canmove, Confirmed users
345
edits
Bugzilla:UI Design: Difference between revisions
Add multiple sections about viewpoint and people.
(Add multiple sections about viewpoint and people.) |
|||
| Line 10: | Line 10: | ||
That's not so hard, is it? | That's not so hard, is it? | ||
== Some UI Design Tips == | |||
Here's some information to keep in mind when you're making a UI: | |||
1. People shouldn't have to read the manual to use your UI. If they have to read the manual, the UI is too complicated. | |||
2. Cramming a bunch of stuff on one screen isn't a good UI. The fewer things there are for somebody to look at, the less confused they will be. Of course, this should be balanced with the power user's desire to do lots of things at once. (Balancing these two factors is the major trick of brilliant UI design.) | |||
== Power Users vs. Normal Users == | |||
Remember that Bugzilla has a larger percentage of power users than most applications do. | |||
But things like the front page, the search screen, the bug entry page, and the search results list should all be designed with "normal users" in mind, as those are the pages that are most-commonly used by people who aren't power users. | |||
Also, the bug details page (show_bug.cgi) should be ''understandable'' to a normal user, because people want to ''read'' bug reports. For actual bug editing, it's OK to expect users to be power users, as people who frequently edit bugs are power users of Bugzilla. | |||
== Viewpoint == | |||
In general, you should imagine yourself as a normal user, and look at your UI. Imagine yourself as a brand-new user, one who doesn't know anything about Bugzilla at all. Is your UI understandable? Can it be figured out in a few seconds? | |||
Don't be arrogant and assume that you are so important that all users should read your manual in detail. Have a little humility, be nice to people. Make things easy for them to understand. | |||
Don't be afraid of being "too simple" or "too easy to use." There's no such thing. You won't insult people by being "too easy." You ''will'' upset people by being too complex. | |||
== Words == | |||
Don't say "Oh, everybody knows what 'Flags' means." ''No, they don't.'' | |||
'''PEOPLE DO NOT MAGICALLY KNOW THINGS THAT YOU HAVEN'T TOLD THEM.''' | |||
New users definitely do '''not''' know the meaning of "flag", "resolved", "verified", "classification" and so on. | |||
They may not know the definition of "product" and "component", particularly if they don't use those terms internally at their company. (There are many organizations that have no idea what "component" means in Bugzilla, and one of their first customizations is to rename it to something that makes sense for them internally.) | |||
They '''do''' know the meaning of "Home", "New", "Search", and "Preferences." These words are used in many other programs. If they don't know these words, they need to take a basic computer class, and we're not here to give them a basic computer class. | |||
In general, if it's not a totally basic English word, or if it's not a word used in lots of other programs, maybe you should provide help (a tooltip or something similar) or just ''don't use the word.'' If you have the choice between a plain-English sentence and a single complex word, choose the sentence. | |||
== UI Design Is Not Code Design == | == UI Design Is Not Code Design == | ||
| Line 18: | Line 56: | ||
As a simple example, Bugzilla has both a Status and a Resolution field in the database. But it's OK to display them both together as part of the Status field, even though they're actually separate in the database. | As a simple example, Bugzilla has both a Status and a Resolution field in the database. But it's OK to display them both together as part of the Status field, even though they're actually separate in the database. | ||
Bugzilla developers call the stuff at the bottom of the Advanced Search page "Boolean Charts", but there's no reason that it has to be called "Boolean Charts" in the UI. I mean, come on, who knows what "Boolean Charts" means? | |||
Generally, don't be limited in your design by how your code works. | Generally, don't be limited in your design by how your code works. | ||