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

This is a topic I've been itching to start talking about since Citrix opened up the doors to blogging. I can only scratch the surface today, but it's a good moment to start.

For those of you attending Citrix iForum in a couple of days, I want to draw your attention to a demo that you might otherwise easily overlook or not immediately see as significant.  In the Tech Lab area on future technology we will be showing how Microsoft's Active Directory Federation Services (ADFS) can be used with Citrix products to enable single sign-on across the enterprise. The demo will illustrate how the user frustration of multiple sign-ons to different apps is replaced with a single strong authentication event that is carried securely into web application sessions and applications running on Presentation Server (with the help of Password Manager if necessary).

Don't be fooled though - single sign-on (SSO) is certainly powerful and useful, but that's not all that's happening here.  What you are witnessing is the blurring of web and Windows application boundaries, the breaking down of silos of user identities for application access and control - the ending of the era of "one way for the web, another for Windows" and the start of a new way for all applications to tap into a common rich understanding of identity, context, roles, authorization, and trust.

If you care about identity (and I sincerely hope you all do) go see this demo and more importantly talk to the people giving it.  You'll find some smart people there who've been thinking hard about this subject, who are eager to hear about the issues you are wrestling with, share what they know, and talk about what Citrix has done already and the work we are doing to enrich and enlarge our approach to identity.

Let me share a bit of my perspective on this, and why I'm really excited by what we have enabled so far and where we're going with this.

I talked before about the role of Web Interface in the Citrix Access Infrastructure, and said that WI is at the intersection of users, resources and access scenarios.  Clearly identity is central to the understanding of users, but I hinted that identity is more than just username and password, richer than just which credentials are needed to access a system. 

Web Interface, and Presentation Server, and Access Gateway, and most other products and systems throughout the lifetime of the entire IT industry were brought into the world with the feeble understanding of user identity that starts and ends with a username and password. But we know that doesn't begin to match the reality users live in, and have lived in for years now.  We know study after study has shown that workers, not just in large enterprises, often have 10 or more usernames and passwords for different systems.  We know that they will try to make them the same, and they hate having to change them, and they can't remember them all without using bits of paper stuck in odd places, or just in plain sight.

Many will even divulge them to strangers for a nice candy, or even just a cheap pen.  (Anyone want a Mars bar?)

Heck, I've come across people that leave their work machines running all the time (even when they're on holiday) with the screensaver turned off, just so they don't ever have to type their password.

What's really significant about our ADFS SSO demo is not that it demonstrates SSO, even across web and Windows applications, but that it is not sending passwords around to do it.  It is sending signed statements of user identity issued by a trusted party (here a corporate ADFS server) based on whatever level of authentication the trusted party and the user agreed to use (password, smartcard, hardware token, etc).  The applications, both web-based ones and Windows ones running on CPS, have been directly or indirectly configured to trust the ADFS server's assertions of identity in lieu of performing their own user authentication.

A monumentally huge tectonic shift just happened so quietly in that last paragraph, you might not have noticed you aren't in Kansas any more.  Have a look out the window.

That's right.  Web apps don't have to perform their own authentication; with help from Citrix, Windows doesn't have to perform authentication either. Both can work with just user identities, not user credentials.  The user identity that is authenticated doesn't have to be the identity asserted or used; the identity asserted in one place doesn't have to be the identity asserted in another.  In some cases, it may not even be the user identity that matters - it can be enough that a trusted party vouches for the user being over 18 say, or a member of a certain organization, or entrusted with specific privileges (if only for one transaction).

(By the way, I think it is worthwhile everyone reading a bit about the Shibboleth project to get a feel for some of the scenarios in which that last statement applies. Then think about what situations in your organization might bear some resemblence to those, and reflect on whether those situations cause tensions and conflicts that might go away if you could make use of the richer understanding of identity, attributes, roles, authorization etc that Shibboleth users enjoy and which Microsoft is actively working to bring to wider fruition.)

Even if you are just going to work with user identities and use passwords for authentication, this is still a win - we no longer need to ship your full credentials around everywhere, in case something needs to check you have the right password to confirm your identity.  You only need to confirm your identity once, to something you trust, using a protocol that doesn't actually have to disclose your password to do it.

But make no mistake, the approach to identity embodied in standards like ADFS and SAML (what Microsoft calls claims-based identity) really is a tectonic shift from the past - and nowhere more-so than in the model of trust it imposes (more on that another time).  To take proper advantage of this new approach, without opening yourself to entirely new risks, you need to get your head around how different this approach is and how it really works.

For those of you going to iForum, I trust you'll get a lot out of it, but whether you are going or not try to spend some time lifting your eyes to see the tidal wave that is starting to come over the horizon.  It's going to take years to get here in full force, but it will radically change the way we think about identity, roles, authorization, trust, security and most other aspects of how applications are delivered and managed.

