We are in the process of planning the next version of the new Mac client for XenApp. This new client will be focused on creating a transparent integrated desktop experience for the Mac platform. The concept is much the same as "Citrix Applications" (formerly PNAgent). Our goal is create an environment where users can move seamlessly between their locally installed apps and those being delivered by XenApp. Or, at least as seamless as you can get when you are running Windows apps on a Mac

 

We are running a survey for the next two weeks to gather feedback on the enhancements that will make the XenApp Mac experience world class. If you are interested in taking part in the survey just click here.

Thanks

Al Grandville

Citrix Product Management

    OK. So I'm airing some rather grungy laundry here but, for good reasons I'm sure, our internal implementation of XenApp serves up some 80 + apps to every user.  It's a pretty tough list to manage but, believe it or not, I've heard horror stories that some folks out there are dealing with hundreds and sometimes thousands (yes thousands) of published apps. You can just imagine how painful it must be for users to sort through such a cumbersome list every time they want to launch an app. XenApp provides tools to publish apps to only the subset of users who need them. This, of course, implies that the folks who set up XenApp had the time, resource and the information available to make these decisions. It's difficult to know how many user actually struggle with this problem but it still seems like an obvious place to uplift the users experience. The question is how we go about it.

Option 1 - Fine Tune Citrix Applications

    Citrix Applications allows users to move shortcuts to their desktop, quick launch bar, Vista gadget, etc ... Users can take advantage of all the methods that the OS provides to allow for quick access to his/her most commonly launched applications. There are some areas that still call for refinement like  full support for the recently used apps list in the Start Menu (right now we only show the last app launched ).

Option 2 - Favorites

    We could provide a method that allows users to create a list of favorite  apps. Once the list exists it would act as a filter and the users would only see their list of favorites. We would provide an interface to configure the list and to show the entire list again if the user needs to access an infrequently used app.

Option 3 - Most Recently Used

    A Most Recently Used or MRU list would build as users launched applications. When a user accessed the list their MRU entries would be their primary view with an easy way to expand the entire list if the user needs to access an infrequently used app. The size of the MRU list would be restricted to a small set of apps but could be made configurable by the user and/or the administrator.

    Back in the days of Windows 9.X Microsoft had "Network Neighborhood" on everyone's desktop. It made sense for us to place an icon on the desktop and call it "Program Neighborhood". From there is wasn't much of a leap to get to "Program Neighborhood Agent" when we decided to create a less conspicuous way to integrate applications into the Windows Start Menu and Desktop. Of course, Microsoft has long ago done away with the "Neighborhood" concept leaving us with a very cool program that no longer had a clear and meaningful name.

    Late last year we embarked on a project called "Pineapple". So named as it was charged with identifying the "low hanging fruit" in the users experience. It probably shouldn't be all that surprising that XenApp with its 13 year legacy doesn't have too much that's easy to  change. There's more to the story but for now let's say that Pineapple settled on crafting a consistent user experience across our products. As a result "Program Neighborhood Agent" became "Citrix Applications". We were shooting for something simple and obvious and I think we nailed it. And, yes, in case anyone was wondering we are considering making it possible to change "Citrix Applications" to something that makes even more sense depending on the implementation.

    These days there is a lot of emphasis at Citrix around End User Experience. You may have heard about "App Receiver" which has been highlighted during the keynote at "App Delivery Expo" back in October of 2007 and at our "Partner Summit" this past January.  App Receiver is our vision for a new user experience that will bring together multiple Citrix technologies in a way that is intuitive and easy to use. Imagine client software that is downloaded, installed and configured with little user interaction. An intelligent system that delivers the right components to the user without revealing any of the complexity involved. We will be talking more and more about App Receiver in the coming months so keep watching this space. I bring up App Receiver now only to point out that it is not simply "Program Neighborhood Agent" rebranded. The new "Citrix Applications" is a part of the larger vision and will play a key role in success of App Receiver but it is only a part of a much bigger plan to provide an awesome experience to the folks who use Citrix products every day to get theirs jobs done.

                So how about a few screen shots of the new "Citrix Applications" .....

