Difference between revisions of "GUI design"

From Lazarus wiki
Jump to navigationJump to search
(moved from discussion)
 
(42 intermediate revisions by 8 users not shown)
Line 3: Line 3:
 
==Overview==
 
==Overview==
  
When working on lazarus, certain design guidelines need to be taken into consideration. To prevent a diversity of styles and ensure the clarity of dialogs. The next article tries to summarize several guidelines to help you designing. But first it starts with a number of screenshots that propose the new Look and Feel for Lazarus
+
When working on lazarus, certain design guidelines need to be taken into consideration. To prevent a diversity of styles and ensure the clarity of dialogs. This article tries to summarize these guidelines to help you designing. There is also a buch of screenshots, artwork and dialog information available.
 
 
==Look and Feel==
 
This paragraph show several examples of look and feel concepts for Lazarus. On the right side is the current layout shown. Please comment...
 
 
 
General features are;
 
* each dialog has a help button (currently disabled) that will show a help page (hint: the Lazarus help system is format independent, so normally it is sufficient to add a unique help path, like 'IDE/CodeExplorer/RefreshButton')
 
* all modal shown forms are bsSizeToolWin, non-modal shown forms are bsSizable
 
* to make Lazarus easier for non english speakers it is recommended to use button glyphs whenever you have a good icon.
 
* all main controls are accessable with access keys ie. "&Cancel". TODO: What about translations? Per language the access keys have to be determined.
 
 
 
 
 
[[Image:Todo.png]] [[Image:Todo_old.png]]
 
 
 
The todo form shows a typical form with buttons. Instead of stretching the buttons across the entire clientwidth (code explorer, project inpector, etc.) a toolbar on top is shown with labeled buttons.
 
 
 
 
 
[[Image:UnitInformation.png]] [[Image:UnitInfo.png]]
 
 
 
This form shows a typical information dialog. Notice the notebook that splits the information, so that there is not too much information at the same time visible.
 
 
 
 
 
[[Image:FindReplace.png]] [[Image:FindReplace_old2.png]]
 
 
 
This form shows a typical dialog. Captions before controls are right aligned (not well visible in this example though) and the options are grouped under bold labels.
 
 
 
==Lazarus art work==
 
 
 
Here prototypes for new Lazarus artwork will be shown.
 
  
 +
* [[GUI design guidelines]]
 +
* [[Screenshots / examples]]
 +
* [[Lazarus dialogs information]]
 +
* [[Lazarus art work]]
  
 
==Comments==
 
==Comments==
 
+
=== Cross platform ===
What you need to keep in mind is the cross-platform nature of Lazarus.  If you make all the changes you suggest, the text on the buttons won't be visible in most standard GTK+ themes, or there will be other problems.  I fully support the idea of some tweaks like this, but it should be tested in Linux, Win32 and even in MAC (you guys are running it in MAC already, right?) before it's committed.
+
What you need to keep in mind is the cross-platform nature of Lazarus.  If you make all the changes you suggest, the text on the buttons won't be visible in most standard GTK+ themes, or there will be other problems.  I fully support the idea of some tweaks like this, but it should be tested in Linux, Win32 and even in Mac OS X (you guys are running it in Mac OS X already, right?) before it's committed.
 