Just trust me on this one.  Okay?

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

Hi, it's me again (Web Interface Guy).

Before I start going on and on with all my ideas about where WI should be heading (just the usual stuff: stopping hunger, imposing world peace, serving fries with every app launched), it will help to be clear about what WI is for; what it's role in life is and should be.  As you would expect, I have a fairly strong opinion on this, but I realize mine may be a rather blinkered view, coloured by the aspirations Citrix has and those I have myself - so please tell me if you think I'm being dumb about this.

Actually, it will help even more if I am clear about what Web Interface is first.  (Thought you knew did you?  Ah-ha!)

As far as I am concerned, WI comprises about a dozen things - in other words, this is what the WI engineering team actually builds and maintains:

• the normal WI web app (ASP.NET and JSP flavours)
• PNAgent Services (same two flavours)
• WI web parts and other bits for SharePoint
• WI portlets for Java-based portals (like WebSphere, SAP, etc)
• WI configuration manager (aka the central config service)
• WI extension to the AMC (our admin tool)
• WI installer and site manager tool (2nd stage installer)
• WI core resource access library
• WI SDK documentation
• CPS XML services (NFuse, Admin, Config, STA, RADE)
  

In fact, about the only component we don't build that logically should perhaps be treated as part of WI is the PNAgent client itself - it is essentially the non-browser UI version of WI.

I mention this list, because I want to use the term 'Web Interface' as a shorthand for all of it, not just the first item which is what everyone else thinks of as WI.  (BTW, I have tried to come up with a good term for this "WI in the large" notion but somehow all my acronyms seem a bit lame - WIITL anyone?)

So anyway, back to my point: what is the role of 'Web Interface', in this larger sense?

I think the answer is quite simple: WI's job is to provide users access to their resources.  The emphasis is on the word provide, for which I have a quite specific meaning in mind.

First let me digress a bit: Citrix started using the term Access Infrastructure a couple of years ago to try and explain the value our products offer, both individually and collectively.  That got me thinking, and I came up with this simple way to categorize our products and components as performing one or more of the following basic functions:

1. Provide access to resources
2. Deliver resources or access to resources
3. Enhance the delivery of resources
4. Control resource access and delivery
5. Manage (ie. measure or monitor) resource access and delivery
   

The ICA piece of Presentation Server of course delivers applications remotely, and enhances the delivery in many ways that I won't tire you with now.  Our SSL VPN products deliver remote network connectivity or access to specific resources (internal web sites, files, etc) and our NetScaler products enhance the delivery of web applications by providing security, compression, load balancing and so on.  Our latest product, WanScaler, does a similar job enhancing network connectivity to branch offices.

Presentation Server, Access Gateway Advanced Edition and NetScaler all support rich policies for controlling their respective resource access or delivery mechanisms, and we are already part way down the path of converging and combining these policy controls to work collectively.

The EdgeSight product line is focused squarely on the final function, of measuring and monitoring all of the above.  The Resource Manager, Report Center, and Dashboard components serve the same function for CPS specifically.

(Okay, you get the idea - there is a cogent strategy in action here.)

For me, the point is that WI is concerned only with the first function, and merely plays a supporting role to the products and components addressing the other functions.  This may seem a trite point, but actually it helps people in Citrix (me in particular!) to understand which of the many enhancement requests or neat suggestions we get for WI are sensible, and whether and how we should go about extending WI to support new features and capabilities in our products.

Right then, here is my definition of what it means for WI to provide users access to resources.  It is WI's job to

• Be aware of the existence, location and nature of resources
• Be aware of how resources can be accessed or used
• Be aware of users and access scenarios
• Make the existence of resources and possible actions known and available to users
• Arrange or orchestrate access to resources (or initiate actions) when requested
  

I like this definition for lots of reasons, but I'll highlight only a couple right now. 

#1 and most significant, WI is at the intersection of users, scenarios and resources. 

WI (usually) needs to know who the user is, but that can be a much richer concept than the traditional view of simply a user name or id - users can have multiple accounts or identities, and may take on different roles in their work at different times.  WI is a good place to help map between these identities and account for the richness that actually exists.  Authentication of course is important and needs to be flexible - but WI doesn't necessarily have to perform authentication itself.

WI then needs to take account of the scenario - 'where' is the user, how are they using the system, what are they trying to do, what are they expecting to happen?  In the WI team, we spend a lot of time thinking about this aspect - as I noted in my first post, for many users WI is the face of Citrix and although they may not be able to express very well what they want, they can certainly tell when it didn't happen!

