We are currently using QlikView installed windows clients to access our applications. We are going to upgrade from QV 8.5 to QV 9.
As part of the upgrade project, I am investigating the pros and cons of web based access using an IE Plug-in vs. our current method of installed clients.
Any feedback on the pros and cons of either method would be appreciated.
If anyone has switched from installed clients to web based access and can share their experiences, that would also be very helpful.
We are in the process of switching. Our users I think are still using the windows client, but I'm using the IE client to access anything we've published, as are most other developers, I believe. I've not been involved in whatever it took to make the IE client available, so I can't speak to that part of it. However, as a "user", I've seen no problems whatsoever. Other than the obvious (it comes up in a browser instead of in QlikView), everything seems functionally and visually equivalent or identical.
All developers (me) use the Windows Client and all users access the documents via QV Server and the plugin. Quite painless to set up and install although we use IIS and our own asp menus rather than AccessPoint (to allow us to align them with group standards).
When installing the plugins, we wrap it up with some vbs that sets each machine to 'trust' macros in documents from the server as named and also to change the default locations of user files (to 'My documents' as only these get saved on our network). The vbs also prompts for the email values in user preferences as a one time set up ready for personalised reports. All these are just registry settings.
You might actually want to review your licencing at some point when you need to buy more. With v9 came document CALS and others which are a lot cheaper than Named CALS (which allow access to unlimited documents and so is expensive if a user only needs to see 1 or 2)
With our upgrade to v9 we took advantage of the 'collapse' of the licencing structure and where server 'leased licences' allows a named CAL to lease a Windows Client licence from the server (needs to connect to the server every 30 days to refresh). This allows us to distribute documents to certain users who can then access them off-line.
Could you please provide me with any reasons why you are switching to web based access via the plug-in (in John's case) or why you develop using the Windows Client but have the users access the applications via the plug-in (in Gordon's case).
John Duffy wrote:Could you please provide me with any reasons why you are switching to web based access via the plug-in
I'm not so much involved with any technical reasons for doing it. But I think it's a good idea because it's one less piece of software that the users have to think about. Send a user an Access Point link, and they already know how to bookmark it and bring it up later. Install QlikView on their machine, and they'll need some instruction on how to bring up Access Point, and if they don't use it frequently, may forget between uses.
What we really wanted to do was switch to AJAX. We wanted a zero footprint client. We didn't want to have to maintain software on the user machines at all. We didn't want to be tied to a specific browser. Unfortunately, there are just too many things that don't look right or work right with AJAX. We kept hoping for a long time, but eventually gave up and decided that the IE plugin was the way we'd go.
From MY perspective, deployment is EXACTLY the same regardless of client. But I don't know what sort of details there are in the background. I believe there's a default Access Point web page it'll generate with probably a minimum of configuration, though I think we customized ours.
I wouldn't think there would be any performance differences of significance, but I haven't tested. I figure it's basically the same code running on the same machines, with just a slightly different display.
we tell our customers to develop with win client (fat client). As far as I know, there is right now no other possibility. All others (analyst) are using WEB-Technologie. I do not view creating collaboration objects as developing; but scripting, data-modelling, designing user-interfaces.
I visited Qonnections 2011 in Miami, Fl. A great part of the roadmap for V11 the QT-guys were presenting is going to support more and more WEB-Interfaces. Browsers, independent of the underlying hardware. This means they see mobiles being the BI-Future. Jeff Boehm (QT): "starting with V10SR2 there will be no more any difference between any type of browser (mobile, desk top, tablet)." And then he showed a very new feature on his ipad: creating a PDF and store it as an I-Book. And the audience: standing ovations .... (except me, think was the only one without an i*)
The only difference I can think of between having the IE Plugin or the thick client installed would be that with v9 people with the thick will be able to develop applications locally unless you disable license lease from the server.
This might or might not be something you want them to do.
You might want to consider going straight to QV10, SR2 is around the corner...
Our setup is mainly historical in that the WIndows client ('Enterprise') was a LOT more expensive than the IE plugin ('Analyser') so it was the obvious way to go at the time.
With the licencing changes and every 'Analyser' licence now 'becoming' 'Enterprise' do I still think its the way to go?
I guess it all depends on if the business wants/needs users to have the ability to develop documents; if not then the plugin is much smaller in terms of install space than the client and upgrading them is (arguably) simpler/quicker. It also feels 'right' knowing the plugin can do no more than make requests of the server and has no ability to interact with qvw's (ie business data) itself.
In conclusion, give the user the simplest method of getting their job done and calling up a web page, pointing and clicking seems to be that to me and administratively it is easier.
I've only just started at looking at it - but there are also some limitations in terms of reloading the document if the user only has access to the documents via AccessPoint right?
Sorry - that question wasn't very clear. I mean the user cannot reload the document on the fly in the same way as if they were using the Windows client?
