A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I like to think I have a decent nose for usability, at least at the detailed level. But I frequently struggle with deciding on the best way of organizing the top-level forms in a desktop application.
For example, for a database-oriented data management app, like CRM or small business management, there's no single "document" to work on like there is in the traditional Windows app like Word, Excel, Paint, etc. I guess there's the "Access model", with a "switchboard" form that fires off a bunch of independent windows for different sections of the domain, but I've never really cared for that interface paradigm. It doesn't seem to follow the current Windows UI standards in a way that's hard to define.
Right now I'm thinking in terms of Outlook, with a big toolbar down the left of the screen with buttons for the main areas of the program (Customers, Inventory, Appointments, or what-have-you, and then on the right side, a dynamically-selected user control to manage the data involved in that area. I'm not 100% satisfied with this model either, but at least it's similar to a UI that's familiar to many users (Outlook).
Any other thoughts on interface patterns for this kind of data-oriented application, or links to references about UI best practices at the forest level, rather than tree level (like most UI books)?
Monday, November 20, 2006
If all you have is a hammer, everything looks like a nail.
Don't start with the solution. Understand the problem.
Your software will be better only if its better for the user from the user's perspective. Your evaluation of it is irrelevant.
How does the user think about his problem? What is his natural or customary sequence of operations? What information must he have available to make the choices he must make? What views of the information are really important for the user getting his job done?
Once you understand the user's universe, you can make a tool that fits it. Until then, all you are doing is stroking your own ego.
+1 to Lionell K. Griffith.
You've mentioned Customers, Inventory, Appointments how will they work with these? Is there a workflow or are these items they will pick and choose as the need arises.
The switchboard approach is dodgy, you are forcing your users to keep coming back to the switchboard each time they want to do anything and if its modal, they'll have to close everything else down and if its not, how will they access it easily when its covered by other forms. What if they close it, how do they get it back? This soon becomes painful.
As for the outlook approach, my problem with this is deciding what the default view should be. If this requires data from the database then the app may not open as fast as it could because it needs to visit the database. If its just blank then why is it there anyway we're back to the switchboard design.
There are other approaches to solving this for which I would would heartily recommend The essentials of interaction design by Cooper & Reinmann and Jennifer Tidwell's book Designing Interfaces.
All the best.
Tuesday, November 21, 2006
One of the most innovative approaches I have to seen to this is this sort of approach:
The main window is a diagram of the workflow, with each stage an icon that can be clicked on to get to the related screen. Attractive, intuitive and easy enough to program.
Tuesday, November 21, 2006
In my opinion an understanding of the business process the software is meant to support would provide a number of benefits:
Provide an understanding the flow of information and decision making;
Elucidate non-functional requirements;
Aid architecture and design of the software.
Ammonianovice is right that a switchboard approach can add work by forcing additional navigation. Unless the user can complete a good chunk of his/her tasks in the switchboard window itself (e.g., it includes records and fields for manipulation), or must look at the switchboard to decide on the next task (e.g., it includes a summary of the statuses of their work), this may not be the approach for you.
The Outlook approach avoids navigating back to a “home” window, but the toolbar on the side consumes real estate that may actually not be used too often, depending on your tasks. Also there are often significant advantages, especially for exceptional tasks, to allowing the user to have multiple forms displayed at once. You should even consider the advantages given your users' tasks of allowing the user to display multiple instances of the same form only differing by query criteria. The Outlook approach doesn’t allow that.
Why not put on every form a pulldown menu of all forms available to the user? Selecting from the menu opens a new instance of the chosen form for a default or user-supplied query criteria. This eliminates navigating back to “home” (there is no “home”), consumes no additional real estate (assuming you have a menu bar anyway), and easily accommodates multiple instances of the same form. For a given user group, you often know the task the user’s is most likely to want to do when starting the app, so I would open populated forms for that task at start-up. If you really don’t know, then your app can open with a switchboard-like dialog box to choose a form in order to get the user going.
Take what others have said to heart and let your analysis of the tasks/business flow drive the design. Make some sketches of the UI using these three approaches and analyze each for completing the users’ tasks as quickly and conveniently as possible.
Tuesday, November 21, 2006
In my Delphi/MySQL CRUD framework, I have had success with my users by combining the Outlook style navigator with a 'task-based' home page for each module, moving the most commonly used functions to the front.
Each module has a 'Home' page, and the application has a 'Home' page. There are no blank screens while the user makes up their mind about what they need to do today.
The problem with the Outlook style menu is that while the navigation makes sense to most users (in my experience), they can feel overwhelmed by the number of options available if they go 'menu-diving'. Not wanting to reinvent the wheel, I use roles to customize access, to reduce the number of options available.
To free them of having to use the menu. Users can 'bookmark' their most-used 'links' on their Home. So when they log in, they can quickly jump to the functions they need, and can get back to their 'Home' with a click. They seem to really like this, they feel like they have some 'control' over their application :)
When Judy in Accounts Receivable logs in, she has on her Home under her 'Common Tasks' section: Credit Lookup, Invoice Search, Customer Maintenance, Reminders, etc... while John in Shipping has Create Waybill, Search Packing Slips, etc... They may have access to many of the same system objects, but typically they are accessing 5 or 6 common functions in a day. If they have to click too much, they get frustrated.
Something often forgotten by programmers these days are 'Function hotkeys'. This is on my top ten list of things that come as requests a few weeks after the system is implemented. I built this capability into my base UI 'home page' class and store the keys with the user profile.
There are probably better ways to organize a UI for business apps, but my users like it, being familiar with Outlook, home pages and the concept of bookmarks.
I do like the idea of implementing WorkFlow concepts into the system in the future, and would like to go in that direction, perhaps even graphically representing the flow... we'll see what the users say. Managers may like it, certainly, but will the actual users want to use it? If it gets in their way of dealing with the electronic objects that mirror/track the real world tasks they need to do, however pretty it may be, that would be a big failure.
Whatever the design, the bottom line is that if your users find it easy to use, then you have done your job. If people find it confusing or tedious to use, even if the interface is beautiful and the data immaculate, then you have failed to do your job well.
I still code in Delphi
Tuesday, November 21, 2006
Thanks, lots of good stuff to think about here. Andy, that ranching program's workflow GUI is interesting, although I notice they also have a toolbar at the top with big navigation buttons as well.
I like "I still code in Delphi"'s user-based "dashboard" approach for large enterprise-scale applications, but I'm not sure that it would work for smaller apps. Although I suppose you could have one application with separate user-based presentations for POS vs. back office tasks.
I think one point in favor of the toolbar along the top or side has is that it's familiar to users, not only from Outlook, but from many web page interfaces.
I've added the Jennifer Tidwell book to my reading list. I already had Cooper's "About Face" on the list, but I saw that he has a 3rd edition coming out in April, so I'll probably wait for that.
Saturday, November 25, 2006
You're talking about what Alan Cooper calls the software's "posture." That's sort of a combination of a mode of operation and set of UI conventions. Things like Outlook's 3-pane UI are appropriate for some things, stuff like Access' multi-doc UI are appropriate for others. It really depends on what your software does, who's going to use it, and how often and how engaged they are going to be while using it.
Check out Cooper's "About Face" for good info on this. You might want to hire a UI person to think about this stuff full-time. Don't just go with your personal preferences or your gut instincts here. This is a fundamental decision about your product.
Thursday, December 07, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz