GUI design style guidelines?

[IPguy]

What GUI design guidelines do you use when creating a program for commercial sale?
Is there a set of best practices that are commonly used?

[Leledumbo]

Not a specific one, I just position myself as the user so I can imagine what he would feel when using my software. One thing I always keep in mind is to have my software's interface as intuitive as possible since many users don't like reading documentation. Instead, they usually ask me to teach them how to use it. By creating intuitive interface, they could quickly use the software without asking me too much about how execute a task.

[felipemdc]

What GUI design guidelines do you use when creating a program for commercial sale?
Is there a set of best practices that are commonly used?

I don't remember any set of positive rules which where really good, but there is the Interface Hall of Shame: http://homepage.mac.com/bradster/iarchitect/shame.htm

Basically don't make stuff that blinks, or text that blinks, this is horrible. Avoid strong colors. Make sure that your text and background colors contrast so that visually impaired people can also use the software.

I think that the most important is simply testing. Take your app to someone without much knowledge of computers and let him try to use it. If this person has major problems using it, then you might need to redesign something.

I think it is a cyclic task. You start with something and then you adjust it when you find out that users have problem with any item.

[jwdietrich]

In additions to the good suggestions above it might be advisable to implement the UI guidelines for the respective operating system.

See e. g. for Mac OS X: (http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html)

and for Windows:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=2695

[mdalacu]

Also for GNOME:
http://developer.gnome.org/hig-book/3.2/

[vvzh]

Here is one for KDE:
http://techbase.kde.org/Projects/Usability/HIG

[lainz]

When you finally got the style don't forget to test it using different themes, font sizes in the target OS.

For example ubuntu has an option to change the system font size without need to restart, in windows is different, you need to log off the user account to apply the changes in font size (High DPI).

In the Windows User Experience Interaction Guidelines say something about High DPI but you can read some more things in the wiki ( http://wiki.lazarus.freepascal.org/High_DPI ). And some about icons in Windows ( http://wiki.lazarus.freepascal.org/Windows_Icon ).

[ssamayoa]

I found an execllent book named "Dont make me think".

http://www.sensible.com/dmmt.html

Is focused in web applications but applies to any kind of application.

Is not just about rules on how to size, position and color the components,  is about to get into mental model of your intented audience (user).

Look at this article wrote by Joel Spolsky: http://www.joelonsoftware.com/uibook/fog0000000249.html

Little old but still valid.

Regards.

[Ocye]

To add one more style guide, "open source" (whatever this means in terms of a guide) and intended for cross plattform use: http://wyoguide.sourceforge.net/. I would recommend to follow Microsoft's UX guide, mentioned by jwdietrich. If you look for best practices you should search for Design Pattern. E.g. http://www.cs.helsinki.fi/u/salaakso/patterns/index.html or http://ui-patterns.com/.
A well-designed application is more than just to follow some rules. Take into account to ask experts to do it for you.

[TurboRascal]

In additions to the good suggestions above it might be advisable to implement the UI guidelines for the respective operating system.

This actually raises an interesting question - Lazarus is crossplatform, so which of the guidelines (four of them are cited) should be followed if the application compiles on four different desktops/widgetsets and it has the same layout in all of them?

I agree some common sense should be followed and everything should be made as intuitive as possible regardless of the type of graphical interface it uses; however there are some real practical differences between the guidelines, for example on some systems buttons are ordered like OK then Cancel, Yes then No, but on others ordering them vice versa is the norm...

[jwdietrich]

Actually, in the process of software development we have to trade off between coding efficiency, i. e. using one source code for multiple platforms, and the principle of minimal surprise on the respective platform.

Fortunately, Lazarus takes its principle "Write one, compile anywhere" serious: The platform-specific widget sets exonerate the developer from writing platform-specific code. However, there are a few points, where some requirements of the respective operating system have to be met. Apart from the ordering of buttons mentioned by TurboRascal this applies e. g. to menus.

As an example, on Mac OS X there is an application menu on the left which holds entries for an about box, preferences, some global OS-wide services and quitting the application. Under Windows and most Linux GUIs however, the about box is accessible from the help menu and the preferences entry often has differing locations. Additionally the modifier keys are not identical on different platforms. It is the command key (apple key) on Mac OS X and iOS, while it is the ctrl key on Windows and Linux.

How can we adapt to these restrictions and simultaneously keep one source code?

In my applications I have solved this with conditional compiling. To take an example from SimThyr, I have defined a menubar with both an application menu for the Mac (defined with the apple-logo) and a help menu for all platforms but with different entries with respect to the OS. The procedure AdaptMenus that is called early in the run of the application performs the assimilation process:

Code: [Select]

procedure AdaptMenus;
var
  modifierKey: TShiftState;
begin
  {$IFDEF LCLcarbon}
    modifierKey := [ssMeta];
    SimThyrToolbar.WinAboutItem.Visible := false;
    SimThyrToolbar.Divider_5_1.Visible := false;
    SimThyrToolbar.Divider_2_2.Visible := false;
    SimThyrToolbar.Divider_2_2.Visible := false;
    SimThyrToolbar.WinPreferencesItem.Visible := false;
    SimThyrToolbar.AppleMenu.Visible := true;
  {$ELSE}
    modifierKey := [ssCtrl];
    SimThyrToolbar.WinAboutItem.Visible := true;
    SimThyrToolbar.Divider_5_1.Visible := true;
    SimThyrToolbar.Divider_2_2.Visible := true;
    SimThyrToolbar.WinPreferencesItem.Visible := true;
    SimThyrToolbar.AppleMenu.Visible := false;
  {$ENDIF}
  SimThyrToolbar.NewMenuItem.ShortCut:=ShortCut(VK_N, modifierKey);
  SimThyrToolbar.OpenMenuItem.ShortCut:=ShortCut(VK_O, modifierKey);
  SimThyrToolbar.CloseMenuItem.ShortCut:=ShortCut(VK_W, modifierKey);
  SimThyrToolbar.SaveItem.ShortCut:=ShortCut(VK_S, modifierKey);
  SimThyrToolbar.QuitMenuItem.ShortCut:=ShortCut(VK_Q, modifierKey);
  SimThyrToolbar.UndoMenuItem.ShortCut:=ShortCut(VK_Z, modifierKey);
  SimThyrToolbar.CutMenuItem.ShortCut:=ShortCut(VK_X, modifierKey);
  SimThyrToolbar.CopyMenuItem.ShortCut:=ShortCut(VK_C, modifierKey);
  SimThyrToolbar.PasteMenuItem.ShortCut:=ShortCut(VK_V, modifierKey);
   SimThyrToolbar.RunItem.ShortCut:=ShortCut(VK_R, modifierKey);
end;                   

This is a quite simple way to provide both platform-conformity and keeping one source code for all platforms.

[Ocye]

Of course you should follow system style in that case. Lazarus offers access to standard dialogs, so use it.
On the other hand most aspects regarding interface and interaction are equal across OS. One of the first guideline from Smith and Mosier [1] is from 1986. And it's still valid.

[1] http://hcibib.org/sam/

[jwdietrich]

[1] http://hcibib.org/sam/

That is a very interesting resource. Is there a PS or PDF version available?

[Ocye]

Is there a PS or PDF version available?

http://www.userlab.com/Downloads/Smith_Mosier_guideline_.pdf

[jwdietrich]

Great, thanks!