Al Grandville

Citrix Product Management 

 So I was thinking a demonstration of XenApp desktop integration might be in order. "Citrix Applications" formerly known as "Program Neighborhood Agent" allows you to deliver Citrix applications seamlessly to the Windows Start Menu, Desktop, Quick Launch bar, Sidebar and the Windows Notification Area (AKA The Systray). Virtually everywhere you can place a Windows shortcut you can place a Citrix delivered app shortcut. Check it out ...

These were created on my Vista desktop but this all works equally well in Windows XP with the exception of the Sidebar which isn't available. The important take away is that users can interact with Citrix delivered apps in the same way they do with local apps.

 Our Motto - "If we do this right users wont know we've done anything at all."

 Al-

 
The XenApp User Experience breaks down into two camps:

1: The Transparent Integrated Desktop Experience -- In this model the users primary interface is either a Windows or Mac desktop. Some of their applications are locally installed and some are being delivered by XenApp. The best experience that Citrix could provide is one that completely obscures the apps mode of delivery. In short, users shouldn't be able to tell the difference between locally installed and Citrix delivered apps.

2: The Web Everywhere Experience- The Web based model is a story of consistency and ubiquity. Regardless of whether a user is connecting from their PC at work, at home or at a public kiosk the experience is always the same. Browse to a URL, enter your credentials and launch your apps.

Citrix covers these scenarios today with Program Neighborhood Agent and The XenApp Web Interface respectively. While it's difficult for us to measure the exact numbers the balance seems to lean toward the Web everywhere experience. The question is why ? There is a big focus on enhancing the transparent experience and a strong belief that If we get it right the Web UI will become virtually unnecessary.

So, Are we right ? What's stopping you from moving over to Program Neighborhood Agent and the Transparent Desktop Experience ?

Like most techie geeks, our developers like to play with the latest technology and explore what's possible.  Sometimes they even get the chance to do it as part of their job...

Folks who have seen Thomas Koetzing's peek at the upcoming version of the XenApp Web Interface component will be aware that we've made some fairly major changes to the look and feel.  Certainly this is the most significant design uplift since WI (originally known as NFuse) was first released in 1999.  As you can imagine we're really excited by this, and we hope you'll not only like the new sleek look, but find the usability improvements we've made genuinely useful.  It's been in the works for a good long time (getting on for 2 years).

However that isn't what I wanted to highlight just yet (I'm hoping to get the people who were deeply involved in doing the usability work and defining and refining the design to talk about it).  Instead I'd like to show you something else we prototyped late last year, as part of some work to explore new user interface concepts and technologies.  If you follow developments in the web development world at all, you will have heard about Silverlight, the new cross platform browser-base rich internet application framework Microsoft is creating.  Derek Thorslund linked to the blog announcement this week from the Microsoft team busy working on Silverlight 2.0.

From our perspective, this is pretty neat stuff.  Citrix is already a very heavy user of Microsoft technologies, and our UI and Visual design teams have been eagerly following what Microsoft has been doing in building a strong design/code separation into WPF and now Silverlight.  For them, the ability to easily and safely update our product UIs without disrupting the code (oh I don't know, because someone wanted to change the look and names of a few products let's say...) - THAT would be the holy grail for them.

But WPF and Silverlight also offer a great chance to start being more expressive and trying out fresh approaches to UI tasks.  As it happens, WI is the most commonly used interface for people to get access to Citrix delivered apps, so it is a natural one to focus on.  So we let a couple of developers loose with some simple instructions: learn about Silverlight and come up with something that looks cool.  Well, they didn't give us cool: they gave us bling - lots of bling!  Have a look...