WI needs to understand the resources; what are they, what are they for, what can you do with them, how do they work?  Note that this is more than just knowing how you "get" to the resource - different types of resources may be accessed with the same physical means (eg. ICA connections to published apps or virtual desktops), and the same resource might be accessed in quite different ways depending on the type of user interface.  For example, someone seeing a Word document link in SharePoint may expect Word to run when they click the link; the same person seeing the same resource listed on their BlackBerry might want a summary of the document emailed to them.

Finally we get the juxtaposition of these three aspects: WI has to figure out what can this user meaningfully do with this resource in thisscenario?  And how can that be made to happen?

#2, WI is an orchestrator and must therefore deal with all the complexities and idiosyncracies that come with the territory.  WI offers the user "X", the user says "do X", WI must make X happen!

In practice, for the resources WI understands today, that involves detecting the access client / device capabilities, downloading and installing appropriate client components if necessary (or giving instructions on how to do this manually), providing 'directions' (translating addresses as necessary based on the user's location relative to the resource, putting the right settings in launch.ica), obtaining security tickets and access tokens where needed, etc.

I think of WI as aiming to be a bit like the perfect travel agent; the user outlines what they want, the travel agent makes some assumptions and deductions, books everything, then hands over a tidy package with the itinery, tickets, foreign currency, emergency helpline numbers, sick bag, etc all neatly layed out.  (But they don't actually go on holiday with you.)

Well, that's the aim anyway!

Cheers,
AndrewI

Hi folks, to the Citrix Architects blog. If you have come here looking to read things our product architects have to say, presumably about Citrix products mostly, probably about what we are working on or thinking about doing as we evolve and expand those products, you come to the right place. If you come to give us your opinions on those things, and what you think we should be doing instead or just better, you definitely come to the right place. We want to hear more from you!

Of course we don know exactly how this forum will turn out, but the plan is for individual product architects like myself to post here occasionally on topics of our choice. The first one will be along in just a moment.

So on behalf of the product architects at Citrix (at least this once), welcome, and without further ado let the conversations begin!

Cheers,
AndrewI

Hi folks,

Every blogger has to start somewhere, so here goes...

I am the product architect for Citrix Web Interface, the main web user interface for Citrix Presentation Server. I guess that means if you don't like something about the way WI works, I'm one of the people you can now shout at - there is even a chance I could do something about it.  (Conversely, if you already like the way WI works, I am perfectly happy to accept accolades, awards, cool shades, that sort of thing - on behalf of the WI team of course.)

For many end users of Presentation Server, I'm told WI is the "face of Citrix", and increasingly responsible for providing that crucial first impression which can either make users love us or hate us - or more to the point, love or hate you as the person who put in this wonderful / *%$&£! 'Citrix' stuff!  (No pressure on anybody there then, that's nice.)

Given that, my aim is to use CitrixCommunity.com to talk about what we are doing and where we are going with Web Interface, how we (or at least I) would like it to evolve, and invite feedback and discussion on those thoughts.  I have an advantage not all product teams in Citrix enjoy, in that WI is not a component where we have deep intellectual property or add super-secret features, so I can talk fairly freely about most of the things we are working on or planning to do.

BTW we will probably create a separate area for WI in due course, but I wanted to start off in the Architects area because some of the ways WI could evolve have far-reaching ramifications on the architecture of Citrix products which go way beyond just the web UI layer people associate with Web Interface.  Even within Citrix, many people think of WI as just "a web page with icons" and are surprised to learn how much WI does and how many things it interacts with in some way.

But that's a topic best kept for another day.

However I can't finish without making reference to at least some of the many excellent resources already out there which are good places to learn about WI, where you will find tips on ways to customize it, and even pre-built packages that provide extra functionality which has obviously proved useful to many people.  I won't be trying to compete with any of these sites, I have to say!

(That reminds me: one of the things I want to talk more about is to explain our reasoning for why we do or don't include various kinds of functionality which clearly have enduring appeal.  But I'll save that for another day too; I'd like to get some rest before I'm roasted.)

From Citrix itself there is our official product support forum http://support.citrix.com/forums/cat.jspa?categoryID=3, and developer support forum http://support.citrix.com/forums/forum.jspa?forumID=106, plus our current very-good-but-then-I'm-biased SDK documentation http://support.citrix.com/article/CTX106665. Curiously, one of the best detail-packed documents on how WI interacts with other Citrix components - and a little-known one I suspect - is the troubleshooting guide for WI http://support.citrix.com/article/CTX106974.  There really is an extraordinary amount of information in there, so have a look if you haven't seen it.

From the wider community, there is www.brianmadden.com, www.thomaskoetzing.de, www.jaytomlin.com, www.jasonconger.com, and www.dabcc.com to name a few well-known sites; no doubt there are others I just don't know so well.

Cheers,
AndrewI