Web Application UI Guidelines?

Tom Davies asks: "Every GUI platform has a document which describes the conventions developers should use when building GUIs with that toolset. There are also lots of good resources for Web site usability (e.g. Jakob Nielsen's useit.com). But what about web -applications-? I am developing an intranet application which is aimed at people who use it every day, not those who stumble on a web site and need to be able to use it immediately. It can have a higher learning curve, but must deliver more 'client/server like' usability. Are there any sites/books which address how to make HTML GUIs for applications?"

Comments

Intranet Privacy

[tedDancin]

I've come across a recent top-list of intranets here in Australia, and had to dismiss it as a joke. Every intranet that I've ever built/worked on has had extremely strict confidentiality clauses etc etc attached with it. It's just the fact that companies don't want a smidgeon of their information out in the open (even to a rating company).

I think software engineering design guidelines would be more appropriate for a web application that anything Jakob Nielsen could come up with. As you know, web applications and websites are two totally different breeds of fish.

Simple answer: Don't

[Twylite]

Ask Google about ui design guidelines for web applications. IBM's Ease Of Use site comes up tops.

But, IMHO, you need to examine your choice of development platform (i.e. "web application") and your methodology. If you have already decided on your platform before determining UI requirements, you have issues.

Quite simply a web application can't deliver the same level of user interaction as a traditional C/S application. HTML (even with JavaScript) does not have a rich widget set for building UIs, which causes most intranet applications to have non-obvious even tedious solutions to common UI problems.

One of the few places where HTML excels is in displaying reports and non-interactive tables. By contrast, it is poorest at interactive tables and dynamic filtering.

Some examples: many applications with long lists have a facility to search-as-you-type, either focused on the list or in a text field adjacent to the list; applications with filter or present options based on another selection draw their data on demand in a C/S model, but in a web application must use submit-and-update or multidimensional JavaScript arrays and transfer ALL values to the client on the first request. Simple elements like menus and toolbars are difficult to get right and keep consistent in a web application.

Re:Simple answer: Don't

[elfkicker]

Agreed.

I've been playing around with Mozilla's XUL a bit which overcomes alot of these problems. It's got a fairly good widget set and I'm sure we'll see it improve quickly. I'm not sure I'd want to invest in a whole intranet worth of XUL, but it might be good for some smaller applications if you can get your users using Moz. I wonder if anyone's thought of doing an IE plugin for XUL apps... prolly not much demand for it, but I hope that changes.

Re:Simple answer: Don't

[fuzzbrain]

I agree with the above post. If you have an intranet and a complicated application then you may as well provide your client machines with a downloadable application (this can be done through the intranet site using something like Java Webstart). That being said, if you really MUST provide a web-based applictation, I'd recommend taking a look at the Echo Web Application Framework. I haven't played with it much but it purports to allow one to produce HTML-Javascript applications using Swing style programming.

Re:Simple answer: Don't

[Twylite]

But why do you want a web based application (with or without Java applets) to begin with? The Web provided a common platform, ease of delivery to remote clients (and by extension ease of maintenance), and an easy display language for simple presentations.

The value proposition of the Web is now significantly reduced in light of alternative technologies. Java, Tcl, Python, Perl and numerous others provide a common platform. Most either provide or easily permit a stub architecture for downloading the application from the server on the fly, negating the traditional remote maintenance problems of C/S software. Visual "builder" IDEs are commonplace.

These languages offer a powerful set of GUI widgets which beat DHTML on interactive use, and have proper RPC mechanisms (with several standards to choose from) rather than the submit-and-retrieve model that limits web applications.

Where a web application can use DHTML and XML to transfer a table, a Java application can address the remote table object as if it were local, or transfer the object to the client implicitly, at no development cost.

You want client/server?

[GeckoX]

Then write a client and server. Web browsers are NOT good substitutes for a client, there is no proper state or environment to do any proper work in on the client, and seeing as you have already specified that you need higher level client/server functionality, well then you answered your own question.

I am so sick of seeing browsers forced to do things they just don't, can't and shouldn't do. It's NOT the catch all wonder solution. Christ, writing a freaking VB client is at least as much a joke as writing a web page.

Do the write thing, don't follow the lemmings.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Web desktops?

[cr0sh]

Something that I remember seeing a while back, then it just up and died, with no fanfare - was web "desktops". Does anybody here remember the desktops that showed up in a browser, and used a combination of javascript, html, possibly css, and cgi to create a windowing desktop within the browser?

Today, such applications are much easier, and with Mozilla at least (XUL, etc), should become more common.

My question is, what happened to the early stuff? Some of it was amazing and fascinating, even if a bit crufty. I assume it died off because it just didn't catch on, or it really wasn't up to the task of better (read: full blown) applications. But the idea of having a remotely accessible desktop anywhere, web based, etc - seemed interesting (and yes, I know about VNC, as well as X)...