If you like that, have a look at this short video clip to get a better sense for what else it can do.  (You'll need the Techsmith codec.)  By the way, something cool that you can't tell from just looking is that it's powered by a new set of web service interfaces we're prototyping, designed to allow custom UIs to be built by all sorts of people (including us).  Actually, they aren't totally new; the first generation shipped inside the Web Interface integration for Microsoft Office SharePoint Server - give that a try if you're using SharePoint, it works with the Windows SharePoint Services component of Windows Server 2003 as well.

Interestingly, our techie guys, along with a lot of other early adopter developers, gave Microsoft some pretty detailed feedback on what was good and what was missing from the early alpha.  With the 1.1 alpha lots of standard UI controls were missing, leaving fairly low-level drawing primitives as the main tool to use, which ironically forced us to be more creative and come up with something that looks really new.  However it's great to see Microsoft is addressing the many gaps in a very major way!  (See Scott Guthrie's post for a lot more detail on what is now going to be the 2.0 version.)

Now, is this really a good user interface?  I don't know - it was a learning exercise, and a nice way to test whether our service interfaces are good ones.  But will we really ever do a Silverlight front-end to XenApp though?  Now that's a very good question....

Would you like us to?

Cheers,
AndrewI

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

Most people have a fairly well developed ability to assess trust when interacting with other people, which enables them to sense when situations are safe or not and whether to trust what other people say or to be suspicious of their intentions.

Let me give you an example, which perhaps just illustrates how some people (like me) aren't actually that well attuned to the signs.  A couple of months ago, my wife and I agreed to let a double-glazing sales rep visit; we've been thinking we need to replace our windows before long anyway, so when a salesman rang we thought why not get a quote?  (Hey, not everyone's sense of suspicion kicks in right away; I do try not to be cynical.)

So we agree a date and time with the sales guy on the phone, and no-one shows up.  We're a bit irritated, because we changed our plans to wait in. Next week, the phone sales guy rings again, and when confronted apologizes that the rep who was supposed to visit the first time didn't come - he says the rep claims he visited and gave us a quote.  It's impressive how persuasive good phone sales guys can be - he says he will offer us a 60% discount because of it - and after some hesitation we agree to a new time.

This time a rep does show up, and right away apologizes for the other rep not showing first time - and says "he was fired".  (Hmmm.) Anyway, this one seems amiable enough and does the necessary inspection then gets down to the sales pitch.  It is rather drawn out but finally he quotes a rather large number - then my wife points out that the phone sales guy promised us a 60% discount.  The rep manages to look suitably furious and rings the office on his mobile, talks angrily for 10 minutes about how the phone sales guy has done it again and how he will have to honour the discount but it makes him so cross etc, then finishes the call and tells us the phone sales guy "will be demoted this time".

Okay, so if you were in my position, what would you be thinking now?  Is this an honest situation, where circumstances and events should be taken at face value?

We respond sceptically about the price (the one with the 60% discount), and are about to start serving supper.  The rep then quickly rings the office again and comes back with "we've got a job near here in three weeks and could do it that day - I'll give you an extra discount if you decide tonight".  As it happens, I'll be travelling that day so we decline politely and show him out the door. Afterwards, we realize he seems to have forgotten to leave the written quote.  (Surprising, that.)  A quick web search reveals some interesting comments from previous customers about the sales tactics employed by this company, the commission structure for its reps and the quality of their products and work.  Suffice to say, we aren't regretting our decision to pass on the generous offer we were made that night.

My point is that when interacting with another person face to face (or on the phone), we usually have plenty of indicators we can look at to assess how much we should trust the other person, how risky the situation is, whether things are what they seem. "The other rep was fired", "The phone sales guy will be demoted this time" - yes, I wonder whether he would answer today if we ring and ask for Frankie ("like the fish"), sounding as cheerful and matey as ever.

How does this relate to Citrix? Simple: trust is critical to what we do in supporting remote application delivery and how people perceive that, as customers and users.

Trust me, I'm a software developer.  (I've got a compiler and a certificate!)

