Opentaps User Interface Guidelines

From Opentaps Wiki
Revision as of 01:02, 12 December 2009 by Sichen (talk | contribs) (Protected "Opentaps User Interface Guidelines": Sysop page [edit=sysop:move=sysop])
Jump to navigationJump to search

Good user interfaces do not have to be flashy or colorful--there was good (and bad) user interface in the days of the 80x24 green screen terminal. Instead, the key to creating good user interfaces is to focus on the user and his needs. These are some suggestions on how to make your user interface better.

Design interfaces for your user, not your framework. Think about who would be using application and how your application could be easier for them to use. Then think about how best to write the interface for them. A framework or set of tools like the opentaps Form Macros might help you, but in the end, it should not dictate how your interface should look.

Write for your users, not your tables. User interfaces should follow what users do, and if several tasks end up working around the same tables, then have several different screens, one for each task. For example, writing an email versus logging a phone call may both involve the same tables, but they are different tasks which require different screens. Similarly, creating a new customer may require working with a dozen different tables, but updating those tables is something your program should do, not the user.

As few fields as possible. Keep it as simple as possible. Don't show the user fields which are not actively used by the system or whose meaning could be inferred from other fields.

Use intelligible labels. "Party ID" is not as understandable as "Customer". NEVER create a form button that says "Submit", unless your form is for submitting college applications. Your form should have buttons that say "Find Order" or "Create Order".

Tell the user which fields are required. If a form field is required, use the "requiredField" css class to mark it red so the user knows.

Never say null. Always check for potential null values, both in your code and on your screen forms, so the user does not see a big null pointer exception.

Bulletproof your UI. If the user fills out a form which causes certain action, check and validate the users' input and make secondary changes to make sure the user doesn't get foreign key exceptions and such. For example, if a roleTypeId is required, then run "ensurePartyRole" first and add that role for the user before trying to insert into the table.

A little color goes a long way. Some color will help make your application more appealing and also help people better understand what's going on, but too much color will confuse or overwhelm (or even blind) your users. When in doubt, use a lighter shade of the color you're thinking about. Don't bold unless you really mean it.

Don't send your user running around. If a customer service rep needs to see invoices, then create an invoice page for them in the application they are using (like CRMSFA); don't make them get into the accounting application.

Can you explain it? Sit down and write a manual for your application. If you can't explain how to use your software in simple terms, then your user interface is too complicated.