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

I am delighted to report that Web Interface 4.5 has officially been published on MyCitrix this week, the fruit of 18 months of intense collaboration by a team extending more than halfway around the world, numbering well into the dozens. Another fruit of this effort is the first release of an officially supported WI portlet for IBM WebSphere, which follows the release of WI for Microsoft SharePoint almost a year ago. There were twists and turns aplenty throughout those 18 months, right up to the final hour before we pushed the "Go!" button, but in the end we had lift-off on schedule and WI is now safely in orbit - err, I mean you can download it.  (We had a brief problem with a couple of loose tiles, but hey it was a bumpy ride!)

It is more than 2 years since I started working on initial planning for this release, looking at how Citrix could deliver a single Suite-wide web UI that provided a consistent front-end for all the 'premise-based' products we were then offering (Presentation Server, Secure Access Manager and Password Manager).  Two of the original goals were to provide a consistent set of authentication methods for all web UIs, and the ability for individual product web UIs to be deployed together to form a single aggregate UI.

The second goal was realized with the release of WI 4.2 and Access Gateway Advanced Edition 4.2 last year, sporting an integration mode whereby WI renders the list of published applications in the AG 'NavUI' page, alongside the list of published web resources and file shares or documents.  We implemented a custom single sign-on mechanism to support this integration, capable of sharing end point scan information collected by AG so that application and session policies on CPS can be triggered by the same information.

The first goal spawned our Callisto project which has evolved over time to put the focus on advanced single sign-on capabilities, since authentication support across AG and WI is now largely consistent and less of an issue than it was 2 years ago.  ADFS and SAML have emerged as the key technologies and standards we are embracing for advanced SSO, and I know we will have more to say about this as our product capabilities increase and as the early adopters among our customers gain experience with the technology.

So, what's next?

For WI, our attention is now firmly focused on improving end user experience.  First up is tackling how to provide remote access to applications when web browsers are becoming increasingly locked down and security conscious - it can no longer be taken almost for granted that a web site can provide remote access to CPS applications.  The importance of this is being driven home by the release of Windows Vista last week, where some pretty major changes have been made to Internet Explorer affecting web sites with active content.  WI essentially by definition is all about running active content, so this is crucial to us.

On top of the technical limitations to what can be achieved, the general climate in the industry is tightening. Spyware and concerns over malware generally have become a regular feature on front page news.  Stringent guidelines have been published on how "goodware" (kindware?) should behave, to instill consumer and business confidence and protect both users and producers.  Legislation is increasingly being adopted to back this up, just in case software producers haven't got the message.

Reconciling Security and Usability

So security and usability concerns are at the heart of what we are wrestling with at the moment.  There is certainly tension between these concerns, but actually they are pulling the WI design in directions that are closer than you might suppose.  For WI, usability is about making things simple and obvious, about providing resource access with as few questions and steps as possible.  Security demands the user be informed about what is going on and in control so that things only happen with his consent.  But consent requires understanding, and understanding requires speaking the user's language and presenting only choices that make sense and are relevant to him - ie. keeping it simple and obvious.

The real challenge is to figure out which choices can be reasonably decided automatically, and when and how to present and explain the choices that the user really needs to decide for himself.

Calling all clients: you need software!

Let me give an example.  WI has three different software options to connect to CPS applications: the "native" ICA client (which can be used in two ways), the Java ICA client, and in some environments the Microsoft Remote Desktop Connection client.

These options mean nothing to most users.  Actually, they are worse than nothing because the options are completely baffling to most users.

We found out recently that just using the term 'client' to refer to the software needed to access applications can be confusing.  After all, in everyday life client refers to a customer receiving a service - lawyers and estate agents have clients.  If I'm not dying, divorcing or moving house why do I need to install 'client software'?!

It is no wonder that a fair few Citrix deployments disable WI's client selection UI.  (In 4.5 we made it easy to hide all the user preferences UI, including the Advanced Options on the login page.)

What we plan to do about client selection

What we are currently thinking would make more sense is the following.  (This is very much work in progress; feedback is welcome and we will update you as we work through this design.)

Using all reasonable tricks and established techniques, we will silently detect as much as we can about the browser environment's ability to use each type of client software.  This means checking for the ICA ActiveX control on Internet Explorer on Windows, checking if pop-up windows are allowed, if Java support appears to be enabled, and if an RDP ActiveX control appears to be available and the WI site is in a suitable IE security zone.  (Currently we think we can detect pretty much everything we need to know in an essentially silent fashion, though there is the possibility we will have to prepare the user if a necessary test could trigger a browser warning prompt of some kind.)

So far so good, but now things start to get tricky.

If we don't detect a native ICA client, but do discover that Java is working, what should we do?  Just because we didn't detect the native client doesn't mean it isn't installed - it might be that it is installed but our ActiveX check is blocked by IE security settings (which wouldn't necessarily stop us using the client for launches).  Should we offer the user the chance to install the native client software (or confirm that it is already installed) before proceeding?  But if it isn't installed and installation fails (or the user is unsure about installing it), how do we explain that there is another way to launch applications after all?

Our plan right now is to avoid this dilemma by making a reasonable decision without asking: if we can determine there is some way to launch apps, we will automatically use the best available method - in this case the Java client.

However, in doing this we've created another problem - the user experience with the Java client might be unsatisfactory or even broken in some way (say because drive mapping is disabled, or printing doesn't work well).  We now need to indicate to the user somehow that they might experience difficulties, depending on what they are doing with the applications, but they might yet be able to resolve the difficulties (we can't be sure yet) by trying to install extra software.

To deal with this, we plan to continue using the "install caption" portion of the message area to flag that the user might experience problems launching or running applications, but there is potentially something he can do about it.  The message will include a link to an explicit client detection and download wizard that will guide the user through the process of determining what options he has for accessing applications, including downloading and installing software and adjusting browser settings if appropriate.

There are many details of this wizard that we are working through right now; once we have some storyboards we are reasonably happy with, I'll post them here for comment.  In the mean time, I would love to hear suggestions on what would work better or what might not work so well.

Cheers,
AndrewI