Trust is an issue in many ways and on many levels - for example, do you trust Citrix to write good products that work as they should and don't pose a risk to your systems?  If so, why do you trust Citrix to do this?  Is it because of how many customers we have, who we have as customers, what customers and third parties say about our products, or because you tested our products in your own environment?  Or maybe you know someone you respect who works at Citrix and that gives you confidence in what we produce?

Already you can see that often there are ways open to you to assess something of the true state of affairs, and so reduce the need to blindly trust us to have written solid products.  But it isn't so easy in every situation.

Right now, I'm wrestling with trust issues that relate to how Web Interface works and how users are or should be involved in making decisions affecting security, especially of their own system.  Most of the key decisions come down to questions of trust.

The core of the problem is that people have very few indicators they can make sense of when visiting a web site on the Internet, to judge accurately whether that site is what they think it is, and whether they are safe visiting it.  The current acute problem with phishing is evidence enough of that.

If that site is Web Interface, one of the first things it does is try to use an ActiveX control - that alone can trigger a warning from the browser these days.  If not found, Web Interface will normally provide a link to a program that must be downloaded and installed to use the site.  If the user elects to do that, they will be faced with a couple of rather cryptic security questions that talk obliquely about trust, but don't really give the user anything useful to go on:

How is an employee of a business partner remotely accessing your system supposed to make an informed and accurate judgement about these questions?  Nothing in either dialog tells the user that the program, if run, will actually try to install something on their computer (unless they know that .msi files are installation packages).  The Web Client for Citrix link just takes the user to the Citrix home page; they would have to really dig to find out what the Web Client actually does.  The publisher link shows them the detailed digital certificate information - barely useful even if you know how to inspect the certificate fields and interpret them.

The business partner employee is implicitly faced with the question "do you trust Citrix to write good products" but without the benefit of the types of evidence someone purchasing the product would likely have.

Even worse than the browser security dialogs are some that the ICA client itself throws up, usually when the user is in the middle of doing something else.  Here is the classic example (this typically appears when browsing My Computer in the Open and Save dialogs of most applications):

I won't go into a critique of this one now - I want to finish this post today!

Can we translate trust judgements about remote systems into judgements about things people instinctively understand?

That is the question I am trying to answer in the context of Web Interface, to improve the way users experience our products and maximize their actual level of security.  I'm willing to forego a theoretically stronger security mechanism that in practice would often be undermined or bypassed for an apparently weaker security mechanism if it will be so easy to use and understand that most people would receive its full benefit.

The idea is that instead of allowing security to depend on individual users making judgements about technical risks they often don't even understand let alone have the means to assess, we should find ways to design the technology so that users are only part of the chain of trust decisions when they are in a position to understand what's happening, and have more natural ways of assessing risks - more akin to the face-to-face indicators I had when judging whether the double-glazing salesman was being honest with me, or trying to lure or pressure me into accepting an offer that wasn't really good value (for me).

Certainly that is possible in some cases.  For example, employers could give employees who need access from home a CD or USB stick that will configure their home PC to trust the company's Web Interface site without needing them to enter the correct URL or manually reconfigure their PC. The employee is making his primary trust decision on the basis of a person he knows (his employer or an IT person at work) giving him a CD for this particular purpose; he will probably assess intention and competence to some extent without even realizing it.  He can also make a secondary trust decision about whether the CD or USB stick could have been tampered with or swapped for a trojan once he received it, because it is a physical object he took home with him and people are fairly good at knowing how to look after small objects. (Or at least better at it than knowing when they have visited a phishing site.)

