From: Raphael A. <rap...@gm...> - 2008-01-23 23:42:45
|
I've started reading the Gnome HIG http://library.gnome.org/devel/hig-book/stable/index.html.en and have a few comments and questions regarding what could be done to improve user interaction with gramps. All the menus should be checked for unique mnemonics and if an entry doesn't have a mnemonic to allow keyboard only navigation, then add one. From: http://library.gnome.org/devel/hig-book/stable/menus-standard.html.en Place application-specific menus after the Format menu and before the Go me= nu Which would mean that the Reports and Tools menus should really go just before the Go and the Bookmarks menu, whereas now they are right after the Bookmarks menu. In the Edit menu: The scratchpad should be renamed to "Clip Board" as agreed on the issue tracker. 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 =09Ctrl+C =09Copies 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. the action|Edit entry seems to be odd. Could it just be Edit? Bookmarks menu: >From HIG: http://library.gnome.org/devel/hig-book/stable/menus-standard.htm= l.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 selected. 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. 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? 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. 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. Popup menus: http://library.gnome.org/devel/hig-book/stable/menus-types.htm= l.en#menu-type-popup Some work needs to be done on popup menus if they should follow the HI guidelines. # 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. 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. Toolbar: # Provide options to show toolbar buttons as text, graphics or both=97 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. Checks to run: http://library.gnome.org/devel/hig-book/stable/checks-yourself.html.en # Context sensitive menus display correctly (Shift+F10). # Tooltips can be popped up and down for all controls that have them (Ctrl+F1, Esc). |
From: James G. S. (jim) <jg...@sa...> - 2008-01-24 04:04:14
|
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 windows, no? > 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 > selected. > > 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 place list. 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 > guidelines. > # 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 How about 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. > > Toolbar: > # 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: > http://library.gnome.org/devel/hig-book/stable/checks-yourself.html.en > # 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 ;-) Regards, ..jim |
From: Brian M. <br...@gr...> - 2008-01-24 04:13:34
|
Raphael, > (Your activities are very productive, Raphael.) I have to agree with Jim on this one. I can't even begin to keep up with you. I have managed to read you're whole message. Everything you write is perfectly valid. Some topics have been discussed before, others are new. These activities are extremely valuable to the Gramps project. All I can say is that you control your own destiny. If anything inspires you, go for it. Thanks for all your work! ~Brian |
From: Benny M. <ben...@gm...> - 2008-01-24 08:00:03
|
Raphael, action|Edit and Edit are both needed for translation. The first is the Edit button that opens an editor, the second is the Edit menu entry. In some languages two different words are needed, so the action of editing an object should be given in the modules with 'action|Edit' and the module should use our sgettext instead of gettext. Benny. |
From: Raphael A. <rap...@gm...> - 2008-01-24 08:08:49
|
Thanks for the explanation Benny. Fixed this locally and will commit later. Using sgettext instead of gettext gets rid of the action| bit and only Edit remains. Raphael On Jan 24, 2008 8:59 AM, Benny Malengier <ben...@gm...> wrote: > Raphael, > > action|Edit and Edit are both needed for translation. The first is the Edit > button that opens an editor, the second is the Edit menu entry. > In some languages two different words are needed, so the action of editing > an object should be given in the modules with 'action|Edit' and the module > should use our sgettext instead of gettext. > > Benny. > |
From: Benny M. <ben...@gm...> - 2008-01-24 08:36:57
|
MjAwOC8xLzI0LCBSYXBoYWVsIEFja2VybWFubiA8cmFwaGFlbC5hY2tlcm1hbm5AZ21haWwuY29t PjoKPgo+Cj4gSW4gdGhlIEVkaXQgbWVudToKPiBUaGUgc2NyYXRjaHBhZCBzaG91bGQgYmUgcmVu YW1lZCB0byAiQ2xpcCBCb2FyZCIgYXMgYWdyZWVkIG9uIHRoZQo+IGlzc3VlIHRyYWNrZXIuCj4g U2hvdWxkIHdlIGFkZCBhIGNvcHkgYWN0aW9uIHRoYXQgd291bGQgbW92ZSB0aGUgc2VsZWN0ZWQg b2JqZWN0IG9udG8KPiB0aGUgIkNsaWIgQm9hcmQiLiBBY2NvcmRpbmcgdG8gdGhlIEhJRyB0aGF0 J3Mgd2hhdCBhIGNvcHkgZG9lczopICJDb3B5Cj4gICAgICAgICBDdHJsK0MgIENvcGllcyB0aGUg c2VsZWN0ZWQgY29udGVudCBvbnRvIHRoZSBjbGlwYm9hcmQuIiAgVGhpcwo+IHdvdWxkCj4gYWxz byBtYWtlIHRoZSBzY3JhdGNocGFkIGVhc2llciB0byB1c2UuIGluc3RlYWQgb2YgaGF2aW5nIHRv IGRyYWcgYW5kCj4gZHJvcCBpdGVtcyBvbiBpdCwgYSBzaW1wbGUgQ3RybCtDIHdvdWxkIHN1ZmZp Y2UuCgoKT2ssIG15IGV4cGVyaWVuY2UgaXMgb25lIGhhcyB0byBiZSBjYXJlZnVsbCBub3QgdG8g aW5hY3RpdmF0ZSBleGlzdGluZwphY3Rpb25zLiBJIHRoaW5rIENUUkwrQyBub3cgd29ya3MgaW4g dGhlIG5vdGUgZWRpdG9yLCBhbmQgaXQgY29waWVzIHRvIHRoZQpzeXN0ZW0gY2xpcGJvYXJkIHZp YToKaHR0cDovL3d3dy5weWd0ay5vcmcvZG9jcy9weWd0ay9jbGFzcy1ndGt0ZXh0YnVmZmVyLmh0 bWwjbWV0aG9kLWd0a3RleHRidWZmZXItLWFkZC1zZWxlY3Rpb24tY2xpcGJvYXJkCgpBY3R1YWxs eSwgaWYgQ1RSTC1DIGlzIGltcGxlbWVudGVkLCB3ZSBjb3VsZCBhZGQgdG8gdGhlIHN5c3RlbSBj bGlwYm9hcmQgb3IKdGV4dCB2ZXJzaW9uIGF0IHRoZSBzYW1lIHRpbWUgYnkgdXNpbmcKaHR0cDov L3d3dy5weWd0ay5vcmcvZG9jcy9weWd0ay9jbGFzcy1ndGtjbGlwYm9hcmQuaHRtbApVbmRlciBs aW51eCB0aGF0IHdvdWxkIHdvcmsgZ3JlYXQuIEEgY29vbCBwcm9qZWN0IHRvIGRvLgoKR3JhbXBz IHVzZXMgaW5kaXZpZHVhbCBib29rbWFyayBsaXN0cyBmb3IgZXZlcnkgdmlldy4gQm9va21hcmtp bmcgYW4KPiBldmVudCB3aWxsIHB1dCBpdCBvbiB0aGUgZXZlbnQgYm9va21hcmsgbGlzdCBldGMu IFdoZW4gZWRpdGluZwo+IGJvb2ttYXJrcywgeW91IG9ubHkgc2VlIHRoZSBib29rbWFya3Mgb2Yg dGhlIHZpZXcgdGhhdCBpcyBjdXJyZW50bHkKPiBzZWxlY3RlZC4KPgo+IFRoZSBISUcgaG93ZXZl ciBzYXkgdGhhdCBFZGl0IEJvb2ttYXJrcyBpcyBmb3I6ICJBbGxvd3MgdGhlIHVzZXIgdG8KPiBl ZGl0IHRoZSBhcHBsaWNhdGlvbidzIGJvb2ttYXJrIiAgd2hpY2ggSSB3b3VsZCB1bmRlcnN0YW5k IGFzIGFsbCBvZgo+IGdyYW1wcyBib29rbWFya3MgYW5kIG5vdCBqdXN0IGhlIG9uZSBvZiB0aGUg Y3VycmVudCB2aWV3LiBXaGljaCBtYWtlcwo+IHNlbnNlIGZvciBlZGl0aW5nLiAgSXQgd291bGQg YWxzbyBiZSBwb3NzaWJsZSB0byBhbHdheXMgc2hvdyBhbGwgdGhlCj4gYm9va21hcmtzLCBvciBh dCBsZWFzdCBoYXZlIGEgc3VibWVudSB3aXRoIHRoZSBib29rbWFya3MgdGhhdCBkbyBub3QKPiBi ZWxvbmcgdG8gdGhlIGN1cnJlbnQgdmlldy4gVGhpcyB3b3VsZCBhbGxvdyB0aGUgdXNlciB0byBq dW1wIHRvIGEKPiBib29rbWFyayB3aXRob3V0IGZpcnN0IGhhdmluZyB0byBjaGFuZ2UgdGhlIHZp ZXcuCgoKT2ssIHRoZSBmaXJzdCwgdG8gc2hvdyBhbGwgYm9va21hcmtzIGluIHRoZSBlZGl0b3Ig bG9va3MgbGlrZSBhIGdvb2QKYWRkaXRpb24sIGJ1dCB0aGUgc2NyZWVuIHNob3VsZCBiZSBjYXJl ZnVsbHkgZGVzaWduZWQsIGVnIGEgY29sdW1uIHdpdGgKYm9va21hcmsgdHlwZSBhbmQgc29ydGlu Zy4KQWJvdXQgc2hvd2luZyBhbGwgYm9va21hcmtzIGluIHRoZSBtZW51LCBhdCBsZWFzdCBhIHNl cGVyYXRvciBzaG91bGQgYmUKdXNlZCwgYXQgdGhlIHRvcCB0aGUgYm9va21hcmtzIG9mIHRoaXMg dmlldywgdW5kZXIgaXQgdGhlIGJvb2ttYXJrcyBvZiB0aGUKb3RoZXIgdmlld3MuIE5vdyB0aGF0 IHRoZSBtZW51IG5lZWRzIHRvIGJlIGNvbnN0cnVjdGVkIGF0IGV2ZXJ5IHZpZXcgY2hhbmdlLApz byB0aGlzIGRvZXMgbWFrZSBjaGFuZ2luZyB2aWV3cyBhIGJpdCBzbG93ZXIuCgpHbyBtZW51Ogo+ IFdoeSBkb2VzIHRoZSBQZW9wbGUgVmlldyBoYXMgYSBHbyBtZW51IGJ1dCBvdGhlciBsaXN0IHZp ZXdzIGRvIG5vdD8gSXQKPiBoYXMgZ28gYmFjayBhbmQgZm9yd2FyZCBhbmQgbW92ZXMgYmV0d2Vl biB0aGUgcGVvcGxlIGxhc3Qgb3BlbmVkIGluIGEKPiBwZXJzb24gZWRpdG9yLiBUaGlzIHVzZSBj YXNlIGNvdWxkIGFsc28gYmUgaW1wbGVtZW50ZWQgZm9yIG90aGVyCj4gdmlld3MuIElmIHNvbWVi b2R5IGlzIGVkaXRpbmcgc291cmNlcyBvciBwbGFjZXMsIGhlIGNvdWxkIGdvIGJhY2sgYW5kCj4g Zm9ydGggYmV0d2VlbiB0aGVtLiBJcyB0aGVyZSBhIHJlYXNvbiB3aHkgdGhlcmUgaXMgbm8gR28g bWVudSBmb3IKPiB0aGVtPyBTaG91bGQgSSBmaWxlIGEgZmVhdHVyZSByZXF1ZXN0PwoKClRoZSBi YWNrL2ZvcndhcmQgbWV0aG9kcyBhcmUgY3JlYXRlZCBnZW5lcmFsbHkuIFRoZXkgd2hlcmUgbW9z dCBuZWVkZWQgb24KUGVyc29uLCBidXQgdGhlIGlkZWEgd2FzIHRvIGFkZCB0aGVtIG9uIGFsbCBs aXN0dmlld3MuIE5vYm9keSBjYW1lIGFyb3VuZCB0bwpkbyBpdC4gSXQgaXMgYWN0dWFsbHkgb24g bXkgdG9kbyBsaXN0LiBBbm90aGVyIG5pY2UgcHJvamVjdCB0byBnZXQgdG8ga25vdwpHUkFNUFMu CgpNZW51IHRpdGxlczoKPiBBbGwgdGhlIG1lbnUgdGl0bGVzIHNob3VsZCBiZSBzaW5nbGUgd29y ZHMuIFdoaWNoIGlzIG5vdCB0aGUgY2FzZSBmb3IKPiAiRmFtaWx5IFRyZWVzIiAgVGhpcyBjb3Vs ZCBiZSBtaXN0YWtlbiBmb3IgdHdvIG1lbnUgaXRlbXMsICJGYW1pbHkiCj4gYW5kICJUcmVlcyIs IGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhhdCBpcyBhIHByb2JsZW0uICBTZWUgdGhlCj4g Z3VpZGVsaW5lIGJlbG93OgoKClRoaXMgaXMgdGhlIHByb2JsZW0gd2l0aCBFbmdsaXNoIGxhbmd1 YWdlIDotKApZb3UgZ3V5cyBzcGxpdCB1cCB3b3JkcyB0byBtdWNoIHdpdGhvdXQgbmVlZC4gQSBG YW1pbHkgVHJlZSBpcyBub3QgYSBGYW1pbHkKYW5kIG5vdCBhIHRyZWUsIGl0IHNob3VsZCBiZSBv bmUgd29yZCEgVGhlIEdlcm1hbnMgYW5kIHRoZSBEdXRjaCBhdCBsZWFzdApnZXQgdGhhdCBtdWNo IHJpZ2h0ISA6LUQKCkkgd291bGQgbm90IGNoYW5nZSB0aGlzLCB3ZSBoYXJkIHRpbWUgY29taW5n IHVwIHdpdGggYSBnb29kIHdvcmQgZm9yIGl0LgoKUGVkaWdyZWUuICBJIHJlY29tbWVuZCBzaG93 aW5nIHRoZSBHbyBtZW51IGl0ZW0gaW4gYWxsIHRoZSB2aWV3cyBhbmQKPiBhbHNvIGFkZCBiYWNr IGFuZCBmb3J3YXJkIGZ1bmN0aW9uYWxpdHkgdG8gdGhlIG90aGVyIHZpZXdzLiBVbnRpbAo+IHRo ZW4sIGl0IGNvdWxkIGp1c3QgYmUgYW4gZW1wdHkgbWVudSBpbiB2aWV3cyB3aG8gZG8gbm90IHN1 cHBvcnQgaXQuCj4gT3IgaXQgY291bGQganVzdCBzaG93IHRoZSBHbyBIb21lIGJ1dHRvbi4KCgpM ZWF2ZSBpdCBhcyBpdCBpcywgdGhlIG1vbWVudCBHbyBtZW51IGlzIGltcGxlbWVudGVkIHdlIGFj dGl2YXRlIGl0LiBObyBuZWVkCnRvIHNwbGl0IGhhaXJzLgoKVG9vbGJhcjoKPiAjIFByb3ZpZGUg b3B0aW9ucyB0byBzaG93IHRvb2xiYXIgYnV0dG9ucyBhcyB0ZXh0LCBncmFwaGljcyBvciBib3Ro 4oCUCj4gc2VlIEZpZ3VyZSA1LTIgZm9yIHRoZSBtZW51cyB0byB1c2UgZm9yIGNvbnRyb2xsaW5n IHRvb2xiYXIgZGlzcGxheS4KPiBBbHNvIHByb3ZpZGUgYW4gb3B0aW9uIHRvIHJldHVybiBhbGwg dG9vbGJhcnMgaW4geW91ciBhcHBsaWNhdGlvbiB0bwo+IHRoZSBjb250cm9sIGNlbnRlciBkZWZh dWx0IGZvciB0aGlzIHNldHRpbmcuCgoKSSBmaW5kIHRoaXMgc3R1cGlkLiBHTk9NRSBVYnVudHUg aGFzIHRoZSBsYWJlbHMgb24gYnkgZGVmYXVsdCwgS3VidW50dSBLREUKaGFzIG5vIGxhYmVscyBp biBvdXIgdG9vbGJhci4gR05PTUUgaGFzIGEgc3lzdGVtIHdpZGUgcHJlZmVyZW5jZSB0byB0dXJu IHRoZQpsYWJlbHMgb2YsIGluIEtERSBJIHdvdWxkIG5vdCBrbm93LgpJIHRoaW5rIGxhYmVscyBv biB0b29sYmFycyBhcmUgc3R1cGlkLCBidXQgaWYgdGhleSBhcmUgb24gb3Igb2ZmIHNob3VsZCBi ZQpzeXN0ZW0gd2lkZSBwcmVmZXJlbmNlLiBJZiB5b3Ugd2FudCBsYWJlbHMgdGhlcmUgc2hvdyB0 aGVtIHRvbyBvbgpvcGVub2ZmaWNlLCBmaXJlZm94LCBldm9sdXRpb24sIC4uLgoKQmVubnkK |
From: Eero T. <ee...@us...> - 2008-01-26 18:55:31
|
Hi, On Thursday 24 January 2008, Benny Malengier wrote: > I think labels on toolbars are stupid, They are important for discoverability. Icons are nice once you know what things do, but until that, you need the text. (Note that tooltips are useless on touchscreens, you need a mouse for tooltips. And touchscreens are getting increasingly common, especially on smaller devices.) > but if they are on or off should be system wide preference. If you want > labels there show them too on openoffice, firefox, evolution, ... - Eero |
From: Benny M. <ben...@gm...> - 2008-01-24 08:38:18
|
2008/1/24, James G. Sack (jim) <jg...@sa...>: > > > 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. > I guess you don't like the new bar in new MS Word then? You should see it as a Ribbon! Benny |
From: James G. S. (jim) <jg...@sa...> - 2008-01-24 19:22:14
|
Benny Malengier wrote: > 2008/1/24, James G. Sack (jim) <jg...@sa...>: >> >> 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. >> > > I guess you don't like the new bar in new MS Word then? > You should see it as a Ribbon! Can someone send me a picture of that? Regards, ..jim |
From: Raphael A. <rap...@gm...> - 2008-01-24 08:59:36
|
I've opened a few issues on the tracker so as not to forget the discussion and will hopefully be able to tackle some of them. On Jan 24, 2008 5:04 AM, James G. Sack (jim) <jg...@sa...> wrote: > 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 > windows, no? I was going to suggest to move it to the Tools menu, but the View menu seems to be the better place. http://bugs.gramps-project.org/view.php?id=1635 The reason why Alt+S doesn't work in edit windows is, that it is bound to the De_scription field which can be selected with Alt+S. Shortcuts for Actions/Menu entries shouldn't use the ALT key according to the HIG as it can interfere with standard ALT usage as can be seen in this case. http://bugs.gramps-project.org/view.php?id=1634 > > > 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.]. > http://bugs.gramps-project.org/view.php?id=1636 > > > > 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. > Have fix on my machine. > BTW: what about changing "Family List" to "Families". > I would support this as it would bring it into line with the other views. Fix locally. > > > > 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 > > selected. > > > > 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?" > http://bugs.gramps-project.org/view.php?id=1637 > > > > 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? > > http://bugs.gramps-project.org/view.php?id=1638 [snip] > > Addressing your original question from the opposite direction, is the > person history of recognized value that it justifies the menu (and > toolbar icons) space? > I like it a lot and use it a lot. It means I don't have to go to the People View and find families and person there. It is much faster. > 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. > ..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. > Please file a feature request and elaborate your idea about "real" pages and other views. [snip] > > > 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. It could be on the Bookmarks menu as the root bookmark/ home person. And you could also have a home place etc, even though that might be less useful. It could even stay where it is and be shown on in every view but instead of setting the selected person as the home person, it would open a dialog that would allow you to select the home person. It is really a config/preference thing and could also be hidden in there and shown only in context menu and not in the main menu. (which would be against HIG ;-) ) http://bugs.gramps-project.org/view.php?id=1639 > > > > > 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 > > guidelines. > > # 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. I can see that in popup menus that might take input from various places and be different if invoked in different places it might be difficult to come up with unique access keys. But the other point of not hiding actions in popup menus only is valid and should be addressed if one believes that not everybody knows about the context/popup menu. http://bugs.gramps-project.org/view.php?id=1640 > > > > > 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 http://bugs.gramps-project.org/view.php?id=1641 [snip] > > 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 am having troubles finding the scratch pad because it moves position. I am still using the toolbar though. especially for adding relations in the Relationship view. > > Checks to run: > > http://library.gnome.org/devel/hig-book/stable/checks-yourself.html.en > > # 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. Thanks for your input Jim Raphael |
From: James G. S. (jim) <jg...@sa...> - 2008-01-24 21:06:46
|
Raphael Ackermann wrote: > I've opened a few issues on the tracker so as not to forget the > discussion and will hopefully be able to tackle some of them. Nice work Raphael. Further discussions of individual issues may still (sometimes) deserve posting to the attention of the full list, but now there's a place to refer for past history, to copy pertinent remarks, to ask contributors to summarize their opinions. And people who express interest can be encouraged to monitor the issue. >.. >> ..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. >> > > Please file a feature request and elaborate your idea about "real" > pages and other views. > Oh man, you're taking me seriously? ;-) OK, will do.. :-) (see below) > [snip] (much snippage of good stuff) Collecting issue references: =========================== 0001635: move scratchpad/clipboard to View Menu http://bugs.gramps-project.org/view.php?id=1635 0001634: change ALT+... shortcuts to not use the ALT modifier and use CTRL instead http://bugs.gramps-project.org/view.php?id=1634 0001636: add support for using CTRL+C to copy items to Clipboard/Scratchpad http://bugs.gramps-project.org/view.php?id=1636 0001637: add support to view all bookmarks in bookmark menu or when selecting edit bookmarks. http://bugs.gramps-project.org/view.php?id=1637 0001638: improve history and navigation for views other then Person view http://bugs.gramps-project.org/view.php?id=1638 0001639: make Set Home Person more accessible. (e.g. add to context menu) http://bugs.gramps-project.org/view.php?id=1639 0001640: Add context menu items to main menu as not everybody knows about context menu. http://bugs.gramps-project.org/view.php?id=1640 0001641: add ... ellipsis to menu items that require user interaction. http://bugs.gramps-project.org/view.php?id=1641 ++ and my additions to the list ++ 0001644: need to brainstorm alternatives to the current sidebar/navbar http://bugs.gramps-project.org/view.php?id=1644 001643: Edit windows should link to Relationship (and/or Pedigree) display http://bugs.gramps-project.org/view.php?id=1643 Regards, ..jim |
From: <rom...@ya...> - 2008-01-24 09:46:17
|
Also, there was an issue : gramps.pot ignored sgettext or gettext context (don't remember which one) for both Edit. Raphael Ackermann a écrit : > Thanks for the explanation Benny. Fixed this locally and will commit > later. Using sgettext instead of gettext gets rid of the action| bit > and only Edit remains. > > Raphael > > On Jan 24, 2008 8:59 AM, Benny Malengier <ben...@gm...> wrote: >> Raphael, >> >> action|Edit and Edit are both needed for translation. The first is the Edit >> button that opens an editor, the second is the Edit menu entry. >> In some languages two different words are needed, so the action of editing >> an object should be given in the modules with 'action|Edit' and the module >> should use our sgettext instead of gettext. >> >> Benny. >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Duncan L. <dli...@gm...> - 2008-01-24 12:01:14
|
I haven't noticed a reaction to this: "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 completely agree. I much prefer the vast majority of programs where all menu items are visible and those not currently available/ relevant are grey and not selectable. Do we want to look into implementing this? Duncan |
From: Brian M. <br...@gr...> - 2008-01-24 12:30:47
|
Duncan, > I haven't noticed a reaction to this: > > "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 completely agree. I much prefer the vast majority > of programs where > all menu items are visible and those not currently > available/ relevant > are grey and not selectable. > > Do we want to look into implementing this? Yes. This supports a very important user interface principle: "always be consistent". ~Brian |
From: Don A. <do...@gr...> - 2008-01-24 13:12:56
|
The general rule we followed before was similar to Evolution (GNOME's email tool). Most programs have a single view. So, when a feature is not available, the menu item is greyed out. Typically some action by the (such as selecting an item) will make that menu item active. GRAMPS should be following this for each particular view. However, like Evolution, GRAMPS has multiple views. In each view, some items have no context, and make no sense. There is no action in that particular view that will make these items have any context at all. So, these are removed to match the context. Just like in Evolution, where marking something as "Junk" has no meaning in Calendar view, but does in Mail view, GRAMPS has removed items from the menu that have no conceptual context in the view that the user is in. Try out Evolution, and see if this makes sense. The phrase: "Allow the user to explore the menu, even though there might be no available items on it at that time." implies that the menu item might be available at some time, and in some views, these items will never be available. So, the guideline we followed in the past was: 1) If it can be available in the view, grey it out 2) If it will never be available in the view, remove it In the past, we have agreed that this was consistent with the HIG. Don On Thu, 2008-01-24 at 04:30 -0800, Brian Matherly wrote: > Duncan, > > > I haven't noticed a reaction to this: > > > > "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 completely agree. I much prefer the vast majority > > of programs where > > all menu items are visible and those not currently > > available/ relevant > > are grey and not selectable. > > > > Do we want to look into implementing this? > > Yes. This supports a very important user interface > principle: "always be consistent". > > ~Brian > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Raphael A. <rap...@gm...> - 2008-01-24 13:35:34
|
I think Benny pointed out that this is not a problem because the only menu that is not consistent across views is the Go menu and there are plans to implement history and go functionality for most of the views and then the Go menu could be there in all the views. Raphael |
From: Duncan L. <dli...@gm...> - 2008-01-25 13:50:21
|
On 24/01/2008, Don Allingham <do...@gr...> wrote: > Just like in Evolution, where marking something as "Junk" has no meaning > in Calendar view, but does in Mail view, GRAMPS has removed items from > the menu that have no conceptual context in the view that the user is > in. > > Try out Evolution, and see if this makes sense. Makes total sense. Thanks for explaining it that way. An important difference is that in Evolution each view has a name which is shown at the top. Perhaps GRAMPS could use something similar... Duncan |
From: Don A. <do...@gr...> - 2008-01-25 13:58:04
|
On Fri, 2008-01-25 at 14:50 +0100, Duncan Lithgow wrote: > On 24/01/2008, Don Allingham <do...@gr...> wrote: > > Just like in Evolution, where marking something as "Junk" has no meaning > > in Calendar view, but does in Mail view, GRAMPS has removed items from > > the menu that have no conceptual context in the view that the user is > > in. > > > > Try out Evolution, and see if this makes sense. > Makes total sense. Thanks for explaining it that way. > > An important difference is that in Evolution each view has a name > which is shown at the top. Perhaps GRAMPS could use something > similar... I agree. That makes a lot of sense. Don |
From: Raphael A. <rap...@gm...> - 2008-01-25 14:31:04
|
On Jan 25, 2008 2:50 PM, Duncan Lithgow <dli...@gm...> wrote: > On 24/01/2008, Don Allingham <do...@gr...> wrote: > > Just like in Evolution, where marking something as "Junk" has no meaning > > in Calendar view, but does in Mail view, GRAMPS has removed items from > > the menu that have no conceptual context in the view that the user is > > in. > > > > Try out Evolution, and see if this makes sense. > Makes total sense. Thanks for explaining it that way. > > An important difference is that in Evolution each view has a name > which is shown at the top. Perhaps GRAMPS could use something > similar... I think that most of Gramps is quite closely interrelated. The main focus are people and their relations with each other. Additional info can be attached to a person or a relation. This additional info can be a place, source, note etc. It doesn't make much sense for example to use gramps as a notes application without having people to attach the notes to. Evolution in contrast has email, calendar and other things. You can use each of these things on their own and they could be implemented in their own application. Like Jim mentioned on issue http://bugs.gramps-project.org/view.php?id=1644 The gramps interface hase some navigation views and other views that are nothing more then a view into a database table. Items in this list can be opened or things done to them like merging. Once opened in an editor, the menu bar cannot be used in editors, only in the view (I might be wrong as I cannot double check right now). I don't think that the list views are like a program on their own and need a different menu and toolbars. I could envision however that more navigational views will be built int he future, such as a hierarchical place navigator/editor. Places could have relations just the way people can have now. This might require a different menu. The existing list view remind me more of let's say tabbed worksheets in a spreadsheet program. They are not a different program, but views to different data. The actions that can be done on the data however are very similar for most of the list views. Raphael |
From: James G. S. (jim) <jg...@sa...> - 2008-01-24 22:09:25
|
Raphael Ackermann wrote: > I think Benny pointed out that this is not a problem because the only > menu that is not consistent across views is the Go menu and there are > plans to implement history and go functionality for most of the views > and then the Go menu could be there in all the views. > > Raphael I hope folks will tolerate a tiny whine here. No intent to single out Raphael -- this is just a good example for me to gripe about. ;-) I don't know what the "this is not a problem" refers to above, because prior message context was discarded. And since mail is not guaranteed to arrive in sequence, that compounds the difficulty. I personally like the convention of trimming the message one is replying to -- fairly aggressively -- but leaving enough context to represent a conversation that the reply is responding to. Then it is easy to add the reply text *below* the quoted original context. That makes it as easy to follow as a conversation. Sometimes there is a lot of context, sometimes less. What to trim and what to keep is a matter of judgment. Usually the conversation can be much abbreviated, and usually only the most recent part of the thread needs inclusion. We do have archives, after all. Trimming also allows removing extraneous and/or duplicate signatures, mail list messages, and even advertisements, all of which are simply clutter. It's not so much a problem now that _everybody_ has broadband, but trimming reduces loads on servers and clients. Of course some people are still on dial-up (although probably not likely, here), and lists with large distributions suffer a multiplicative penalty for extraneous content, so there is a small but real "conservation" principle here, too. The practice known as "top-posting" raises religious-like protest storms on some lists, and I don't want to start that kind of argument, but some people may not be familiar with the objections to top-posting. In most cases it is harmless, because the context of the reply is established by the subject, sender, and possibly aided by sparseness of the mail traffic. I find two points most significant: 1. Top posting makes it almost impossible to conduct a running conversation that can be followed by examining the quotes, whereas bottom-posting allows reading like a book A says.. B replies... C replies... because the quotes and replies are in sequence and subsequent quoting preserve the sequence. 2. Top posting takes extra effort to find the context of a reply, and may even invite misunderstandings. Admittedly bottom-posting puts a quote first which you have to skip past when you don't need to study the context, but I would say it's not much penalty (with proper trimming), and worth the cost. I would summarize by inviting people to try the idea, especially when context is important. A little effort by the sender can save MULTIPLE readers' headaches, so it's a social gesture, as well. I would also repeat that in many cases it's not important, so don't take my whining too seriously. :-) Regards, ..jim (and don't forget to trim) |
From: Raphael A. <rap...@gm...> - 2008-01-25 14:23:50
|
On Jan 24, 2008 11:09 PM, James G. Sack (jim) <jg...@sa...> wrote: > > Raphael Ackermann wrote: > > I think Benny pointed out that this is not a problem because the only > > menu that is not consistent across views is the Go menu and there are > > plans to implement history and go functionality for most of the views > > and then the Go menu could be there in all the views. > > > > Raphael > > I hope folks will tolerate a tiny whine here. No intent to single out > Raphael -- this is just a good example for me to gripe about. ;-) > > I don't know what the "this is not a problem" refers to above, because > prior message context was discarded. And since mail is not guaranteed to > arrive in sequence, that compounds the difficulty. It referred to the post by Duncan, I must have cut out too much text. See the original post below: I haven't noticed a reaction to this: "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 completely agree. I much prefer the vast majority of programs where all menu items are visible and those not currently available/ relevant are grey and not selectable. Do we want to look into implementing this? Duncan |
From: Duncan L. <dli...@gm...> - 2008-01-31 19:55:24
|
http://bugs.gramps-project.org/view.php?id=1675 0001675: GRAMPS 'Views' are not named in the window header, or in the view menu Description We often talk about the views in gramps but haven't really done much in the UI to show users that that's the thinking behind the organisation. I propose two additions: 1. That the name of the current view is shown in the window header 2. That the views are added as radio button items to the end of the 'View' menu I would like to make these changes myself as the next step in learning how the code works if that's alright. Additional Information For discussion: 1. For the window header do we want the format: DATABASE_NAME - VIEW_NAME - "GRAMPS" ... or something else? 2. Should we consider splitting the views into two types, those for navigation and those which are purely for viewing. Such a split would be something like: Views: - Pedigree View - are there others? Navigators: - Person View/Navigator/Manager - Family View/Navigator/Manager - Media... etc. Duncan |
From: James G. S. (jim) <jg...@sa...> - 2008-01-31 20:25:33
|
Duncan Lithgow wrote: > http://bugs.gramps-project.org/view.php?id=1675 > > 0001675: GRAMPS 'Views' are not named in the window header, or in the > view menu Description > > We often talk about the views in gramps but haven't really done much in > the UI to show users that that's the thinking behind the organisation. > > I propose two additions: > > 1. That the name of the current view is shown in the window header > 2. That the views are added as radio button items to the end of the > 'View' menu > > I would like to make these changes myself as the next step in learning > how the code works if that's alright. Additional Information For > discussion: > > 1. For the window header do we want the format: > DATABASE_NAME - VIEW_NAME - "GRAMPS" > ... or something else? > > 2. Should we consider splitting the views into two types, those for > navigation and those which are purely for viewing. > Such a split would be something like: > Views: > - Pedigree View > - are there others? Relationships > > Navigators: > - Person View/Navigator/Manager > - Family View/Navigator/Manager > - Media... > etc. > The two suggestions may need to be considered separately. Having view names on the window titlebars seems useful to me. Even though we don't run a telephone customer support operation, it might come in handy in clarifying questions and instructions for users. The View menu probably raises a different set of considerations, which is why I think it might be better discussed separately. Note that at present, there are two views (Gramplets and Relationships) that add custom setting options to the View menu. As an aside (an ongoing gripe about things disappearing from menus), those options seem hard to discover -- but that's a different subject, eh? Regards, ..jim |
From: Duncan L. <dli...@gm...> - 2008-01-31 20:41:55
|
On Thu, 2008-01-31 at 12:25 -0800, James G. Sack (jim) wrote: ... > Having view names on the window titlebars seems useful to me. Even > though we don't run a telephone customer support operation, it might > come in handy in clarifying questions and instructions for users. Yes, and I think it helps users understand the thinking behind the way GRAMPS works. > custom setting options to the View menu. As an aside (an ongoing gripe > about things disappearing from menus), those options seem hard to > discover -- but that's a different subject, eh? Not entirely, this issue started with that objection and is now focusing on how to make users more aware that GARMPS is designed with a set of functionally separate views. In that context your (and earlier also my) objection becomes less relevant. Duncan |
From: Benny M. <ben...@gm...> - 2008-01-31 21:27:48
|
2008/1/31, Duncan Lithgow <dli...@gm...>: > > http://bugs.gramps-project.org/view.php?id=1675 > > 0001675: GRAMPS 'Views' are not named in the window header, or in the > view menu Description > > We often talk about the views in gramps but haven't really done much in > the UI to show users that that's the thinking behind the organisation. > > I propose two additions: > > 1. That the name of the current view is shown in the window header > 2. That the views are added as radio button items to the end of the > 'View' menu > > I would like to make these changes myself as the next step in learning > how the code works if that's alright. Additional Information For > discussion: > > 1. For the window header do we want the format: > DATABASE_NAME - VIEW_NAME - "GRAMPS" > ... or something else? > > 2. Should we consider splitting the views into two types, those for > navigation and those which are purely for viewing. > Such a split would be something like: > Views: > - Pedigree View > - are there others? > > Navigators: > - Person View/Navigator/Manager > - Family View/Navigator/Manager > - Media... > etc. Please, let's stop this talk of splitting the views quickly, quickly, ... It is technically not possible at the moment to do that. It would mean changes to the core GUI elements of GRAMPS, and is not something that can be done in a 3.0.x No problem to think of changes, but please do as Don suggested not so long ago in a thread: take glade, and design a different interface, then post that suggestion. At the moment the views you see and the sidebar icons are a single notebook. Notebooks can only be shown as they are shown at the moment, no splitting, ... A different core GUI element is needed to change the look with signals of our own making to change views if we want something different. That is not so super hard to do for somebody into GTK+, but without a good design, I see no-one stepping forward to do that, even more, it would be foolish to start it without a good design. And with design I mean a gtk mockup, and the way classes should be made to do the interaction (as PageView now, but then for the driving force that determines the view to be visible). Benny |