Basic GUI
- What kind of data need to be input/output?
- What type is each datum?
- How is it read?
- From disk
- From user input
- from serial port
- etc, etc
- How will the data be output?
- to a file
- to the screen
- to the serial port
- to a database
- etc, etc
- Who will use the application?
- the author:
If you are designing soley for yourself, with no intention to ever distribute the
software, you can skip a lot of the error handling, bells and whistles and
niceties you will need for more general software. The interface can be rough and
ignore all guidelines.
- a select group with certain skills:
Their skills need to be taken into account when designing error handling, etc.
For instance, software for technical professionals can have more terse, albeit
direct, error messages, etc. Software for secretaries probably can't. The interface
should be fairly polished, although general guideline considerations might be
set aside for specific group considerations.
- general user:
Error handling should be copious, informative and consistent. The interface
should follow general guidelines for whatever windowing system it is meant
to be used under. There should be an attempt to follow accessibility guidelines
(more about these below).
- How should the application look?
- In some cases this is a matter of personal preference
- Greatest utility is also important
- Sticking within the guidelines/framework is important as well
- If possible, make it intuitive
- Test the look on others, technically minded and not technically minded
if you are building an application for others
Gnome has guidelines for applications. While you do not have to follow these
they are what makes the desktop seem unified. They also have accessibility
guidelines, which are very important if you are building an application that
might have handicapped users.
KDE has design standards as well. They can be found here.
Be consistent with what you present in the application, consistent with how
it is presented, consistent with the desktop environment's guidelines. Handle
errors in a consistent, predictable manner. Present data in that way.
As a coder, the natural instinct is to make the GUI follow the code. For instance
the code might contain a branch where something is decided. This need not be
necessary for the user to see, but it is necessary for the code flow, so we tend
to include it in our GUI. Try to avoid making things more complex this way.