Re: [Gramps-devel] HIG

[Don A. <dal...@us...>]

Alex, 

This is a great start, and I'm starting to make changes. I've already
made changes to the error boxes. I've put up a site that will keep track
of before and after shots. The new dialog boxes are shown here.

http://donaldallingham.home.attbi.com/gramps/hig.html

Don


On Sat, 2003-02-22 at 22:46, Alex Roitman wrote:
> Hi,
> 
> Attached is the amended list of HIG issues relevant to GRAMPS. 
> I went through conceptual details and not so much through visual 
> details. I absolutely ignored icons, palette, and such, as an 
> ultimately artistically challenged person. 
> 
> If anyone feels like filling the gap, you're most welcome :-)
> 
> I am not sure that my opinion is the absolute truth, 
> so why don't we discuss it broadly within this mailing list?
> 
> Alex
> 
> -- 
> Alexander Roitman   http://ebner.neuroscience.umn.edu/people/alex.html
> Dept. of Neuroscience, Lions Research Building
> 2001 6th Street SE, Minneapolis, MN  55455
> Tel (612) 626-7280   FAX (612) 626-9201
> ----
> 

> Sat, 22 Feb 2003 23:35:07 -0600 
> 
> * GNOME Menu name: 
> 	GRAMPS Genealogy System
> 
> * GNOME Menu Comment:
> 	Manage genealogical information, perform genealogical research 
> 	and analysis
> 
> * MIME type for .gramps and .zodb
> 	How about making file extensions .grs and .grz ?
> 	Call it application/x-gramps ?
> 	
> 	Also handle GEDCOM? 
> 	I have no idea what the MIME-type for GEDCOM files is.
> 	application/x-gedcom ?
> 
> * Delete confirmation
> 	Default of NO instead of YES
> 
> * Properties dialog
> 	* Menu should be Preferences, since Properties are for 
> 	  objects (documents, files, etc)
> 	* Title: GRAMPS Preferences (currently: Preferences - GRAMPS)
> 	* Window commands: Close, Minimize, Roll-up/Unroll
> 	* Close button should be in the lower right corner
> 
> * Save error alert
> 	* No title for alert windows! (currently: Error - GRAMPS)
> 	* Primary and secondary texts should be distinguished. HIG suggests 
> 	<span weight="bold" size="larger"> Could not create /newdir </span>
> 	as primary markup and default font and weight for the secondary 
> 	text (permission denied).
> 
> * Confirmation Alert of Delete (person, for example)
> 	* No title! (currently: Delete Person - GRAMPS)
> 	* Confirming button (in this case Yes) should be lower right.
> 	* Confirming button should be either the verb (Delete) or OK, 
> 	  instead of current Yes.
> 	* Cancel button (currently No) should be next to the left from 
> 	  Confirming button
> 	* Should have primary and secondary text. E.g. 
> 	  <span weight="bold" size="larger">Delete Edwin Michael Smith?</span>
> 	as the primary, and
> 		If deleted, this record will be irreversibly lost.
> 	as the secondary texts. 
> 
> * Save Confirmation
> 	* Currently, I can change the birth date of Smith, Edwin Michael, 
> 	  say OK, and then quit. As a result, the database is not changed 
> 	  (i.e. no save action was taken), but there's also no confirmation 
> 	  on exit -- therefore changes might be lost if the user forgets to 
> 	  explicitly click/choose from menu Save action. HIG suggests the 
> 	  following for the Save Confirmation alert:
> 	*  No title for the window
> 	* Primary text "Save changes to "mygramps" before closing?"
> 	* Secondary text "If you close without saving, changes from the 
> 	  last <Time Period> will be  discarded."  where <Time Period> is 
> 	  the time elapsed from modified time of the file.
> 
> * Dialog boxes (e.g. Descendant Report for Edwin Michael Smith)
> 	* Window commands: minimize, roll-up/down
> 	* buttons: right-to-left: Affirmative ("Produce Report" or 
> 	  current "OK"), Cancel. 
> 	* Somehow, size and orientation popups are huge. HIG does not specify 
> 	  the size of controls, but there has to be some sane default. 
> 	  For example, libgnomeprint - aware apps all use the same controls 
> 	  and they look much nicer. Anyway, it's just my impression.
> 
> * Popup menus
> 	One would expect to get popup menu with some actions when 
> 	right-clicking on an object such as person, source, and place. 
> 	Currently, only media-objects have popu menus.
> 
> * Keyboard Shortcurts
> 	How come Edit->Find does not have a shortcut? Should be Ctrl-F.
> 	Also, one might like having Find Next (Ctrl-G) and Find Previous 
> 	(Shift-Ctrl-G) menu items.
> 
> * Toolbar
> 	* There should be an option to turn it completely off (currently one 
> 	  can only modify the view).
> 	* There should be an option to return toolbar to the GNOME default 
> 	  (set in control center).
> 	* Users should be allowed to modify/construct toolbar.
> 	* Another toolbar option: text beside icons vs text below icons. 
> 	  This also should be allowed to take on the default GNOME value. 
> 	* Make "return tollbar layout to the GRAMPS default" option available. 
> 	* Since we've a single toolbar, there should be View->Toolbar 
> 	  checkbox menu item. 
> 	* ALL TOOLBAR CONTROLS SHOULD HAVE TOOLTIPS!!!
> 
> * Instant preferences
> 	Is it necessary to have Apply button in GRAMPS preferences window?
> 	HIG says that, unless it poses a problem, prefs should be applied 
> 	instantly. The valid excuses are cases when more than one parameter 
> 	has to change at the same time (like proxy address and port) or when 
> 	applying prefs takes more than 1 second. 
> 
> * Text entry fields
> 	* That is: 
> 		Preferences->Usage->Researcher Information
> 		Preferences->Database->GRAMPS internal IDS
> 	  and filesystem path fields (these are actually combo boxes, 
> 	  but all the things below apply to them too) in 
> 		Preferences->Usage->Report Preferences
> 		Preferences->Database->General->Default database directory
> 		Report dialogs
> 	* In the text fileds, the corresponding labels (on the left of the 
> 	  field) should have access keys (e.g. _Name)
> 	* These labels should have sentence capitalization (Media object, 
> 	  not Media Object; Postal code instead of Postal Code, etc.)
> 	* The fields' lengths should be set according to the likely size 
> 	  of the input. Specifically, one shouldn't try to make them all same 
> 	  length. In our case, zip code and phone are way too long by any 
> 	  expectation. Actually, most of the text entry fields are too long.
> 	* When several text entry fields are usually filled out in order 
> 	  (Name, address, phone, etc), HIG suggests setting the 
> 	  activates-default property on those entry fields to FALSE.
> 	  Then RETURN key will advance the focus to the next field, 
> 	  and not close the dialog window. 
> 	* Sping box in Preferences->Database->General->Autosave interval 
> 	  should be right-justified (all numerical text entry should, actually) 
> 	  and should be way shorter - few digits at most. 
> 
> * Check Boxes - these are all over the place. 
> 	Labels should have acces keys
> 
> * Radio Buttons
> 	Labels should have acces keys
> 
> * Option Menus
> 	Labels should have access keys
> 	_EACH_ menu item should have acces key which is unique through 
> 	the window/dialog, not just that menu
> 
> * Combo Boxes
> 	Labels should have acces keys
> 
> * Trees
> 	Should have a label (above or left) in sentence capitalization. 
> 	An access key too. In our case, GRAMPS preferences' tree should have 
> 	the label "GRAMPS preferences" (or, maybe, "Categories") above the tree, 
> 	instead of the top of the grey area on the right. 
> 
> * Tabbed notebooks - GRAMPS does not have these, does it?
> 
> * Frames and separators - Oh my, we've got a lot of those all over. 
> 	Frames are generally deprecated, the arguments being that they 
> 	add a lot of visual noise. The alternatives suggested are: bold 
> 	labels for categories, indented contents, good layout and spacing.
> 
> * Labels for all UI controls:
> 	* Left aligned if they're of comparable length, right-aligned if 
> 	  they're too different in length (in Preferences->Database->General, 
> 	  the labels "Autosave interval" and "Default database dir" should be 
> 	  left-aligned)
> 	* Must have clear meaning even if taken out of context.
> 	* Sentence capitalization
> 	* Labels preceding controls must have trailing colon 
> 	  (eg. Name: [text entry field] )
> 	* Access keys for all labels
> 
> * Visual details of layout
> 	* as much stuff aligned as possible
> 	* when aligned, has to be _EXACTLY_ aligned
> 	* avoid frames/separators, use space/indentation/typeface instead
> 	* all spaces are multiples of 6 pixels
> 	* the lower right button (OK) is exactl 12 pixels up and 12 pixels left 
> 	  of the window corner. 
> 	* other buttons are 12 pixels left of the previous one
> 	* Help button is 12 pixels right of the roght window corner
> 	  (preferences window does not have the righ layout of buttons: 
> 	  OK, Cancel, Help on the left, Apply is the third from the right, 
> 	  if it is absolutely necessary, see above).
> 
> OVERALL - gedit seems to be an example app from the HIG point of view. 
> If in doubt, look at how that thing is done in gedit :-)