Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
Working on a prototype using QlikView 8.5 - our server is hosting a fairly large (100 million row?) data set, and the QVW file that's been created covers most of the basic analysis that the users will need.
However, the power users have been sold on the idea that they can explore the data in any way they wish and have two key requirements:
I'm stumped as to whether either of these things are possible. Obviously, I can provide a subset of the data that they could use locally (the full 100 million data set would blow their PC memory away). This can't be satisfactory, because then they're not seeing the whole data picture.
Without meeting these two needs, we won't be offering our users true freedom to explore large datasets.
I welcome any and all suggestions for these issues!
Cheers,
DrNick
DrNick wrote:
Since the functionality is present to create new sheet objects when accessing QVWs via Client-Server, I'm just not sure why QlikView hasn't implemented the ability for the users to actually build something useful (e.g. by adding new sheets and being able to populate true ad hoc reports) in this way. It's almost an afterthought (or, worse, a 'cool demo' feature).
Still wondering if any forum members with large userbases have managed to tackle this problem, or do you all pretty much roll out QlikView as 'read-only' once it's available on the server?
It's been pretty much read-only. The ability to create new objects in a server document is a fairly recent capability and it still has some rough edges. It's received limited use at our shop, mostly by Developer and Professional users for ad-hoc work. I would not rely on Server Objects as your development model. It's not robust enough yet. For example, we once lost all our server objects during a server upgrade.
I agree that the inability to create a new sheet seems goofy and I hope that it will be provided in a future release.
With regards to "power users" creating new content. If they are Professional users with proper training, it may work. The ability for users to create new objects in a server document is a fairly recent capability. It's received limited use at our shop, mostly by Developer and Professional users for ad-hoc work.
Most Analyzer users have reacted coolly to the idea. They find it too complex to create useful charts without significant training. If I am going to give them that much training, I may as well make them Professional users. So far Analyzer users have limited themselves to adding listboxes.
Frankly, I have some concerns about the idea of Analyzer user object creation and would turn it off it weren't so useful for the Developer/Professional user. I would prefer to allow Server object creation on a userid basis. My concerns are:
1. It's fairly easy, especially for the inexperienced user, to create a QV chart that shows incorrect results. Sharing/Printing/Exporting these bad charts will damage the organizational confidence in all QV reports. "It's the user's fault" is not a productive explanation.
2. Demands for training and assistance will be hard to quantify and keep up with. We have about 200 analyzer users. Developer and Professional users get "pre qualified" as having reasonable technical aptitude before we invest in training them. The technical aptitude for Analyzer users is all over the map.
I don't worry much about the limitations of the Server object creation feature, as I consider it of relatively low value for Analyzer users.
I believe a good model for a medium to large company is:
1. Create QV Developers from the IT department / programming class. Their role is to write the scripts that extract and translate the data into useful QV data models.
2. Create QV Professional users using technically savvy people from the business units. Their role is to create the visual elements the meet the business needs.
-Rob
The "QlikView way" is that drill down is acheived by selections in list boxes rather than defining drill paths.
You could leave a few blank sheets at the end of each document and request it be changed. It does seem silly that sheets can't be created but maybe there's a reason for it.
J
In my opinion, users "pre-defined" drills are stored in bookmarks... local or shared.
DrNick wrote:The ability to create and share new content (using their Professional licenses) via collaboration on the server. This would probably be delivered by users adding content to additional 'user content' sheets on the dashboard.
These are two different things you are talking about:
1. You can let them create new content using Professional Licenses within the document - this way, they are modifying the original documents. SInce Professional license is a form of a "local client", they are not truly working on QVS. Because of your huge data volume, I'd suggest that they work on a powerful server (same or separate) via remote terminals and modify the documents right there.
2. Create a share new content via collaboration on the server. You don't need a Professional license for this option, but hte changes don't get stored within the document itself. Instead, they are stored in the "shared objects" area - those strange files that QVS is creating next to the original document. Any licensed analyzer can create and share objects using Collaboration pane.
hope this answers your question.
Oleg
Thanks for all the replies.
Oleg - you're right, they're two different things.
With regard to creating new content (point 1) - I think this is the point that I end up being most disappointed with QlikView's ability to deliver. With multiple users in a large corporation there's no way that I can get them to log onto a powerful server via a terminal and run QlikView there.
Since the functionality is present to create new sheet objects when accessing QVWs via Client-Server, I'm just not sure why QlikView hasn't implemented the ability for the users to actually build something useful (e.g. by adding new sheets and being able to populate true ad hoc reports) in this way. It's almost an afterthought (or, worse, a 'cool demo' feature).
Still wondering if any forum members with large userbases have managed to tackle this problem, or do you all pretty much roll out QlikView as 'read-only' once it's available on the server?
Best Rgds,
Nick
From Jay: The "QlikView way" is that drill down is acheived by selections in list boxes rather than defining drill paths.
Thanks for the reply, but that makes me confused on two counts:
1. By going to document properties, groups in the full client I can define objects that allow me to cycle or drill - why can't I do this in client-server mode?
2. QlikView marketing always states that a huge benefit over OLAP is that users don't need to go back to IT to redefine their hierarchies (etc, etc.), but the only QlikView alternative in Client-Server seems to be to populate a page full of list boxes to highlight possible drill paths. Seems a bit clunky, doesn't it?
I wonder what the official QlikView view is on this...? Anyone on the forum that can answer this?
DrNick wrote:
Since the functionality is present to create new sheet objects when accessing QVWs via Client-Server, I'm just not sure why QlikView hasn't implemented the ability for the users to actually build something useful (e.g. by adding new sheets and being able to populate true ad hoc reports) in this way. It's almost an afterthought (or, worse, a 'cool demo' feature).
Still wondering if any forum members with large userbases have managed to tackle this problem, or do you all pretty much roll out QlikView as 'read-only' once it's available on the server?
It's been pretty much read-only. The ability to create new objects in a server document is a fairly recent capability and it still has some rough edges. It's received limited use at our shop, mostly by Developer and Professional users for ad-hoc work. I would not rely on Server Objects as your development model. It's not robust enough yet. For example, we once lost all our server objects during a server upgrade.
I agree that the inability to create a new sheet seems goofy and I hope that it will be provided in a future release.
With regards to "power users" creating new content. If they are Professional users with proper training, it may work. The ability for users to create new objects in a server document is a fairly recent capability. It's received limited use at our shop, mostly by Developer and Professional users for ad-hoc work.
Most Analyzer users have reacted coolly to the idea. They find it too complex to create useful charts without significant training. If I am going to give them that much training, I may as well make them Professional users. So far Analyzer users have limited themselves to adding listboxes.
Frankly, I have some concerns about the idea of Analyzer user object creation and would turn it off it weren't so useful for the Developer/Professional user. I would prefer to allow Server object creation on a userid basis. My concerns are:
1. It's fairly easy, especially for the inexperienced user, to create a QV chart that shows incorrect results. Sharing/Printing/Exporting these bad charts will damage the organizational confidence in all QV reports. "It's the user's fault" is not a productive explanation.
2. Demands for training and assistance will be hard to quantify and keep up with. We have about 200 analyzer users. Developer and Professional users get "pre qualified" as having reasonable technical aptitude before we invest in training them. The technical aptitude for Analyzer users is all over the map.
I don't worry much about the limitations of the Server object creation feature, as I consider it of relatively low value for Analyzer users.
I believe a good model for a medium to large company is:
1. Create QV Developers from the IT department / programming class. Their role is to write the scripts that extract and translate the data into useful QV data models.
2. Create QV Professional users using technically savvy people from the business units. Their role is to create the visual elements the meet the business needs.
-Rob
Let me second Rob's observations. My experience has been exactly the same - vast majority of end users don't need and don't want any ability to modify QlikView objects. They are happy consumers of information.
As for the ability to perform development work in a Client/Server environment - I believe it's a "Work in Progress". QlikView will get there at some point, but it's not there yet - that's just the way it is, at the moment.
Oleg
DrNick wrote:Is there a way that the users can add additional sheets to the document without IT intervention?
According to this http://community.qlik.com/forums/t/16497.aspx QV 9 allows user added sheets.
-Rob
I attended QV 9 new features webinar today, and there was a question about adding sheets. The answer was like "no - but a good idea for future enhancements".