
|
[openbeos]
||
[Date Prev]
[07-2003 Date Index]
[Date Next]
||
[Thread Prev]
[07-2003 Thread Index]
[Thread Next]
[openbeos] Re: UI Guidelines (was: very long topic)
- From: "Matthijs Hollemans" <matthijs@xxxxxxxxxxxxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Thu, 3 Jul 2003 14:56:45 +0200
From: "DarkWyrm"
> When designing an application, the main thing is (1) to figure out
what
> the goals of the application are, and (2) design the application's UI
> in such a way as to not hinder the user in performing tasks, if not
> make the user's tasks easier. It's part art, part science, part
> experience, and part testing. [...]
There are two different "levels" at which you can discuss UI design
issues:
1) designing the user interface so it becomes a joy to use
2) making the UI consistent with the other apps in the system
When I talked about UI guidelines earlier, I did not mean #1. As
DarkWyrm said, designing a great UI is as much of an art as it is
science. Giving out guidelines for this will be very hard, especially
because the situation will be different for every app. (Tip: read Alan
Cooper's "The Inmates Are Running The Asylumn" to learn more about
this.)
But it is very well possible to make guidelines for situation #2. The
devil is in the details, and this is about the details. For example,
where do the OK and Cancel buttons go in a dialog box? Do they go at the
bottom or at the right? What order are they in: is OK on the left or on
the right of Cancel? And so on...
These are small issues, but if every app does them differently chaos
ensues. The bevel-around-the-background-box-or-not issue that was
mentioned on this list a few days back also falls into this category.
These "UI rules" should be considered a checklist. Good developers will
run down this list before they release their app, just to make sure it
is top-notch quality. (Tip: read Alan Cooper's "About Face" for more
about these kinds of issues.)
An analogy to coding style: you can make rules for syntax -- what the
OpenTracker coding standard does -- which corresponds to my #2. But
would you make rules for how to design the class architecture (number
#1)?. There is a big difference between the two. Likewise for UI design.
-Matthijs
|

|