Over at Digital Web Magazine this month, Jean Tillman from Unisys discusses an issue close to my heart – User Interface Design for Web Applications.

Whilst the article is refreshing in its subject matter (you don’t hear a lot of talk of AUI design online), there are quite a few specific practical points in the article that I disagree with. For the last three years or so, my 9 to 5 (and quite a lot of my 5 to 9) has been taken up with specifically designing and building web applications – so on reading some of the points in Tillman’s article I felt the need to respond.

A user might fill out the same form many times (for example, to add several user-IDs to the database), so it’s not important to distinguish which pages have been visited. In cases like this, it’s preferable to specify the same color for the unvisited links as for the visited links so all links look the same.

Whilst I agree that main functions within the application should not indicate a visited status, but in the same breath they shouldn’t be styled as links. People expect to click links to perform major operations – it doesn’t feel natural – they look for icons or buttons. Links tend to be used at a much lower level, like clicking to view the detail of a particular item in a long list of options. In these cases, it’s extremely useful to show which links have been visited within the current session. (“which one did I just edit?”)

So what about using frames in a Web-based application? Some of the problems still apply—but not all. For example, most people wouldn’t bookmark a specific page within an application. […] Same thing for grabbing a URL and sending it to a friend.

Fair enough, Tillman does go on to say that frames should only be considered after thorough usability testing, but the justification for even considering that testing is thin. Remember that frames are not a structural device, they’re a visual device (in fact, they’ve been replaced by CSS). Therefore, the decision to use frames has to be on the bases of visual effect – and when the effect can be achieved with CSS that argument is null and void. The arguments against using frames, as Tillman suggests, are still strong. (More discussion on this in the comments below).

In contrast [to websites], applications (Web-based products) rarely involve searching—except in the online help system, of course. The skills and strategies used to craft search-friendly Web pages aren’t needed when designing an application. Instead, the focus is on ease of navigation and form design.

Try telling a user of a CMS containing 20,000 items of content that they have no search tool. They’ll love you for that, I promise. Search is a well-understood, every-day tool. Users know how to search and expect to be able to search – especially when the volume of content is high.

… the concept of landing in the middle of an application while on the Web generally does not apply. For that reason, it might make the most sense to use the same page title on every page—perhaps indicating the application name and version.

I strongly disagree with this one. Obviously a user isn’t going to land in the middle of an application, but they might return to an application after taking a call and forget where they were, for example. Where’s the first place you look when you’re not sure what you’re looking at on a computer screen? The title bar. I’d suggest a combination of application name and title of the current task.

Designers of Web-based applications, however, may have more control over the target environment, depending on the situation. They can specify a required browser, much like they specify the required hardware or operating system environment.

True, but bad advice on the whole. If you can possibly help it, you should build web applications with the same principals used on a public site where the platform and browser is unknown. Use web standards. What if the IT Manager were to leave, and the new one decide to roll out Linux across the desktop? You know all the arguments – they still apply.

…although the Back button may return to the previous page, it might not execute the associated application code, which could mean some of the displayed data is no longer current. For this reason, some applications provide instructions warning users to avoid these buttons—and even to hide the standard toolbar on their browser.

Please don’t ever do that – don’t go hiding the standard toolbar in preference to writing your application well. Nine times out of ten, the problems caused by resubmitting forms and such can be at least checked for at the application side. It takes a little work, but once that framework is in place it should be easy to implement. Of course it’s advisable to make users aware (either on the interface or in training – or both) that refreshing a page after submitting a form could cause problems, but try not to rely on it. (Modern browsers warn about resubmitting data too).

Apart from those points, I thought the article was good. As I said previously, it’s nice to see some discussion of this topic online. After being a moaning old git when someone else makes the effort, maybe I should put some more of my own thoughts on the subject together.