Raphael Ackermann wrote:
> In the Edit menu:
> The scratchpad should be renamed to "Clip Board" as agreed on the
> issue tracker.
Has anyone suggested that the Scratchpad [Clipboard] menu item might be
moved to the View menu? I would still keep the keyboard hotkey. Hmmm,
should the key be a toggle instead of an activate? Also I notice that
Alt-S doesn't activate it from edit windows. Is that a bug? Or might it
be desirable as a new feature? Copying is often done from/to those edit
> Should we add a copy action that would move the selected object onto
> the "Clib Board". According to the HIG that's what a copy does:) "Copy
> Ctrl+C Copies the selected content onto the clipboard." This would
> also make the scratchpad easier to use. instead of having to drag and
> drop items on it, a simple Ctrl+C would suffice.
Seems like a neat idea, but I can foresee some work being needed (or
questions being asked) about what the "current selected object". For
example on opening an edit box (note: multiple data lines individually
copyable) nothing is highlighted by default. So would that mean there is
no "selected object". This suggestion might be worth playing with a bit.
And if we were to implement Ctrl-C copies into _our_ clipboard, might
that confuse people thinking that Ctrl-C should copy things into the
system clipboard? [This is the reason I thought the term clipboard was
not the best choice, in a prior discussion, but my opinion didn't
prevail there. Waah. :-) Oh wait .. look at item with the ==> pointer a
few pages down.].
> the action|Edit entry seems to be odd. Could it just be Edit?
Where does this wording appear? Oh, I see, Family (and other) Lists (but
not people). Oh, on the Edit menu and the toolbar icon too.
BTW: what about changing "Family List" to "Families".
> Bookmarks menu:
>>From HIG: http://library.gnome.org/devel/hig-book/stable/menus-standard.html.en#Bookmarks
> Gramps uses individual bookmark lists for every view. Bookmarking an
> event will put it on the event bookmark list etc. When editing
> bookmarks, you only see the bookmarks of the view that is currently
> The HIG however say that Edit Bookmarks is for: "Allows the user to
> edit the application's bookmark" which I would understand as all of
> gramps bookmarks and not just he one of the current view. Which makes
> sense for editing. It would also be possible to always show all the
> bookmarks, or at least have a submenu with the bookmarks that do not
> belong to the current view. This would allow the user to jump to a
> bookmark without first having to change the view.
A worthwhile suggestion. Some kind of submenu part appeals to me. Some
presentation design questions no doubt lurk here.
==> The thing I like most about the suggestion is that it reduces the
difficulty of data discovery -- "I know it's in there somewhere, but where?"
> Go menu:
> Why does the People View has a Go menu but other list views do not? It
> has go back and forward and moves between the people last opened in a
> person editor. This use case could also be implemented for other
> views. If somebody is editing sources or places, he could go back and
> forth between them. Is there a reason why there is no Go menu for
> them? Should I file a feature request?
Another worthwhile question. (Your activities are very productive,
Raphael.) If the idea is extended, does that mean a default (family,
source, etc) might be of some value?)
Then, maybe a generic page history might be a reasonable way to extend
it? Then it looks a bit more like a web browser interface. Back/Forward
refer to main pages. Go "Home" might better be changed to something
like default person, but what would happen if you are now viewing a
Hmmm, now you have me thinking that Gramplets, Relationships, and
Pedigree are "real" pages, whereas all the rest are lists that bring up
an edit window for a selected item. Gramplets is kind of special (an
"extra added attraction"), but Relationships and Pedigree are two
different ways of displaying details about a person. I now recall taking
a little while to realize that (classification of windows) when I first
met Gramps. I would say it's very workable, but might like to consider
alternatives for some later version of Gramps.
Addressing your original question from the opposite direction, is the
person history of recognized value that it justifies the menu (and
toolbar icons) space?
A lot of these questions probably have come up before. (I've not been
around so long myself, so I'm guessing.) Even if the current way of
doing things is a deliberate design decision, I would say the questions
(and decisions) deserve being documented. I bet a lot of these things
fall into the category of "well, maybe.., but nobody's got the time to
do it right now" -- or some related explanation, such as there are
complications that make it troublesome at the moment. If it is decided
not to pursue one or more of these suggestions, I still think it might
be valuable to get something into the tracker about it.
..so, anybody: feel free to hit me with my own words when I offer
a suggestion, gripe, whine, snicker, or whatever. Permission is hereby
granted to tell me to formulate it as a tracker feature request.
> Menu titles:
> All the menu titles should be single words. Which is not the case for
> "Family Trees" This could be mistaken for two menu items, "Family"
> and "Trees", but I am not sure whether that is a problem. See the
> guideline below:
> "Menu titles on a menubar are single words with their first letter
> capitalized. Do not use spaces in menu titles, as this makes them
> easily-mistaken for two separate menu titles. Do not use compound
> words (such as WindowOptions) or hyphens (such as Window-Options) to
> circumvent this guideline."
> The HIG also says that if you don't work on Files, then call the Files
> menu something different, which is the case in Gramps. I am not sure
> however whether we actually deal with "Family Trees". "Family Trees"
> http://en.wikipedia.org/wiki/Family_tree are a certain representation
> of somebody's ancestors. A gramps database however usually doesn't
> just hold somebody's ancestors but also descendants and other
> relatives. It might make sense to search for a better word to describe
> what is stored in a gramps db.
I do believe the "Family Trees" term was discussed not too long ago.
There was even some discussion of whether "Family Tree Manager" might be
too close to "Family Tree Maker". I recall the assertion that the
"~Manager" form was not anybody's trade/service mark. As it turns out we
only use the term "Family Trees", so I guess that doesn't matter.
Our working object substitute for files seems more than the usual
interpretation of database. Although maybe "Family Database" might be
more explicit, I think the term "Family Tree" serves the purpose. My
feeling is that the FT term, is ok -- unless someone comes up with a
killer alternative before 3.0 release.
And the double word for the _first_ main-menu item seems to me ok, and
in fact maybe more than ok, because it emphasizes what our working
objects are. I would vote for other names to be single words, though.
> The HIG also has the following guideline: "Do not disable menu titles.
> Allow the user to explore the menu, even though there might be no
> available items on it at that time." Gramps does hide menu items and
> only shows them if there is some content in them. I think that only
> the "Go" menu item is hidden from all the views but People and
> Pedigree. I recommend showing the Go menu item in all the views and
> also add back and forward functionality to the other views. Until
> then, it could just be an empty menu in views who do not support it.
> Or it could just show the Go Home button.
Another place (which I criticize on the "hard to discover" principle) is
Edit > Set Home Person
This menu entry only shows up on when viewing the People list. I don't
see that it would be especially useful to show grayed on other menus,
which makes me think it might not be placed in its ideal spot in the
menu system. But I don't have any other suggestion. It does occur to me
that "Set Home Person' could be on a few context menus though.
> Popup menus: http://library.gnome.org/devel/hig-book/stable/menus-types.html.en#menu-type-popup
> Some work needs to be done on popup menus if they should follow the HI
> # Provide an access key for each item. However, to enhance their
> spatial efficiency and readability, do not show keyboard shortcuts in
> popup menus.
> #Since the user may not be aware of their presence, do not provide
> functions that are only accessible from popup menus unless you are
> confident that your target users will know how to use popup menus.
> --> I think the popup menu items not present in the menubar should be
> added to the menubar, and in some cases it makes sense to add items
> from the menubar to the popup menu.
> #Order items on a popup menu as follows: ....... See the above link
> for ordering guidelines.
I think myself sensitive to accessibility issues, but would nevertheless
place this HIG guideline in a lower-priority category. Trying to come up
with good access keys can chew up a lot of time. If somebody wants to do
it on general principles, well, I would agree that it's better to have
access keys than no access keys. Maybe it should just be done without a
lot of discussion. In case someone is confused, access keys are "hot"
only when the menu is displayed, so that conflicts only need be resolved
within each menu.
> Menu items in general:
> "Label the menu item with a trailing ellipsis ("...") only if the
> command requires further input from the user before it can be
> performed. Do not add an ellipsis to items that only present a
> confirmation dialog (such as Delete), or that do not require further
> input (such as Properties, Preferences or About)."
> Things like "Edit->Compare and Merge" should have ... to indicate that
> there is user input needed
Edit > Preferences
Note: here's a case where Thunderbird seems to differ from standard
behavior of other apps. Tbird uses no elipses, others do. I think if the
dialog allows input of data, the elipsis would be appropriate.
Same for all context menus "Edit" items, eh?
I'm thinking that this is not one of those big things, but it does not
hurt to have a clear policy and be consistent with it.
==> While I'm at looking at it, I've just made a discovery that raises
the issue of which clipboard is which. In the context menu of a person
on the pedigree window (the right-click menu), there is a "Copy" which
copies the text into the system clipboard.
> # Provide options to show toolbar buttons as text, graphics or both—
> see Figure 5-2 for the menus to use for controlling toolbar display.
> Also provide an option to return all toolbars in your application to
> the control center default for this setting.
> I don't seem to be able to find such an option in gramps.
Might be a nice addition for those keeping a features scorecard.
Probably not critical, though. A related thought is to allow users to
choose which icons to put on the toolbar. Might be hard to do, though,
since we have that dynamic toolbar behavior.
Aside: I actually find it a little disconcerting that it changes when
I change windows, so I have the toolbar disabled anyway. I wonder if
anyone else has that reaction? I'm glad that there isn't anything on
the toolbar which is only on the toolbar! The only thing I think I
would use regularly might be the back button, so I don't miss it much.
> Checks to run:
> # Context sensitive menus display correctly (Shift+F10).
> # Tooltips can be popped up and down for all controls that have them
> (Ctrl+F1, Esc).
Tooltips seem like an enormously useful and user-friendly feature. It
might be worth a separate tooltip audit and/or party to deal with that.
- - - - -
Well once again I've rambled a lot. Mostly just expressing personal
preferences, of course. Feel free to "divide the issue" as needed.
> This SF.net email is sponsored by: Microsoft
> Defy all challenges...
I'll try my best ;-)