GEPS 034: Improve usability
Improve the usability of Gramps
This Gramps Enhancement Proposal explores ways to improve the usability of Gramps.
This GEPS is about changes that would significantly improve the user friendliness of Gramps. It is not about the visual details of the user interface; it is not about whether the user interface conforms to some specific guidelines or style. It is not about minor changes to the user interface.
It is appreciated that improving usability is among the hardest things to do with software, especially with Open Source, and that in some (most? all?) cases it is a matter of opinion. However, It is important to have this GEPS as a place to collect feedback on problems as well as possible solutions.
Some of the wording below has been taken from various messages on the Gramps mailing list. The purpose of this GEPS is to stimulate radical thinking, rather than to follow what has gone before.
- 1 The challenges
- 2 Possible ideas
- 2.1 Provide more Natural Transcription input methods
- 2.2 Reduce the number of editors
- 2.3 Make displays editable
- 2.4 Improve Help and Documentations in Gramps
- 3 Minor changes that are NOT the subject of this GEPS
- 4 See also
Making a user interface that novice users can understand is hard. Making a user interface that provides the power and flexibility that advanced users require is really hard. And making an interface that does both is ... nearly impossible.
Based on my experience with the Gramps team, I think a major overhaul effort would be difficult to execute. Major projects like that require sustained focus. Our developers are volunteers who have to find time to hack code between washing the dishes and changing the oil in the car. The most substantial changes I have seen over the life of Gramps have been slow and evolutionary - and were developed over the course of a series of staged releases.
- From: Brian Matherly - 2011-03-30 - Re: (Gramps-devel) Focus On User Interface, Usability
I just can't see how this can be tackled in the incremental way that Gramps mostly works. The 'little improvements over time' approach seems to have given us a powerful but unwieldy tool.
- From: Duncan Lithgow - 2011-03-30 Re: (Gramps-devel) Focus On User Interface, Usability
The reviews and feedback
- Program complexity
- Douglas T watts says: "Too Complex when it came to adding a spouse???".
- Hal Bates says: "found it very difficult to use and it is not intuitive...Biggest Con: Hard to use or figure out".
- Doug says: "inputting even basic information is far too complicated and the documentation is weak. Even a simple task like creating a marriage link between two people isn’t intuitive and the information required (available names of the right gender) simply does not display...Biggest Con: Interface far too complex".
- niteowl says: "This software is the worst genealogy software for entering info I have ever used, I have been a genealogist for 22 years and would NOT recommend this software, free or not...Biggest Con: navigation and data entry".
- Art says "it takes some time to understand how to enter information...Biggest Con: Ease of use (practice makes perfect)"
- catsy says: "15 years of experience with genealogy software, and this is the most user-unfriendly experience ever. Utterly non-intuitive...Trying to figure out how to enter basic data is nearly impossible...Biggest Con: completely non-intuitive".
- Dan Cornett says: "Biggest Con: Rather clunky interface for adding new people & relationships.".
- corb says: "Gramps is a bit hard to learn and definitely a pain to use...Biggest Con: data entry is cumbersome".
- Robert K. Tompsett says: "Gramps does not even come close to user friendly...Biggest Con: User unfriendly".
- Neil LCW Naessens says: "extremely and annoyingly basic"
- Help and documentations Issues
- Apr 30, 2012 - R Stevens say, "ridiculously difficult to enter the most basic of info. Help buttons don’t work" Biggest Con: Takes user friendliness to new lows".
- Nov 21, 2012 - Robert K. Tompsett says: "Gramps has no documention worth using."
- Jul 8, 2014 - Not ready for prime time says: "The documentation doesn’t match version 4 in this respect so it’s no help." Biggest Con: not intuitive, sketchy documentation
- Aug 11, 2014 - VRM says: "The manual is inaccurate ...., or just plain wrong. The developers expect you to read the whole manual before attempting anything, yet they provide directions that you’ll not remember by the time you actually get to the software. Also, as for the manual, wall-of-text alert. The program icons? Some are mystery meat, where you guess what they are (Why does that green tree split apart at the bottom?)" Biggest Con: ... I don’t want to read 50 pages of manual to find out if it does or not.
- Jun 17, 2014 - bh says: "The Manuel in not helpful. ... "
- Sep 23, 2015 - 8665#c44667 asharpham says: " I've said it before but the Manual leaves a lot to be desired. It isn't user friendly because it's been written by the developers. Developers don't speak "user friendly" so us mere mortals can find it hard to follow. I've learned not to go to the manual for advice because I just don't understand most of the instructions."
Note that in some cases
the criticisms quoted are accompanied by positive remarks. The comments in some cases also mention specific interface issues. None of these are considered here.
- A comment:
Recently having sought to really use GRAMPS on a regular basis for practical genealogical research has repeatedly illuminated a lack of intuitive or smooth workflow within the user interface, particularly for the new user manually entering information. In some future major revision of GRAMPS, for example for version 4.0, how about putting a major emphasis on the user interface and its usability? It seems to me that a new user should understand how to enter basic information smoothly and effectively and not feel like they're switching back and forth between a large number of views or performing many steps which could perhaps be combined and lessening redundant processes. It also seems that a new user should not have to load alternate views, gramplets or perform any significant customization. These areas appear to need some attention.
- From: Greg Lamberson - 2011-03-29 - (Gramps-devel) Focus On User Interface, Usability
- Another comment:
I am often highly frustrated by the difficulty of data entry, especially on the Relationship and Pedigree views. Coming from Family Tree Maker 2006, the ease of data entry is the one thing I miss.
The main issue I have with the pedigree view is that it takes too many clicks (two; one too many) to go to a child of the active person. Couldn't there be an always-present left sidebar display of the active person's parent and spouse families? Furthermore, sometimes with distant ancestors with several children I have descendants recorded for, I don't remember which one is my ancestor. This would be helped by a sidebar because the sidebar could display children's dates and maybe spouses.
- Click edit family
- Click add child
- Enter given name, edit family name if necessary (with three shift-tabs or a click)
- Click add event for birth
- Click date field, enter date
- Click select place or new place, or 4 or 5 tabs to get to it; select place; click ok (or alt-o); click ok (or alt-o);
- Repeat 4-6 for death event
- Click OK
Total: 14 clicks, or 7 clicks and 15 to 17 keystrokes, plus the data you are entering (including selection of place)- From: Michael White - 2008-02-11 - (Gramps-users) My thoughts on usability/data entry
- Another comment:
When I add a person in PAF, or Ancestry, I see one screen where I enter name, gender, and main events. When I do the same in Gramps, I see half a dozen screens, one for the person, one extra to add each event, and another extra to add a location or to choose an existing one. That's a lot of work, and when I want to enter birth, baptism, death, and burial, I need at least 9 screens in Gramps, where PAF still has only one. And in Gramps, it's actually more, because many times I need an extra click to see whether the location that I want to enter already exists in the database. In those occasions, it is not half a dozen, but a full one,really!
- From: Enno Borgsteede - 2014-03-31 - Re: (Gramps-devel) Gramps 3.4.8 from GIT --> Sources
Suppose you want to add an attribute to an event for a user. The steps involved would be:
- Click on the People category
- Scroll to and double-click on the relevant person
- Click on the Events tab (actually it will already be selected)
- Scroll to and double-click on the relevant event
- Click on the Attributes tab
- Click on the 'Create and add a new attribute' button
- Type in the attribute name
- Click on (or tab to) the Value field
- Type in the value
- Click OK to exit the Attribute Editor
- Click OK to exit the Event Reference Editor
- Click OK to exit the Person [Editor]
One aspect that seems particularly confusing for (new) users is the way relatives are added to a person.
The description in Start with Genealogy describes how to add a person and their birthdate and place. This involves opening and closing a large number of different windows. This can be contrasted with a number of other genealogy programs where all this data is input on a single window.
Provide more Natural Transcription input methods
- This is already addressed by GEPS 024.
Reduce the number of editors
1. Reduce (gently) the number of different interfaces: this, of course, means that some interfaces will be busier. Too often, confusion results from too many windows open simultaneously.
- From: David Lynch - 2011-03-30 - Re: (Gramps-devel) Focus On User Interface, Usability
At present, Gramps is largely based on a paradigm of one-to-one correspondence between editors and (internal) database objects.
One approach might be to construct editors that support editing of several objects at once. For example, the Person editor might allow editing of the person name, events etc.
There are clearly a number of issues that would need to be addressed:
- There are technical issues of object locking.
- Window size issues would need to be addressed.
- Multiple objects would need to be addressed (e.g. there will be several event objects).
- Complex structures would need to be addressed.
One way of addressing complex structures is illustrated by the current person editor and the preferred name. The normal window shows a simple name structure. There are then two different ways of handling complexity within that editor. First by a 'Go to name editor and add more information about this name' button which opens a new editor only if the user really needs the complexity. Second by the 'Use multiple surnames' button, which does not open a new editor, but instead expands the current editor display.
An example of the approach of having editors which edit more data is Personal Ancestral File (PAF). The Edit Individual window combines editors for name, main events, other information, other events etc. I presume that more 'other events' etc. can be added into the same editor as required. There are buttons beside events etc. which lead to editors for sources etc.
An example of how a possible combined editor might look, see below. Changing or adding basic information like names, birth and death dates and events (including places, which are not shown on the example) should be done directly on this page. More complicated changes would require clicking on the edit button to bring up the full editor (edit buttons are not shown, except for the spouse).
N.B. This is only a very quick and rough example - it needs to be worked out much more fully.
Make displays editable
For example, if I wanted to edit the City, County and Country of each Place in the Place category, then I have to open each, and edit it.
If the Place display were editable then one could simply go down the list and edit the fields.
Please note that this is not a request for a tool to perform some operation. In the particular example given here, the Place Completion Tool might do what is required. The point is that if the operation wanted is not exactly what the tool does so that the user needs to do the operation manually, the lack of an active view makes it necessary to edit each object individually.
Improve Help and Documentations in Gramps
Improve Help and Documentations in Gramps
- Update user manual to match (Gramps 4.2.0) version of Gramps (Started:20150701 - Completed: On hold )
- 8888 : [Review]Gramps Help button User Manual wiki-links (Started:20150904 - Completed: 20151025 )
- 9042 : [Review]Gramps Help button User Manual wiki-links (Started:On hold - Completed: - )
- Review Gramps code and ensure that F1 help links as well as Help buttons link to correct sections on wiki.
- Add help buttons where missing
- If no Help button can be shown for the page ensure that pressing F1 brings the user to the correct page and not just the Manual index eg: correct context.
Know your audience, who uses this software?
- Icons are nice, text labels are better. (no mystery meat navigation) (Add Toolbar text under icons by using patch from 6583#c44563)
- Add an help icon to the toolbar eg a question mark ? etc.
Roll over of user manual
As of 20150831 the manual roll over occurs just before a release is made, this is too late for practical use by translators etc.
I suggest we change the way this is done so that updating the user manual is in sync with changes in Gramps master.
- When a release manual roll over is made the user manual should be locked with no changes possible.
- Have a Gramps master manual that all updates made against Gramps master are taken into account.
- Copy the the Gramps master manual to the next major release number.
Separate the User manual
Separate the user manual into:
- User guide - General usage and help that refers to the individual dialogs (eg: Help Screens?), but does not repeat the information.
- User guide - Tutorials (how to?)
- Reference manual - Context help for the individual dialogs
- Appendices with more technical information.
- Gramps Developer documentation - In the sphinx format: Gramps Python API
Code changes for help
Improve and consolidate help methods
- F1 context help?
- Help button
- 9677:Move "help_url" option to all plugins (and addons)
- 9678:Default help page for addons is the plugins page, not the addons page
Existing help API's
print_help()If the user gives the –help or -h option, print the output to terminal.
help_urlThe URL where documentation for the URL can be found
get_help()Get the help information for this option. Returns: A string that provides additional help beyond the label.
set_help(help_text)Set the help information for this option. Parameters: help – A string that provides additional help beyond the label. Example: “Whether to include or exclude people who are calculated to be alive at the time of the generation of this report” Returns: nothing
on_help_clicked(obj)Display the relevant portion of Gramps manual
on_help_clicked(obj)Display the relevant portion of Gramps manual
help_clicked(obj)Display the relevant portion of Gramps manual
Github searches for:
Have a unique gramps_help_key for each type of help that does not change between versions.
Have single XML file(per language) with those gramps_help_key's and the link to the wiki so that can be updated in one hit.
- Help for addons would also have to have a gramps_help_key
Mediawiki changes for help
Existing translations are out of sync (outdated) with the English version.
Install and use:
- The Translate extension tool to translate every kind of text. It's used especially to translate software and to manage multilingual wikis in a sensible way. https://www.mediawiki.org/wiki/Extension:Translate
Update media template(skin):
- 8665#c44676 : Change location of search button - larger search button at the top of the page where most search buttons are found... :-)
- Mediawiki mentions that In the Vector skin (the default MediaWiki skin since MW 1.16), near the top right of every page there is a search box with a magnifying glass icon looks like Gramps uses the older Monobook Skin. See: https://www.mediawiki.org/wiki/Help:Searching
Have the search box restrict search to just the newer user manual? Mediawiki:custom namespace
Add a Mediawiki instance and new domain for documentation
Be able to cache Offline help files?
- In preferences have a help server URL dropdown with an option for "Offline/local" that point to a local GRAMPS_HELP directory that you can place a spidered html copy of the help.
Minor changes that are NOT the subject of this GEPS
All these changes belong in Feature Requests. (They come up in a search for 'usability'.)
- Provide a list of 'recently used sources'.
- Leave search options on the last used option.
- Improve search when typing a few characters (doesn't work well in People view).
- Select Child window to open at last used name.
- Improve usability of export assistant filters.
- 8686 Prototype for a new "Event Entry" window.
- 1577 Cumbersome work flow to add more people to an event
- 7807 main window makeover (full-screen option)
- 8099 Create hard-copy like documentation as PDF (Suggest installing the Mediwiki:Extension:Collection Allows to organize personal selections of pages in a collection that can be edited, persisted and optionally retrieved as PDF, ODF or DocBook (XML))