Of course the software installation process started by using that CD or USB stick needs to allow the individual sufficient control over what is happening, as well as ensuring they are properly informed (in terms they can actually understand) about what is happening to the security settings or posture of their system, why that is desirable or necessary, how the user can change their mind later etc.  This is where Citrix needs to do its homework, to make sure we design our products to minimize the chance they could be used maliciously to endanger anyone's systems.  (That still doesn't quite answer how any particular individual, who might be a third-party user of a Citrix system, can tell whether they should trust Citrix software to behave this way though.)

There are lots of even more complicated scenarios that get interesting, when you look at the relationships between application provider, application consumer, application data owner, device owner and application + device user.  I'll talk more about those actors and their relationships another time.

As I said earlier, trust is critical to how Citrix products work and are used, and there are many varied facets and levels of trust we could talk about.  Let me know if I've oversimplified things, or missed something you think is vitally important.

Cheers,
AndrewI

PS.  I've deliberately been imprecise in using the word trust, to try and speak to the various 'natural' meanings that different people assume. It turns out there are some quite interesting articles that talk at length about the nature of trust, which make insightful reading.  One that I've been reading recently is "Designing Systems That People Will Trust", which is included in Security and Usability.

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

I was fascinated by Jeff Muir's account of how the ICA web client came to be written, and also by the timing of when this happened (much earlier than I realized).  It brought home to me again the curious arc Web Interface is riding, from the early days of the Web when it was a novelty to be able to run applications from a web browser, to the point we are at now where it is getting increasingly difficult to run ICA applications from a web browser, at least with the technology we have today.  Making sure we are in a better place a few years from now concerns me, and makes me wonder if we need a step-change in technology.

We've known for some time that it is getting harder, and that people are running into more and more situations where Web Interface isn't working properly and they can't get access to their applications.  It isn't just executives using the kiosks in airports and hotels - though you can imagine how much visibility that gets when a company has just put in a shiny new Citrix system for remote access!  It also matters for customers wanting employees to be able to access critical applications from home, or from anywhere they might be stranded in a wide-scale emergency.

The problem is that security concerns have come to the fore, and browsers are increasingly trading off usability and convenience (or rather the apparent convenience you enjoy before your PC stops working for you and opts for a life making money for spammers) for better security.  Browsers themselves are including more security mechanisms like the IE Information Bar introduced by Windows XP SP2, pop-up blockers and the like have become de rigueur it seems in almost any product with an Internet focus, and security suites are hooking into almost everything that's happening on your PC to block bad behaviour.

This decline in usability unfortunately goes to the heart of the Citrix value message, that access is provided from any device over any connection anywhere.  Web Interface is the primary means we have of delivering on that promise, with the Internet and web browsers taken for granted as the ubiquitous baseline we can assume to exist (almost) everywhere.

So it's a big deal for us that WI is hitting more and more problems that undermine this essential role, and I am pleased to say we are now doing something about it.  We can still use your input and guidance though, to help ensure we are focused on the right aspects and make the right tradeoffs.

The approach we are taking is one that has been pioneered already; you can see a good example in action here.  In essence, the approach is this: accept that we cannot always accomplish what the user wants, or not always as easily or as well as the user would like.  Instead of pretending that we can always launch applications at the click of a button, and treating the small matter of ensuring the user's computer has the necessary client components and security settings as a kind of after-thought, lets make that process an essential part of the user experience.

And if we can't launch applications (for reasons beyond our control), lets be sure tell the user so clearly and promptly, so they don't waste any more time trying.  If we can say why, they also may have the chance to get something done about it; maybe convince kiosk owners to pre-install ICA clients for example.

I'm sure this is a topic that will get discussed a lot more, here and elsewhere, so for now I'll just whet your appetite with a screenshot from a prototype we've built recently which gives you a flavour of how we are intending to start following this approach in the near future. 
 
 
As I said in my initial post, this forum is an opportunity for you to give feedback directly to the Web Interface team, and there is a good chance that we will be able to act on your feedback and incorporate good ideas, if not in the next release then as soon as we can.  So, let us know what matters to you, and where you would like us to concentrate.
Cheers,
AndrewI