Tips and Techniques
Web Apps vs. MS Windows Apps
Different UI thinking
There is a significant amount of information becoming available on browser application UI design in terms of what works for users and what doesn't, what can readily be replicated and what can't or even potentially, what shouldn't. In other words, what a user has come to accept as 'standard' in one environment, may not be considered 'standard' or even 'meaningful' in another environment.
Before you decide to transfer functionality from one environment to another, put some thought into what will transfer elegantly and what will not. Ask yourself if the assumptions in the users mind are still valid and if not, should they be or should that function and that interface method be deemed inappropriate? Perhaps it's an opportunity to think outside the box.
While there is a lot of useful new environmental transfer information, much of it - with few notable exceptions - tends to focus on the 'look-n-feel' or the more visual aspects of creating an IP based application UI. Possibly this is due to the visual toolset currently being used by application developers and software engineers - few have the human factors expertise to realize what works and what doesn't across agnostic environments but anxious nonetheless to create something that 'looks cool' and 'looks similar'. Acting similar is a different matter entirely.
While visual design and cool graphics is important and useful to understand, some key aspects of usability come from more fundamental considerations of the UI architecture. In particular it's worth noting that, when creating a web application (Hot Mail for example) a UI designer is generally designing within another pre-existing application framework (Internet Explorer for example). This creates a fundamental contextual difference between the application feature capability and a standard MS Windows application capability. Not only will your end user not understand this, they will become frustrated by it. To see what I mean, go into hotmail, find a piece of mail or a working object, right click and you'll see what I mean. Is what you see hotmail-relevant or browser-relevant? Do you even know? It's cryptic at best...
It's impossible to discuss all the detailed implications this difference has on the UI design of a browser-based application versus that of an MS Windows application. However, consideration of a few basic aspects should illustrate the importance.
One of the most useful UI elements in an MS Windows application is - not surprisingly - the windows themselves. Of particular interest in illustrating the difference between browser-based and MS Windows applications is the use of cascading secondary windows. Secondary windows in MS Windows apps are named because they generally contain information of use to the user which is "secondary" or relative to a focused aspect of a primary window. For example, if you want to change the font colour in a document you are writing you 'pop up' a secondary window, execute the change, and return to the primary window. As such the secondary windows often have properties coupled to the primary window. For instance they may "collapse" to the task bar with the primary window or they may be modal (no action is allowed on the primary window until a decision is made on saving or canceling out of the secondary window).
In pure browser based (web) applications while the same functionality may be desired there's no simple or elegant way to create a true secondary window. For one, the MS Windows operating system client will generally recognize it as a primary window of the Browser application. This may be contrary to the type of behaviour a user actually interprets as a 'pop up' (i.e. secondary) window. For this, and other reasons, it's better for most situations to stick to a single browser window for actions that you might normally associate with a secondary window in a standard windows application. This affects the design criteria significantly.
This is just one example of the many overt and subtle differences between doing UI design for internet based application versus a standard MS Windows application. Other considerations include things such as the use of menus, lists, search, wizards as well as numerous subtle differences in applying UI principles and design techniques.
These differences arise from both the structure of the User Interface and some of the inherent behaviours of the User Interface toolkit in association with the technology used and the user assumptions.
When trying to transfer from one environment or medium to another (MS Windows application to browser based application or vice versa) it's important to be aware of these differences or a usable design in one medium may end up with a number of not-so-obvious problems in another medium.
Transferring functionality and environment-specific UI may not only be inappropriate and unworkable - it may just be plain silly!