Usability improvement or not

We often receive the remark of users that not all information is shown nicely in the editors GRAMPS has, and that some functionality is not easily discovered. Our common reply is that the editors are for data entry first, and overview of data is a second. Two remarks keep coming back:

  • The names tab does not show the default name, it is unclear how to change default name or what name tab should hold
  • Only personal events are visible in the person editor, causing people to underuse the family events, or redefine them as personal events

There is truth to this, however making the editors show things more nicely will make data entry a bit more difficult. Nevertheless, let’s offer a possible improvement, grouped lists in the data tabs of the editor:

Name tab as grouped list

Name tab as grouped list

Above screenshot shows a possible change to the name tab of the person editor: two groups are shown, the default name visible at the top of the editor too, and the alternative names.

The aim is to make it clear to the user that he can use this tab to change what is the default name. Also, he sees all names in one place (perhaps some extra columns need to be shown).

The drawback of this approach: the name tab in reality only manages what is in the alternative names grouping, so eg up and down arrow are only in that group, and delete does not work on the default name. Also, the default name can change outside of this tab. All technical issues that make life for a programmer complicated, but need not worry a user in essence to decide what is the better approach.

This idea can be used in the event tab, showing family and personal events in the event tab of a person (but again, you manage only personal events in the person editor).

Good idea? Bad idea?


  • SvenWehner


    I think the idea of showing the default name in the Names tab is very good. But actually I would prefer a less “difficult” solution. Couldn’t you just create a default entry and mark it by using bold letters?
    You have always just (one or) two different groups, so why should you use a tree structure?
    If you do it that way, you shouldn’t have so many problems with sorting, selecting a new default name etc. either.

    Well… grouping in the event tab makes more sense (even if there are most likely just two groups as well). Because it is common, that in each group are multiple entries and I don’t think you could separate them that easily.
    Actually you could paint personal events black and family ones in a lighter color (to show that they are inherited). Then you could add some nice additional icons showing if the event is a personal or a family event (or another type of event?).
    (Is the birth of a child a relevant event, that should be included in a person’s event list?)


  • Benny

    The reasons for grouping are:

    1. it spells things out for the new user. In this case, I do not think it annoys the advanced users. Otherwise people will see something bold and not know what it is.
    2. drag and drop is clear. How do you drag something on the default name to make it the new default otherwise?
    3. code reuse. A tree can be used in other places, one special bold entry would be new code only used here I think

    Playing around with this, I see that sorting is always a mess as it does not reflect the database order. Using one bold entry does not solve this.

    Note that color cannot be used as that goes against the styling of the widgets, we can use bold and italics though. I’ll experiment with cellrenderers, but again, making text bold is actual more difficult to achieve … Same thing for icons. I don’t think icons give extra meaning if there are only two different kinds possible.

Join the Conversation!

You must be logged in to post a comment.

Fork me on GitHub