The Goals of UI
The basic goals of a user interface are easy to understand:
1. Be easy to use
2. Look nice
Number 1 is more important than Number 2.
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.)
3. Attach a screen shot or mock-up of whatever ideas/changes you have.
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.
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.
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
Databases have certain principles of design. Object-oriented code (which is what Bugzilla uses) also has certain principles of design.
These are not the same as User Interface design principles. You shouldn't be displaying information to users in a certain way just because it's layed-out in the database a certain way. You also shouldn't be displaying information to users in a certain way just because your objects are designed in a certain way.
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.