UI style - Revision history

Patsyblefebre: what is it

2012-12-26T22:24:04Z

what is it

Daleathan at 04:09, 28 September 2011

2011-09-28T04:09:13Z

Lcc: UI Style moved to UI style

2010-03-30T11:07:42Z

UI Style moved to UI style

Dsblank at 03:25, 18 February 2008

2008-02-18T03:25:26Z

Pez4brian at 05:41, 11 November 2007

2007-11-11T05:41:05Z

Bmcage at 20:01, 4 September 2007

2007-09-04T20:01:33Z

Don: New page: As more and more people start working on the UI, it is important to get a few guidelines in place to maintain consistency. * Adhere to the [http://developer.gnome.org/projects/gup/hig/2.0...

2007-09-04T19:16:31Z

New page: As more and more people start working on the UI, it is important to get a few guidelines in place to maintain consistency. * Adhere to the [http://developer.gnome.org/projects/gup/hig/2.0...

New page

As more and more people start working on the UI, it is important to get a few guidelines in place to maintain consistency.

* Adhere to the [http://developer.gnome.org/projects/gup/hig/2.0/ GNOME Human Interface Guidelines] as much as possible. If you feel you have a need to deviate from these, make sure you can justify it, and get buy off from the rest of the developers.
* Avoid using color to distinguish text. If you can, use a different mechanism. There are two issues:
# GTK allows the users to change their themes. You may be happy with your dark blue text that you've defined, but what about the person whose theme has a dark blue background? So far, the only widget that seems safe to use color is the gtk.TreeView.
# Many users (particularly males) are color blind. What you can distinguish, others may not be able to do so.
* Go for consistency. If a concept is used elsewhere in the program to represent what you want to do, use that mechanism. As an example, if someone's birth date does not exist, and you want to use a christening date instead, put the date in italics. This is what the Person View does. Be consistent with that. The more consistent we are, the less confused the user gets.
* Don't go button crazy. Buttons should be reserved for functions routinely used by all users (like Add, Delete, Edit). More obscure and less frequently used items should be in menus (such as a right context menu). Think of Firefox - The "Go to home page" function is used all the time, so it is a button. The "Send Link" function is not frequently used, so it appears in the menus.
* Data editors (like the Edit Person or Edit Family dialogs) should be just that - Data Editors. They are for data entry, not for displaying interesting information. If you want to display related data that is not part of the entry, use a Quick Report in the right context menu.
* Help the user. If a button is not valid in the current context, set it insensitive. That way the user doesn't click on it and wonder why nothing happens.
* Remember that the majority of the users are probably novices without a lot of computer experience. Design things so that your Aunt Martha could use it. Advanced functions can be deferred to the right context menu.

← Older revision		Revision as of 22:24, 26 December 2012
Line 1:		Line 1:
−	For developers working on the UI, it is important to follow this guidelines to maintain consistency.	+	For developers working on the [http://en.wikipedia.org/wiki/User_interface#User_interfaces_in_computing UI] (User interface), it is important to follow this guidelines to maintain consistency.

	* Adhere to the [http://library.gnome.org/devel/hig-book/stable/ GNOME Human Interface Guidelines] as much as possible. If you feel you have a need to deviate from these, make sure you can justify it, and get buy off from the rest of the developers.		* Adhere to the [http://library.gnome.org/devel/hig-book/stable/ GNOME Human Interface Guidelines] as much as possible. If you feel you have a need to deviate from these, make sure you can justify it, and get buy off from the rest of the developers.

@@ Line 1: / Line 1: @@
-As more and more people start working on the UI, it is important to get a few guidelines in place to maintain consistency.
+For developers working on the UI, it is important to follow this guidelines to maintain consistency.
-−
-[[Category:Developers/General]]
 * Adhere to the [http://library.gnome.org/devel/hig-book/stable/ GNOME Human Interface Guidelines] as much as possible. If you feel you have a need to deviate from these, make sure you can justify it, and get buy off from the rest of the developers.
@@ Line 15: / Line 13: @@
 * In the UI, display actual data, not derived data. If people see derived data in the UI, they will expect to be able to edit it. Derived data should only be shown in reports.
 * Remember that the majority of the users are probably novices without a lot of computer experience. Design things so that your Aunt Martha could use it. Advanced functions can be deferred to the right context menu.

← Older revision		Revision as of 20:01, 4 September 2007
Line 1:		Line 1:
	As more and more people start working on the UI, it is important to get a few guidelines in place to maintain consistency.		As more and more people start working on the UI, it is important to get a few guidelines in place to maintain consistency.
		+
		+	[[Category:Developers/General]]

	* Adhere to the [http://developer.gnome.org/projects/gup/hig/2.0/ GNOME Human Interface Guidelines] as much as possible. If you feel you have a need to deviate from these, make sure you can justify it, and get buy off from the rest of the developers.		* Adhere to the [http://developer.gnome.org/projects/gup/hig/2.0/ GNOME Human Interface Guidelines] as much as possible. If you feel you have a need to deviate from these, make sure you can justify it, and get buy off from the rest of the developers.

@@ Line 3: / Line 3: @@
 [[Category:Developers/General]]
-* Adhere to the [http://developer.gnome.org/projects/gup/hig/2.0/ GNOME Human Interface Guidelines] as much as possible. If you feel you have a need to deviate from these, make sure you can justify it, and get buy off from the rest of the developers.
+* Adhere to the [http://library.gnome.org/devel/hig-book/stable/ GNOME Human Interface Guidelines] as much as possible. If you feel you have a need to deviate from these, make sure you can justify it, and get buy off from the rest of the developers.
 * Avoid using color to distinguish text. If you can, use a different mechanism. There are two issues:
 # GTK allows the users to change their themes. You may be happy with your dark blue text that you've defined, but what about the person whose theme has a dark blue background? So far, the only widget that seems safe to use color is the gtk.TreeView.

@@ Line 11: / Line 11: @@
 * Data editors (like the Edit Person or Edit Family dialogs) should be just that - Data Editors. They are for data entry, not for displaying interesting information. If you want to display related data that is not part of the entry, use a Quick Report in the right context menu.
 * Help the user. If a button is not valid in the current context, set it insensitive. That way the user doesn't click on it and wonder why nothing happens.
 * Remember that the majority of the users are probably novices without a lot of computer experience. Design things so that your Aunt Martha could use it. Advanced functions can be deferred to the right context menu.