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

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 and as well as possible solutions.

= Problem The challenges =

In <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://www.gensoftreviewssourceforge.comnet/?p=1648 GenSoft Review for Windows], [http:/gramps/mailman/message/www.gensoftreviews.com27280108/?p=1649 GenSoft review for MacRe: (Gramps-devel) Focus On User Interface, Usability] and '''</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://www.gensoftreviewssourceforge.comnet/?p=286 GenSoft review for Linux/gramps/mailman/message/27280425/ Re: (Gramps-devel) Focus On User Interface, Usability], some selected comments are:'''</blockquote>

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

==Positive remarks=={{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.}}

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

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

<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 andWhen the new Builder because I add run a large genealogy site with about ahundred kin. It was my intention to find a free software program thatwas hassle free and would be easy for ordinary, non hobbyists. Ones whodon't wanna know about field names and operators to navigate throughtheir ancestry. Sadly Gramps isn't it. I found my 1991 version of FTM has betternavigation that yours and even better than the New touted Family TreeBuilder. So I offer you a few suggestions for your next rewrite. Workon your labels and your search mechanism first... thats stuff theordinary user looks for. Ease of Navigation.  First, so you know where I'm coming from, I've been a database andwebsite designer since about 92 with a person lot of training in PAFdbase/Foxpro/VFP, or Ancestryand then when microsoft took over the world, I see one screen where I enter've donenamesome sqlserver, genderand a bit of XML because the Java programers liked thatold stuff. So I"ve worked with an open source, java group of people and main eventsmy background is different. When I'm a journalist by trade so I do write a lotof documentation. Started out with dBASE on old Osbornes in the same in Grampsmid80s. I was always more USER oriented than PROGRAMMER oriented, whichmakes me gently suggest good programming is to impress USERS, I see halfnot otherprogrammers. It's been hard for early programmers to learn writing forusers with WYSIWYG tools. User interface isn't a dozen screensnatural skill forprogrammers who love writing very tight, interchangeable, one objectoriented back end oriented apps. Less code the better. That's not thesecret to a good programming. Its Intuitive navigation for USERS. ANdthat's all. I think your navigation is far too complex for regular people who wantthe personbuttons intuitive, one extra to add each eventwell labeled and laid out like Microsoft writesmost of their software. Easy on the eyes, key data displayed in BOLDandusing colors... that similarity of arrangement improves peoplescomfort level. I finally quit programming as designed by Dbase II foranother extra to add a location or to choose an existing oneDOS, and started doing things Microsoft's way. That's why Gates is alot of kazillionaire and I'm not ;) Family Trees label should be "OPEN" and the program should default tothe last tree that was used. How many genealogists workmultiple treesand go back and forth everytime they run the program? The old computerword is LOAD, the one for the last twenty years is "FILE and when I want OPEN". Next should be Search or FIND. And it should open a dedicated box to enter birthlast, first, an an easy on the eyes Picker with the most importantfields first. And the ever present search box should be smaller, baptismfitting the fields of last, deathfirst, and burialmiddle, Birthdate like Americansexpect it MMM-DD-YYYY not YYYY-MM-DD. I need at least 9 screens think ya can write code tosort inside your date field, can't you? It's like you've made it easyfor the Programmer but unfamiliar for the USERS. Especially whenkeying in Grampsdata by phone when everyone on earth says month- day -year, where PAF still has only onenot the other way around. Just add code snippet. Andor put a datepreference in Grampsyour setups to please Europeans. I think programming large multi-functional boxes was easy to write butit takes too many keystrokes to pick the function a user wants each timethey open the program. We dont' say "FILTER" anymore with all thosefield buckets. Very old school. We say "FIND" or "SEARCH" and we makethe most common useage default. That'd be NAME, last first. I can'timagine people even caring about ID and why it's actually moreso prominent. Itshould be invisible to users, who search on name, then date of birth.ID is just clutter. That whole filter screen should be hidden in aToolbox because regular people just don't search based on birthdates ordeathdates, marriage dates, very often. Its all about NAME. Why do you break down by GENDER either, and spell it out rather than anon-intrusive 1 character field for M or F? I wouldn't even waste sixspaces with a field label in the browser. I'm just saying youdisplay too many times I filter categories...its too hard to find people, and ata glance see the right fields. Ya know how iTUNES lists, and givesusers ability to change field displays and field order on their browsescreen? You have ID and gender right after Name, and if anything, itshould be NAME, birth date, death date, place of birth--the keyinformation users would need an extra clickto see whether from the people picker. Speaking of the location picker, why don't you just sort on LAST FIRST and notbother with all the filter choices, You have a button for 'regularexpressions"? That so reminds me of Foxpro days when programmers triedto make software users use our lingo. Who uses command lines but oldguard programmers? Bill Gates replaced all that but us old programmerguys just can't let it go, can we? In the lower part of your screen, why do you list by TYPE (personal -1etc). If the event is the most common, BIRTH, just say birth. Noneed for Personal-1, personal -, F amily -0. Under Events and names, abucket displaying any TYPE is just screen clutter and they should behidden. Events should be naturally displayed after birth by eventdate. No need to sort by behind the scenes 'type'. I wish when I had a PERSON selected, I could just always be just a clickaway from PARENTS, and CHILDREN. And have the program intuitive enoughso if I want clicked a parent or a child, the pointer would just go to enter already exists thatperson and repaint all the detail. In short, your navigation is clunky. Okay, I've beaten on you enough. Now about your HELP. Wiki help wastrendy in themid 90s but not anymore. The first thing I wanted to dowas find out what buttons to push to import my GED file...and it took alot of hunting and way too much explanation about your databaselayoutfor me to find it. The whole thing is too wordy and not TASKoriented. In those occasions WHen you write a help screen, it youre only answering onequestion. "HOW DO I....." Yours seems more to be a long treatise onhow the back end of the program is designed. How do I add a new spouse?How do I move or not half move children to that spouse?How can I click on a dozenchild record and see that persons vitals, but spouse,children?Do we really need all the field filters and regular expressions?How can I quickly add a Note without pushing a full bunch of buttons? That's all...I just wanted to vent. Imagine how hard it would besitting with grandma at the kitchen table and entering data as fast asshe can tell it, moving from onekid to the next? Its all about Johnmarried sally on this date...key in her first,middle, maiden, her dateof birth, now let's list the kids. And quickly bring up the kid'srecord so we can add that kid's spouse before moving on to the NEXTkid. or move upwards from people to their parents, thengrandparents...or click click click father records all the way back tothe progenitor?<br>- '''From: RadiomanKC - 2015-12-31 - [https://sourceforge.net/p/gramps/mailman/message/34731862/ (Gramps-devel)Fwd: feedback on Gramps] ;Feedback on MantisDBreally!* <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 ==

The description in [https://www.gramps-project.org/wiki/index.php?title=[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. = 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. 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. </blockquote> <blockquote>I just can'tsee how this can be tackled in the incremental way that Gramps mostlyworks. The 'little improvements over time' approach seems to havegiven us a powerful but unwieldy tool. </blockquote>

== Provide more '''Natural Transcription''' input methods == This is already addressed by [[GEPS_024:_Natural_transcription_of_Records|GEPS 024]].

<blockquote>1. Reduce (gently) the number of different interfaces: this, ofcourse, means that some interfaces will be busier. Too often, confusionresults 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>

* Update [[User_manual|user manual]] to match current (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 

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

* 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]] ]

* Copy the the Gramps master manual to the next major release number.[ [[Rollover_for_the_manual#Rolling_over_the_Gramps_user_manual|Done]] ]

* User guide - General usage and help that refers to the individual dialogs(eg: Help Screens?), but does not repeat the information.

* Gramps Developer documentation - In the sphinx format: [https://gramps-project.org/docs/ Gramps Python API]<!-- ( api.gramps-project.org ) -->

UseInstall 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] ==== xxxxxxx.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?