Sigh, why does everyone think that their pet UI preferences are the right way to do everything. Over the years I get people telling me:
1) I love the large icons. I hate the large icons
2) Make the enter key view books/make the enter key edit books
3) I hate these icons/I hate those icons/I love these icons/I love the new icons/I love the old icons
4) I love the single key shortcuts, lets me launch actions pressing only one key. I hate the single key shortcuts, they're not what I'm used to and I refuse to learn something new, even if its better
6) This program doesn't follow the UI guidelines X. This program doesn't follow the UI guidelines Y. This program doesn't follow the UI guidelines Z.
7) This option needs to be more obvious. That option needs to be more obvious. The third option needs to be more obvious. At the same time the interface needs to be less "cluttered" and more "coherent".
Guidelines for armchair UI designers:
1) What you think is good UI design depends entirely on what kinds of UI you are used to. calibre is used by *millions* of people, with literally hundreds of different "optimum" UI experiences. Be aware of that.
2) calibre design goals are to be simple to use while not hiding the power under the hood and keeping code duplication to a minimum. If you want to make a proposal for UI change, it has to be congruent with those goals.
3) Make small, concrete proposals. So, make the topmost cover in the cover browser clickable is a good proposal. The UI lacks coherence is not, it's not even a proposal.
4) Never, *ever* try to present your proposal by dressing it up as, "Most users expect this". That is just going to make me laugh and expose your ignorance. The fact that *you* expect something, most emphatically does not mean that *most* people expect it.
5) Stop to think what your proposal means to the larger picture. Realize that UI design is at the most fundamental level a trade-off. When you do something one way, you gain some things and you lose other things. I will be much more inclined to listen to a proposal if it is accompanied by an acknowledgement of what implementing it costs.
6) When some aspects of calibre is not the way you think it should be, stop to realize that there are almost always good reasons for it to be that way. Those reasons may not be obvious too you, but they exist. So instead of saying "This behavior is wrong and must be like this" say instead, "Why is this behavior like this, to me it seems like it should be like this".
7) Be humble. You may be an uber hot shot software developer/genius/god/graphics designer/wise guy, but you *do not* know what is best for calibre, better than its creator does. You may well have good ideas, but present them as such, ideas.
8) Remember that calibre development is done by volunteers. So do not expect your pet concerns to be addressed/responded to, unless one of those developers has the time/inclination to do so. And you will greatly enhance that inclination by following the previous 7 guidelines.
|