Portability of Customizable and/or Adaptive User Interfaces
This March my workplace issued employees a Motorola i760 cell phone, which apart from being pretty sluggish, doesn't work the same way as my personal phone, a Nokia 3100 - the menus aren't the same, shortcuts are different, and so on. What I discovered a few minutes after receiving the phone was that the User Interface was customizable, which didn't cause the phone to suck less, but only to work the same way as my Nokia did.
Customizable and adaptive user interfaces are great, but they're not something every developer does on their own accord. Most of the time, it's "My way or the highway" when a developer designs a user interface, and since most companies don't hire designers to design their user interfaces, this might turn into a fiasco, as many of you know or
have heard about.
As with my phone, Customizable User Interfaces are interfaces that allow users to change parts of themselves using a special menu or screen chuck-full of options. Adaptive User Interfaces are interfaces that change over time in accordance with how the user interacts with them, such as Windows's Start Menu (when items you don't usually click on are hidden until you click the little arrows at the bottom).
A few days after changing the entire layout on my new phone, a coworker
tried to use my phone, but due to the fact that my interface had been
customized one way and his another and the fact that the phone presented little to no textual
or graphical cues as to which button does what (unless manually
activated through, guess what, one of those unlabeled buttons), he was unable to do anything like he was used to, got pissed off and had to ask me how to do operate the phone.
What this means is that these types of user interfaces don't work well simply because they're not portable. When I sit on my own computer, logged in under my own username, I have no problem with the user interface - it is as I have set it. On the other hand, when I move to a different computer or even log on as a different user on the same machine, my customization is inexistent and sometimes even worse - the customization is for a different person, with their own preferences. This is a disorienting experience for most users and will usually take them more time to perform any action, as easy as it may be, which contradicts with the reason for creating such complex user interface logic in the first place.
This pretty annoying problem doesn't (or I should say shouldn't) happen in web applications, but it does in windows applications, where to date I've only seen one solution. You too may have seen it yourself - it's the "Save my preferences to file" method, which you can find in Microsoft Office and Visual Studio, to name only two applications, but the problem with that is that you have to carry that file with you or place it somewhere where you could access it from any computer you may use.
So what can be done about this? In my opinion, the best way the problem could be solved would be to create a central server that would save these preferences (and optionally also all other configuration changes made by the user) to some database and while your application loads, it would connect to said server and download the preferences from it, depending on which user is logged into it. This, of course, does not necessitate the creation of a logon screen in your application, which would be annoying, but rather a special form that would be filled with a their own predefined username and password. Once these credentials are entered for the first time or changed, via a form that will always be accessible from the same location (you may call it the user's 'anchor' in an unknown UI), the server would be queried for the preferences and the application would transform into what the user is already familiar with.
One might argue that this solution poses a security risk, as anyone getting hold of this 'valuable' information could do malicious things with it, but this risk is also present in the current form, where the database is not centralized, but each user has their own 'configuration file' saved on their own machine. Add this to the fact that the information could be held almost anonymously and behind very powerful encryption and you have a very low security risk (I would never say there are no security issues what-so-ever as much as I will never say an application is bug-free).
This solution looks not only applicable for vendors - holding their own repository for their applications, but there may even be a few service providers that could provide a central repository for many applications by many software vendors. Payment for this service could be an agreed upon sum per-license sold (or it could even be free (as in beer)).