Coming from web development, how do I approach desktop app usability/design?

Question

When developing a desktop application that has several groups of equally important data and operations, how do you tackle the user interface design?

Most of the web-based apps I've developed have a simple home page with links to each service the app offers. Most of those pages contain lists of items in a database which you can drill down or perform operations on by following "edit" "update" or "delete" type links. Think of the vBulletin user control panel. Menu down the left side, data groups and operations on the right.

I'm now looking into desktop application development and am curious about the most common design idioms. For the above example, I imagine some kind of tabbed interface (like Eclipse with the Java perspective, Subversion perspective and so on), but if the functionality groups are used with roughly equal frequency, the user will be clicking around between the tabs very often. I also wonder whether I want to let the user launch n tabs of the same type, or preload each tab for each functionality group and only allow the user to switch between them.

I suppose it could also be implemented using separate windows for each group of functionality. That leaves the problem of having an out-of-place "home window" which is just a collection of buttons to fire off those windows.

After being a desktop application user for so many years, I'm stumped when it comes to actually building an interface that makes sense and doesn't stand out. I looked to microsoft office, but most of those apps deal with one piece of data (eg. a word document) with many operations, rather than many equally important pieces of data each with unique functionality.

What design principles / idioms do you follow for desktop application development in this situation?

Answer 1

Not sure why you're not getting any answers to this. For what it's worth, you should find many of the answers on this related question helpful.

Answer 2

Having three separate windows for each data group allows the users to see more than one data group side by side (assuming their monitors are big enough), a flexibility that tabs don’t provide. Separate windows also allow you to have different menu bars and toolbars for each data group, eliminating the clutter of a bunch of disabled operations when the user works on any one data group.

Unless your “home” window is more like a dashboard for summarizing and monitoring what’s in the other three windows, you are right to not have one in addition to three windows for the actual data. Instead, allow users to open any window through the pulldown menu of any of the three windows. In place of the ubiquitous Open menu item found in the File menu of most desktop apps, have three Open menu items, one for each data group (e.g., Open Customers, Open Inventory, Open Orders, or maybe just label them Customers, Inventory, Orders). Do not use a cascade menu unless adding a bunch of Open Xs makes your File menu very long; 15-20 menu items are acceptable. Redundant toolbar buttons for opening each window may also be a good idea.

There’s no reason you can’t open all three windows by default when the users execute the program if they indeed use all three equally in a given session. If they tend to use one window per session, you can provide a dialog at start-up (perhaps integrated with a splash window) with command buttons to select the starting window; or you can eliminate the extra step of a dialog by putting three shortcuts in the Start Menu at installation, one for each window. If there are nonrandom variations in what windows are used when, you can alternatively automatically open whatever windows were open in the last five seconds of the previous session. If there are individual differences in window usage, and you have some way of knowing which windows a particular user tends to use the most (e.g., from their job description), then set the default window(s) at installation. If all else fails, provide users with an option/preference to select what window(s) to open at start-up.

One other thing: as a desktop app, use edit-in-place. Don’t make users click an “Edit” link or button to change a database record, like so many web apps do. Let users make the record change right there in the table in which the data is shown. This makes interactions simpler and faster, and reduces the complexity (number of windows) of your app.

Answer 3

http://richnewman.wordpress.com/2007/10/26/user-interface-design-for-business-applications/

Turns out what I'm after is an "MDI" (multiple document interface) even though the documents aren't necessarily of the same type. This article covers some of the common MDI styles and wraps up with a good suggestion.

Answer 4

You might consider writing your application on the Eclipse Rich Client Platform (RCP). That platform would give you the leg-up you need into the world of MDI approaches. Visit the Eclipse RCP home page for more information.