-[http://wiki.lazarus.freepascal.org/index.php/User:Tonymaro Tony Maro]
 
-[http://wiki.lazarus.freepascal.org/index.php/User:Tonymaro Tony Maro]
 
:That's the only way to do it ;). I have patches of the different dialogs and I would encourage people to test them and post screenshots here. - Darius
 
:That's the only way to do it ;). I have patches of the different dialogs and I would encourage people to test them and post screenshots here. - Darius
  
==Dialogs==
+
=== CAFE standard ===
Dialogs are special forms that need the user to make / change some setting before lazarus can continue.
+
I found these ideas on form designs very interesting.  If you can, I would be grateful if you could visit http://www.nvtech.com.au/ProjCurr/CAFE/CAFE.html to read about a convention called CAFE; standing for "Common Application Front End".  
 
 
 
 
===Dialog Settings===
 
Settings that should be applied in general are;
 
 
 
* '''BorderStyle''' : bsSizeToolWin
 
* '''Position''' : poScreenCenter
 
* '''FormStyle''' : Do not use fsStayOnTop, as this can be pretty annoying under some window managers.  
 
 
 
Show the dialog using ShowModal
 
 
 
===General layout===
 
* On the bottom all required buttons to close / cancel the dialog, or to recieve help should be placed
 
* The dialog should work on a screen of 800x600. 640x480 is not needed to support.
 
* Close on Escape (if key not used otherwise)
 
* Define default button and Return activates it (if key not used)
 
* All but the most simple dialogs should be resizable and size is stored
 
 
 
====Button panel====
 
The button panel should consist at least of the following elements;
 
 
 
* OK button (or better: a describing text like 'Save' or 'Rename')
 
* Cancel button
 
* Next button (optional)
 
* Previous button (optional)
 
* Help button
 
  
An example is shown below:
+
The intention of CAFE is not so much to have attractive forms but to have ones that reduce:
 +
* training required for application users,
 +
* effort required to input data and navigate around the application, and
 +
* the chances of a user accidentally inputting incorrect data.
  
<center>bottom panel.jpg</center>
+
The keypoints of the CAFE standard are that it requires each form to:
 +
* have a menu of options displayed (ie, not drop down menus or other hidden features)
 +
* be capable of being driven by both keyboard and pointing device with the option selection being done primarily by using numbers typed into the number pad on a conventional keyboard (tests have shown that clerks using the keyboard and number-pad are 60% faster than those that have to take their hands off a keyboard to use a pointing device.)
 +
* have a field devoted to "form help" which tells the user the purpose of the form and a field devoted to "field help" which changes as focus moves from field to field on the form.  The "field help" informs the user of the purpose of the field and the input into that field which is acceptable.
  
===Anchoring===
+
If all contractors wrote their applications to conform with the CAFE standard, not only would it ensure an application that was best for business, but it would also allow many different contractors to participate in software development with all applications having exactly the same look and feel and so giving the perception they all belonged to one coherent applications suite.  This would be good for everyone.
To make sure that a dialog after resizing will keep on showing the components in a good way, anchoring is being used. Each components has a property called Anchors. With this property you can determine the way a component is anchored to it's parent.
 
  
Hint: Use the anchor editor of the IDE.
+
I hope you find these ideas interesting.
  
===Aligning===
+
Kevin Loughrey
Another way to organise components is using alignment. Each component has a property Align. By selecting the appropriate align position several components can be positioned properly.
 
  
====BorderSpacing====
+
CEO Non Volatile Technologies Pty Ltd
Especially useful in combination with Align is the BorderSpacing property. (Also found on the Anchors dialog). A typical borderspacing of 6 pixels around a component is used.
 
  
==Dialogs to be converted to LFM==
+
(NVTech supports and promotes the use of Open Source Software as a means of accelerating societal advancement throughout the world.)
<strike>Striked items</strike> are already converted.
 
  
'''Bold items''' are being worked on
+
== See also ==
 +
* [http://www.lazarus.freepascal.org/list_archives/lazarus/msg08842.html Lazarus look and feel, 16 Jul 2005] Related discussions on the mailing list
  
* '''/lazarus/ide/addtoprojectdlg.pas''' <D. Blaszijk>
+
[[Category:Artwork]]
* /lazarus/ide/buildlazdialog.pas
+
[[Category:Guidelines]]
* /lazarus/ide/clipboardhistory.pas
+
[[Category:GUI]]
* /lazarus/ide/codetemplatedialog.pp
 
* '''/lazarus/ide/codetoolsdefines.pas''' <D. Blaszijk>
 
* /lazarus/ide/codetoolsoptions.pas
 
* /lazarus/ide/compileroptionsdlg.pp
 
* <strike>/lazarus/ide/diffdialog.pas</strike>
 
* <strike>/lazarus/ide/diskdiffsdialog.pas</strike>
 
* <strike>/lazarus/ide/editoroptions.pp</strike>
 
* <strike>/lazarus/ide/environmentopts.pp</strike>
 
* '''/lazarus/ide/exttooldialog.pas''' <D. Blaszijk>
 
* /lazarus/ide/exttooleditdlg.pas
 
* /lazarus/ide/findinfilesdlg.pas
 
* '''/lazarus/ide/findreplacedialog.pp''' <D. Blaszijk>
 
* <strike>/lazarus/ide/helpmanager.pas</strike>
 
* /lazarus/ide/inputfiledialog.pas
 
* /lazarus/ide/keymapping.pp
 
* /lazarus/ide/macropromptdlg.pas
 
* /lazarus/ide/mainbar.pas
 
* /lazarus/ide/makeresstrdlg.pas
 
* <strike>/lazarus/ide/msgview.pp</strike>
 
* <strike>/lazarus/ide/newdialog.pas</strike>
 
* '''/lazarus/ide/newprojectdlg.pp''' <D. Blaszijk>
 
* /lazarus/ide/patheditordlg.pas
 
* <strike>/lazarus/ide/projectinspector.pas</strike>
 
* <strike>/lazarus/ide/projectopts.pp</strike>
 
* <strike>/lazarus/ide/runparamsopts.pas</strike>
 
* /lazarus/ide/searchresultview.pp
 
* /lazarus/ide/sortselectiondlg.pas
 
* <strike>/lazarus/ide/splash.pp</strike>
 
* /lazarus/ide/sysvaruseroverridedlg.pas
 
* <strike>/lazarus/ide/todolist.pp</strike>
 
* /lazarus/ide/unitdependencies.pas
 
* <strike>/lazarus/ide/uniteditor.pp</strike>
 
* '''/lazarus/ide/unitinfodlg.pp''' <D.Blaszijk>
 
* /lazarus/ide/viewunit_dlg.pp
 
* /lazarus/debugger/debuggerdlg.pp
 
* /lazarus/debugger/test
 
* <strike>/lazarus/debugger/watchpropertydlg.pp</strike>
 
* /lazarus/designer/aligncompsdlg.pp
 
* /lazarus/designer/designermenu.pp
 
* /lazarus/designer/menueditorform.pas
 
* /lazarus/designer/menupropedit.pp
 
* /lazarus/designer/noncontrolforms.pas
 
* /lazarus/designer/objinspext.pas
 
* /lazarus/designer/scalecompsdlg.pp
 
* /lazarus/designer/sizecompsdlg.pp
 
* /lazarus/ideintf/columndlg.pp
 
* /lazarus/ideintf/componenteditors.pas
 
* /lazarus/ideintf/graphpropedits.pas
 
* /lazarus/ideintf/imagelisteditor.pp
 
* /lazarus/ideintf/listviewpropedit.pp
 
* /lazarus/ideintf/propedits.pp
 
* /lazarus/packager/addtopackagedlg.pas
 
* /lazarus/packager/brokendependenciesdlg.pas
 
* /lazarus/packager/packagedefs.pas
 
* /lazarus/packager/pkggraphexplorer.pas
 
* /lazarus/packager/pkgoptionsdlg.pas
 
* /lazarus/tools/apiwizz/apiwizard.pp
 

Latest revision as of 15:07, 10 August 2014

Deutsch (de) English (en) français (fr) 日本語 (ja)

Overview

When working on lazarus, certain design guidelines need to be taken into consideration. To prevent a diversity of styles and ensure the clarity of dialogs. This article tries to summarize these guidelines to help you designing. There is also a buch of screenshots, artwork and dialog information available.

Comments

Cross platform

What you need to keep in mind is the cross-platform nature of Lazarus. If you make all the changes you suggest, the text on the buttons won't be visible in most standard GTK+ themes, or there will be other problems. I fully support the idea of some tweaks like this, but it should be tested in Linux, Win32 and even in Mac OS X (you guys are running it in Mac OS X already, right?) before it's committed. -Tony Maro

That's the only way to do it ;). I have patches of the different dialogs and I would encourage people to test them and post screenshots here. - Darius

CAFE standard

I found these ideas on form designs very interesting. If you can, I would be grateful if you could visit http://www.nvtech.com.au/ProjCurr/CAFE/CAFE.html to read about a convention called CAFE; standing for "Common Application Front End".

The intention of CAFE is not so much to have attractive forms but to have ones that reduce:

  • training required for application users,
  • effort required to input data and navigate around the application, and
  • the chances of a user accidentally inputting incorrect data.

The keypoints of the CAFE standard are that it requires each form to:

  • have a menu of options displayed (ie, not drop down menus or other hidden features)
  • be capable of being driven by both keyboard and pointing device with the option selection being done primarily by using numbers typed into the number pad on a conventional keyboard (tests have shown that clerks using the keyboard and number-pad are 60% faster than those that have to take their hands off a keyboard to use a pointing device.)
  • have a field devoted to "form help" which tells the user the purpose of the form and a field devoted to "field help" which changes as focus moves from field to field on the form. The "field help" informs the user of the purpose of the field and the input into that field which is acceptable.

If all contractors wrote their applications to conform with the CAFE standard, not only would it ensure an application that was best for business, but it would also allow many different contractors to participate in software development with all applications having exactly the same look and feel and so giving the perception they all belonged to one coherent applications suite. This would be good for everyone.

I hope you find these ideas interesting.

Kevin Loughrey

CEO Non Volatile Technologies Pty Ltd

(NVTech supports and promotes the use of Open Source Software as a means of accelerating societal advancement throughout the world.)

See also