View source for GEPS 034: Improve usability

{{man note|Improve the usability of Gramps|This 2014 [[GEPS|Gramps Enhancement Proposal]] explores ways to improve the usability of Gramps.}}

{{man menu|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.

= The challenges =

<blockquote>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.<br><br>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.<br>- '''From: Brian Matherly - 2011-03-30 - [http://sourceforge.net/p/gramps/mailman/message/27280108/ Re: (Gramps-devel) Focus On User Interface, Usability]'''</blockquote>
<hr>
<blockquote>
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.<br>- '''From: Duncan Lithgow - 2011-03-30 [http://sourceforge.net/p/gramps/mailman/message/27280425/ Re: (Gramps-devel) Focus On User Interface, Usability]'''</blockquote>

== The reviews and feedback ==

In the reviews of Gramps on Gensoft for [http://www.gensoftreviews.com/?p=1648 MS-Windows], [http://www.gensoftreviews.com/?p=1649 Apple Mac] and [http://www.gensoftreviews.com/?p=286 Linux], some selected comments are:

;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 - {{bug|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."

{{man note|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:
<blockquote>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.<br>- '''From: Greg Lamberson  - 2011-03-29 - [http://sourceforge.net/p/gramps/mailman/message/27278184/ (Gramps-devel) Focus On User Interface, Usability]'''</blockquote>

* Another comment:
<blockquote>
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.

Current method:
# 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)<br>
- '''From: Michael White - 2008-02-11 - [http://sourceforge.net/p/gramps/mailman/message/18563150/ (Gramps-users) My thoughts on usability/data entry]'''</blockquote>

* Another comment:
<blockquote>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!<br>- '''From: Enno Borgsteede - 2014-03-31 - [http://sourceforge.net/p/gramps/mailman/message/32167521/ Re: (Gramps-devel) Gramps 3.4.8 from GIT --> Sources]'''</blockquote>

* Another comment:
<blockquote>Over the years, I've tried to get friends and relatives to use Gramps. They've all tried but eventually gave up and complained to me that it's too difficult and confusing to use.  I'm not saying that what you have can't do the job and, yes, I find it very useful – for extended analysis.  Bur for day-to-day work, it's the pits and I always fall back to Family Tree Maker
and so do my genealogist colleagues.  I've worked in genealogy for over 40 years and IT program development for almost as long and have been so disappointed that you don't use the GUI environment to your or the user's advantage.  It really feels like a DOS or Windows 2 environment.  Times change – techies should be the first to recognize that.   So, come on! – get with it!!!!!  Keep the old stuff, it's useful, but look at your competitors and other open source stuff and be better than them… or at least keep up.<br>- '''From: f8pumy@... sent to webmaster email and forwarded to Gramps-devel mailing list - 2018-10-07 - [https://sourceforge.net/p/gramps/mailman/message/36438271/ (Gramps-devel)Fwd: Gramps 5.0]'''</blockquote>

* Another comment:
<blockquote>I wish this was a love letter but it isn't.   I have used a 1990s Family Tree Maker for years... made by Broderund.

I have not wanted to get into a subscription program like ancestry and
the new Builder because I run a large genealogy site with about a
hundred kin.  It was my intention to find a free software program that
was hassle free and would be easy for ordinary, non hobbyists. Ones who
don't wanna know about field names and operators to navigate through
their ancestry.

Sadly Gramps isn't it.  I found my 1991 version of FTM has better
navigation that yours and even better than the New touted Family Tree
Builder.  So I offer you a few suggestions for your next rewrite.   Work
on your labels and your search mechanism first... thats stuff the
ordinary user looks for.  Ease of Navigation.

   First, so you know where I'm coming from, I've been a database and
website designer since about 92 with a lot of training in
dbase/Foxpro/VFP, and then when microsoft took over the world, I've done
some sqlserver, and a bit of XML because the Java programers liked that
old stuff.  So I"ve worked with an open source, java group of people and
my background is different.   I'm a journalist by trade so I write a lot
of documentation.  Started out with dBASE on old Osbornes in the mid
80s.     I was always more USER oriented than PROGRAMMER oriented, which
makes me gently suggest good programming is to impress USERS, not other
programmers.   It's been hard for early programmers to learn writing for
users with WYSIWYG tools.  User interface isn't a natural skill for
programmers who love writing very tight, interchangeable, object
oriented back end oriented apps.  Less code the better.   That's not the
secret to a good programming.   Its Intuitive navigation for USERS.  ANd
that's all.

I think your navigation is far too complex for regular people who want
the buttons intuitive, well labeled and laid out like Microsoft writes
most of their software.   Easy on the eyes, key data displayed in BOLD
and using colors... that similarity of arrangement improves peoples
comfort level.   I finally quit programming as designed by Dbase II for
DOS, and started doing things Microsoft's way.   That's why Gates is a
kazillionaire and I'm not ;)

Family Trees label should be "OPEN" and the program should default to
the last tree that was used.   How many genealogists work multiple trees
and go back and forth everytime they run the program?   The old computer
word is LOAD, the one for the last twenty years is "FILE and OPEN".

Next should be Search or FIND.  And it should open a dedicated box to
enter last, first, an an easy on the eyes Picker with the most important
fields first.  And the ever present search box should be smaller,
fitting the fields of last,first,middle,  Birthdate like Americans
expect it  MMM-DD-YYYY not YYYY-MM-DD.   I think ya can write code to
sort inside your date field, can't you?  It's like you've made it easy
for the Programmer but unfamiliar for the USERS.   Especially when
keying in data by phone when everyone on earth says month- day -year,
not the other way around.   Just add code snippet. or put a date
preference in your setups to please Europeans.

I think programming large multi-functional boxes was easy to write but
it takes too many keystrokes to pick the function a user wants each time
they open the program.    We dont' say "FILTER" anymore with all those
field buckets.  Very old school.   We say "FIND" or "SEARCH" and we make
the most common useage default.   That'd be NAME, last first.   I can't
imagine people even caring about ID and why it's so prominent.   It
should be invisible to users, who search on name, then date of birth.
ID is just clutter.   That whole filter screen should be hidden in a
Toolbox because regular people just don't search based on birthdates or
deathdates, marriage dates, very often.  Its all about NAME.

Why do you break down by GENDER either, and spell it out rather than a
non-intrusive 1 character field for M or F?  I wouldn't even waste six
spaces with a field label in the browser.      I'm just saying you
display too many filter categories...its too hard to find people, and at
a glance see the right fields.  Ya know how iTUNES lists, and gives
users ability to change field displays and field order on their browse
screen?   You have ID and gender right after Name, and if anything, it
should be NAME, birth date, death date, place of birth--the key
information users would need to see from the people picker.

Speaking of the picker, why don't you just sort on LAST FIRST and not
bother with all the filter choices,   You have a button for 'regular
expressions"?   That so reminds me of Foxpro days when programmers tried
to make software users use our lingo.  Who uses command lines but old
guard programmers?   Bill Gates replaced all that but us old programmer
guys just can't let it go, can we?

In the lower part of your screen, why do you list by TYPE (personal -1
etc).     If the event is the most common, BIRTH, just say birth.    No
need for Personal-1, personal -, F amily -0.   Under Events and names, a
bucket displaying any TYPE is just screen clutter and they should be
hidden.   Events should be naturally displayed after birth by event
date.   No need to sort by behind the scenes 'type'.

I wish when I had a PERSON selected, I could just always be just a click
away from PARENTS, and CHILDREN.   And have the program intuitive enough
so if I clicked a parent or a child, the pointer would just go to that
person and repaint all the detail.  In short, your navigation is clunky.

Okay, I've beaten on you enough.  Now about your HELP.   Wiki help was
trendy in the mid 90s but not anymore.   The first thing I wanted to do
was find out what buttons to push to import my GED file...and it took a
lot of hunting and way too much explanation about your database layout
for me to find it.   The whole thing is too wordy and not TASK
oriented.    WHen you write a help screen, youre only answering one
question.   "HOW DO I....."  Yours seems more to be a long treatise on
how the back end of the program is designed.

How do I add a new spouse?
How do I move or not move children to that spouse?
How can I click on a child record and see that persons vitals, spouse,
children?
Do we really need all the field filters and regular expressions?
How can I quickly add a Note without pushing a bunch of buttons?

That's all...I just wanted to vent.  Imagine how hard it would be
sitting with grandma at the kitchen table and entering data as fast as
she can tell it, moving from one kid to the next?   Its all about John
married sally on this date...key in her first, middle, maiden, her date
of birth, now let's list the kids.   And quickly bring up the kid's
record so we can add that kid's spouse before moving on to the NEXT
kid.  or move upwards from people to their parents, then
grandparents...or click click click father records all the way back to
the progenitor?<br>- '''From: RadiomanKC - 2015-12-31 - [https://sourceforge.net/p/gramps/mailman/message/34731862/ (Gramps-devel)Fwd: feedback on Gramps]

;Feedback on MantisDB

* <blockquote>I am sure the whole program is vastly configurable, but that's actually part of the complexity that makes it daunting for people. Instead, I want the *default* configuration to make it easy for the user. So, suggesting that I could drag the columns all around and click on them for sorting by date-changed is not only irrelevant but counterproductive. I'm trying to REDUCE the amount of makework clicks and drags that I and every user have to do in order to enter simple genealogical info.<br>{{bug|9866}} Selecting objects should show the most recently added objects</blockquote>

== Examples ==

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|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.

= Possible ideas =

== Provide more Natural Transcription input methods ==

* This is already addressed by [[GEPS_024:_Natural_transcription_of_Records|GEPS 024]].

== Reduce the number of editors ==

<blockquote>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.<br>- '''From: David Lynch - 2011-03-30 - [http://sourceforge.net/p/gramps/mailman/message/27281113/ Re: (Gramps-devel) Focus On User Interface, Usability]'''</blockquote>

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.
{{-}}
[[File:Example composite editor.jpg|thumb|800px]]
{{-}}

'''Change the UI toolkit''' The [https://subsurface-divelog.org/ Subsurface open source divelog program] had somewhat similar problems with their UI, and resolved these by [https://www.youtube.com/watch?v=ON0A1dsQOV0 migrating from Gtk to Qt] See [http://gramps.1791082.n4.nabble.com/Display-update-after-dismissing-a-dialog-tp4672434p4672494.html] and [http://gramps.1791082.n4.nabble.com/Gramps-5-0-Decisions-tp4672349p4672562.html]. <blockquote>I think we have many of the same problems with our using of gtk as the people in the video (the problem of how to get into an editing state - having to double click to open a new editing window is exactly the same as with gramps).<br> <br>

It was clear that for them switching between gtk and qt was a mammoth amount of effort, and they had lots of support and many really good developers. So unfortunately I think it would be out of the question for us, nice though it might be. </blockquote>

See [http://gramps.1791082.n4.nabble.com/Implementing-persona-support-in-Gramps-tp4674013p4674227.html]

<blockquote>What I particularly like about the interface is the ability to edit information directly on the main display without having to open up a new editor for every change.

The first place I would like this is in the main category displays. For example, it should be possible to edit the main person names and birth and death dates in the main People category displays.

Secondly, it would be nice to have a single display that shows the main information about a person, and allows that information to be edited. For example, it could show events, children etc, and then it should be possible to edit and add without having to go into a separate editor. I have done a VERY quick and dirty Photoshop mock-up of what something like this might look like in:

https://gramps-project.org/wiki/index.php?title=GEPS_034:_Improve_usability#Reduce_the_number_of_editors

I envisage the data entry being something a bot like the Data Entry Gramplet, where you can simple enter the birth dates and names.

The main point is that for very simple users, it should be possible to enter the main information more simply. More 'professional' users would of course need to full power of the Gramps editors to define everything.

(I suspect that the main internal change needed is to implement a different object edit lock). </blockquote>

== 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|user manual]] to match (Gramps 4.2.0) version of Gramps (Started:20150701 - Completed: Abandoned in favor of Gramps 5.0.0 update )
* Update [[User_manual|user manual]] to match (Gramps 5.0.0) version of Gramps (Started:20171211 - Completed: In progress )
* {{bug|8888}} : [Review]Gramps Help button User Manual wiki-links (Started:20150904 - Completed: 20151025 )
* {{bug|9042}} : [Review]Gramps Help button User Manual wiki-links (Started:On hold - Completed: - )
* {{bug|10919}} : [Review]Gramps Help button User Manual wiki-links (Started:On hold - Completed: - )
** Review Gramps code and ensure that {{man key press|F1}} help links as well as {{man button|Help}} buttons link to correct sections on wiki.
** Add help buttons where missing
** If no  {{man button|Help}} button can be shown for the page ensure that pressing {{man key press|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 {{bug|6583#c44563}})
* Add an help icon to the toolbar eg a question mark '''?''' etc.

* [[Translating the Gramps User manual]]

* [https://gramps.discourse.group/t/did-you-try-to-to-contribute-on-the-wiki-but-give-up/1910  Did you try to to contribute on the wiki but give up?] - Feedback - 2021


=== Roll over of user manual ===
As of 2015-08-31, the [[Rollover_for_the_manual|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. 

Instead:
* When a release manual roll over is made the user manual should be locked with no changes possible. [ [[Rollover_for_the_manual#Set_previous_version_pages_to_be_protected|Done]] ]
* Have a Gramps master manual that all updates made against Gramps master are taken into account.
* Copy the Gramps master manual to the next major release number. [ [[Rollover_for_the_manual#Rolling_over_the_Gramps_user_manual|Done]] ]

=== 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: [https://gramps-project.org/docs/ Gramps Python API] <!-- ( api.gramps-project.org ) -->

=== Code changes for help ===

Improve and consolidate help methods

* {{man key press|F1}} context help?
*{{man button|Help}} button
*Tooltips

See:
* {{bug|9677}}:Move "help_url" option to all plugins (and addons)
* {{bug|9678}}:Default help page for addons is the plugins page, not the addons page
==== Existing help API's ====

;gramps.cli
* gramps.cli.argparser.ArgParser.print_help
:<code>print_help()</code> If the user gives the –help or -h option, print the output to terminal.

;gramps.gen
* gramps.gen.plug._pluginreg.PluginData.help_url
:<code>help_url</code> The URL where documentation for the URL can be found
* gramps.gen.plug.menu._option.Option.get_help
:<code>get_help()</code>  Get the help information for this option. Returns: A string that provides additional help beyond the label.
* gramps.gen.plug.menu._option.Option.set_help
:<code>set_help(help_text)</code> 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

;gramps.gui
* gramps.gui.editors.filtereditor.EditFilter.on_help_clicked
:<code>on_help_clicked(obj)</code> Display the relevant portion of Gramps manual
* gramps.gui.editors.filtereditor.EditRule.on_help_clicked
:<code>on_help_clicked(obj)</code> Display the relevant portion of Gramps manual
* gramps.gui.editors.filtereditor.FilterEditor.help_clicked
:<code>help_clicked(obj)</code> Display the relevant portion of Gramps manual

<hr>
Github searches for:
* [https://github.com/gramps-project/gramps/search?utf8=%E2%9C%93&q=WIKI_HELP_PAGE WIKI_HELP_PAGE]
* URL_MANUAL_PAGE
* WIKI_HELP_SEC
* [https://github.com/gramps-project/gramps/search?utf8=%E2%9C%93&q=help_url help_url]
* [https://github.com/gramps-project/gramps/search?utf8=%E2%9C%93&q=help_text help_text]

==== Idea ====
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
* The '''MobileFrontend extension''':  https://www.mediawiki.org/wiki/Extension:MobileFrontend (As by default, MediaWiki does not offer mobile device-specific support, making MediaWiki sites very difficult to use on mobile devices. This has been mitigated in many ways by Extension:MobileFrontend [https://www.mediawiki.org/wiki/Manual:Mobiles,_tablets_and_responsive_design][https://www.mediawiki.org/wiki/Mobile_support_in_MediaWiki_core])

Update media template(skin):
* {{bug|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
** https://www.mediawiki.org/wiki/Manual:$wgDefaultSkin

Have the search box restrict search to just the newer user manual? [https://www.mediawiki.org/wiki/Manual:Using_custom_namespaces Mediawiki:custom namespace]

==== xxx.gramps-project.org ====

Add a Mediawiki instance and new domain for documentation

xxx.gramps-project.org

==== Offline help ====

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.

* Maybe use the code from [https://www.archlinux.org/packages/community/any/arch-wiki-docs/ arch-wiki-docs] that allow you to use pages from Arch [Media]Wiki optimized for offline browsing] and embed a Gramplet/widget that can render html?

= 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.

= See also =
* {{bug|8686}} Prototype for a new "Event Entry" window.
* {{bug|1577}} Cumbersome work flow to add more people to an event
* {{bug|7807}} main window makeover (full-screen option)
* {{bug|8099}} Create hard-copy like documentation as PDF (Suggest installing the [https://www.mediawiki.org/wiki/Extension:Collection 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)'')
* {{bug|10753}} Redesign Gramps to provide a Good looking GUI?

[[Category:GEPS|U]]