Quick Look at the WI Client Detection and Download Wizard » ocb

Post to Twitter | Comments (5) | Views (22871) |

12 May 2007 12:00 AM EDT

Quick Look at the WI Client Detection and Download Wizard

[ Tags: architecture , web interface , client detection , client download , informed consent , nonspecific ]

For the next release of Web Interface we have revamped the way we detect client software and help the user select and if necessary install and enable the most appropriate software for accessing applications. We call this the Client Detection and Download wizard, or CDD for short.

I've described the problem and our approach before, so I won't rehash that here. We're now in closedown on the next release that includes CDD, so I wanted to give people a peek at what it looks like in action.

Almost no-one expected CDD to be so much work; I'm told there are something like 50 different screens in total because we wanted to tailor the user assistance to each browser we support, and cope with as many configuration as we can. Quite possibly it has ended up being too complicated, but it is our first attempt to fully tackle the complexity of coping with a wide range of browser configurations and client combinations whilst striving for high usability. Also, we made a serious attempt to follow best practice in handling informed consent for installing software - we think that will be increasingly important in making sure our products are perceived as dependable and trustworthy.

As always, let me know if you think we've got it wrong!

On to the screenshots

Initially, nothing looks different when the user hits the login page; behind the scenes a (mostly) silent detection process has taken place to attempt to detect any of the allowed client options. In my example, only the native ICA client is permitted and was not found to be installed.

If the site had been configured to allow the Java or RDP clients one of them would have been selected automatically, and the warning message would instead have just been an informational message to advise that a better client is available.

If the user simply logs in, he will be advised that client software is needed, because none of the allowed client options could be detected automatically:

Choosing to detect client leads into the primary page of the CDD - an automatic mode designed to help the user select and enable the most useful client from available options with minimum interaction. The user is offered options to bail out of the process at any time, or simply logout if they don't have time to continue. The option most likely to help them get their task done is highlighted to make it quick to find, but with the security warning shield immediately under it to help flag that some caution may be needed before proceeding. More detail is available if the user is unsure what might happen next.

In this case, clicking the recommended Download action will initiate the download and install of the ICA web client for Windows. Although the web client install process is not as streamlined as we would like (or as previous versions were), it is a multilingual client package that can be installed by users without local admin privileges, and so stands the best chance of being usable whatever the circumstances.

After installation of the web client completes, or is abandoned, the user is prompted to indicate the final outcome because WI cannot reliably detect this, as we'll see.

If the user reports the installation was successful, the CDD wizard then attempts to verify this and ensure the browser is configured to be able to see and use the client (this no longer happens automatically with IE6 SP2 and IE7). With default IE7 settings, the user will need to allow the installed client to be accessed by web sites by opting-in through the IE Information Bar:

Having navigated through the steps to get a usable client, the user is now shown their list of applications ready to launch. In my example, we have some streamed applications available as well but the streaming client hasn't been installed, so there is a notification about that.

There is also a warning that applications might not launch smoothly because of the possibility that browser lockdown settings may block or intercept launch attempts (in ways that WI cannot detect). The specific reason here is that the WI site is in the Internet security zone and is accessed by https - the normal situation when accessing WI for remote access from arbitrary machines on the internet. The first point forces WI to rely on downloading a launch.ica file (which might be blocked outright) and the second point means that file downloads might trip on the IE setting "Do not save encrypted pages to disk". In practice neither setting is likely to be an issue, and for the latter the required user action is simply to save and then open the file, so we elected to just have a warning.

By the way, as an important point of principle, we have deliberately avoided asking (or as our security architect might say "enticing") the user to change any of the browser's security settings unless it is necessary (there is one case where it is necessary). Instead we try to provide the best possible user experience within the limitations of the actual settings. In my example, if the WI site had been in Local Intranet or Trusted Sites, then the warning message would not have appeared. To avoid problems with browser lockdown making file downloads less usable, WI will now use the ICA ActiveX control whenever possible to launch applications - in practice that requires the WI site to be in Local Intranet or Trusted Sites, because of the ICA client's own security policy.

I will point out that one side-effect of using the ActiveX control for lauches is that the old trick of right clicking on launch links in order to save the ICA file no longer works in most cases. We've been getting a bit of grief on that even from our own support folks who consider it a valuable debugging tool. There is probably a way to enable it by customizing the WI scripts to detect right click in javascript and have WI switch to ICA file download, but I haven't tried it.

Cheers,
AndrewI

Labels

Comments (5)

Anonymous says:

Wisam AlSattar says:

Andrew Innes says:

Anonymous says:

Andrew Innes says: