[QGIS Commit] r14682 - in trunk/qgis: . doc

svn_qgis at osgeo.org svn_qgis at osgeo.org
Mon Nov 15 05:45:32 EST 2010


Author: timlinux
Date: 2010-11-15 02:45:32 -0800 (Mon, 15 Nov 2010)
New Revision: 14682

Modified:
   trunk/qgis/CODING
   trunk/qgis/doc/CODING.t2t
Log:
Updated HIG guidelines

Modified: trunk/qgis/CODING
===================================================================
--- trunk/qgis/CODING	2010-11-15 10:45:27 UTC (rev 14681)
+++ trunk/qgis/CODING	2010-11-15 10:45:32 UTC (rev 14682)
@@ -1399,6 +1399,27 @@
    Using a button box will ensure that the order of 'OK' and 'Cancel' etc,
    buttons is consistent with the operating system / locale / desktop
    environment that the user is using.
+ 6. Tabs should not be nested. If you use tabs, follow the style of the
+   tabs used in QgsVectorLayerProperties / QgsProjectProperties etc.
+   i.e. tabs at top with icons at 32x32.
+ 7. Widget stacks should be avoided if at all possible. They cause problems with 
+   layouts and inexplicable (to the user) resizing of dialogs to accommodate 
+   widgets that are not visible.
+ 8. Try to avoid technical terms and rather use a laymans equivalent e.g. use
+   the word 'Transparency' rather than 'Alpha Channel' (contrived example),
+   'Text' instead of 'String' and so on.
+ 9. Use consistent iconography. If you need an icon or icon elements, please
+   contact Robert Szczepanek on the mailing list for assistance.
+ 10. Place long lists of widgets into scroll boxes. No dialog should exceed 580
+   pixels in height and 1000 pixels in width.
+ 11. Separate advanced options from basic ones. Novice users should be able to
+   quickly access the items needed for basic activities without needing to
+   concern themselves with complexity of advanced features. Advanced features
+   should either be located below a dividing line, or placed onto a separate tab.
+ 12. Don't add options for the sake of having lots of options. Strive to keep the
+   user interface minimalistic and use sensible defaults.
+ 13. If clicking a button will spawn a new dialog, an ellipsis (...) should be
+   suffixed to the button text.
 
 
 

Modified: trunk/qgis/doc/CODING.t2t
===================================================================
--- trunk/qgis/doc/CODING.t2t	2010-11-15 10:45:27 UTC (rev 14681)
+++ trunk/qgis/doc/CODING.t2t	2010-11-15 10:45:32 UTC (rev 14682)
@@ -1280,7 +1280,28 @@
    Using a button box will ensure that the order of 'OK' and 'Cancel' etc,
    buttons is consistent with the operating system / locale / desktop
    environment that the user is using.
- +
+ + Tabs should not be nested. If you use tabs, follow the style of the
+   tabs used in QgsVectorLayerProperties / QgsProjectProperties etc.
+   i.e. tabs at top with icons at 32x32.
+ + Widget stacks should be avoided if at all possible. They cause problems with 
+   layouts and inexplicable (to the user) resizing of dialogs to accommodate 
+   widgets that are not visible.
+ + Try to avoid technical terms and rather use a laymans equivalent e.g. use
+   the word 'Transparency' rather than 'Alpha Channel' (contrived example),
+   'Text' instead of 'String' and so on.
+ + Use consistent iconography. If you need an icon or icon elements, please
+   contact Robert Szczepanek on the mailing list for assistance.
+ + Place long lists of widgets into scroll boxes. No dialog should exceed 580
+   pixels in height and 1000 pixels in width.
+ + Separate advanced options from basic ones. Novice users should be able to
+   quickly access the items needed for basic activities without needing to
+   concern themselves with complexity of advanced features. Advanced features
+   should either be located below a dividing line, or placed onto a separate tab.
+ + Don't add options for the sake of having lots of options. Strive to keep the
+   user interface minimalistic and use sensible defaults.
+ + If clicking a button will spawn a new dialog, an ellipsis (...) should be
+   suffixed to the button text.
+ + 
  
 
 = Authors =



More information about the QGIS-commit mailing list