Re: consistency (or lack thereof)
On 22 Jul 2006, at 07:13, Ryan Paul wrote: There seems to be some confusion about what the first top-level menu should be called in cases where the contents of that menu do not relate to operations that are performed on files. In some cases, particularly in the terminal, using the name File seems a little absurd. As it turns out, Terminal is just a bit of a problematic case, if you follow the HIG guideline about not using File as the primary menu name. The trouble is that terminal refers both to the type of application (like Calculator or Game etc.), and to the type of objects you use it to create (which would be documents in gedit). So whereas in gedit you have a File menu and a Documents menu, in gnome- terminal, if you were to follow the HIG guidelines to the letter, you'd have a Terminal menu and, er... another Terminal menu. Not to mention the fact that there's _already_ a Terminal menu anyway, which is for something else entirely :) Just have one combined Terminal menu then, you might say... which makes some sense up to a point, assuming it wouldn't be too long. But it disrupts the positional consistency of some items-- for example, in a tabbed application, users generally expect a menu immediately to the left of Help for switching between open tabs etc. (which is in fact currently called the Tabs menu, in gnome- terminal). There have been a few discussions about the terminal menus over the years: http://bugzilla.gnome.org/show_bug.cgi?id=76800 http://bugzilla.gnome.org/show_bug.cgi?id=88318 http://bugzilla.gnome.org/show_bug.cgi?id=95350 I'd agree that there's probably considerable room for improvement though. My first go at re-arranging would probably be something like: - s/File/Terminal - s/Tabs/Window (HIG actually says Windows, but I think it really only makes sense for it to apply to tabs in the current window) - Move everything from the current Terminal menu onto the View menu, as they're all things that affect the appearance of the current tab, rather than its content (except perhaps Change Profile) and see how things looked after that. I have also noticed some inconsistencies in GNOME game applications (for which I'm currently engaged in doc revisions). Users start a new game with either Game - New or Game - New Game depending on the application. That one we could probably have a HIG guideline for; in general, the menu name shouldn't be repeated in the menu items, except where it's necessary to disambiguate anything. (That kind of works in English, anyway; I don't know if it would be more troublesome in other languages.) I also occasionally notice places where there is no access key for menu items (a violation of the HIG). A few perpetrators that come immediately to mind: Tools - Scale Images in GThumb, Server - Join Channel in XChat, File - Close All Files in Anjuta. Please just file bugs for those, where possible, with the 'keynav' keyword set (if they're in bugzilla.gnome.org). There are also some naming inconsistencies within individual programs. Image - Scale and Tools - Resize Images in GThumb, for instance, is a good example. This sort of thing is probably best covered by the Documentation Style Guide's terminology list... I know there are plans to revamp that. I don't know if those guys prefer bugs to be filed in bugzilla, or have a wiki page or something... but it would certainly be good to record this and any other terminology inconsistencies you find. At what point is an application expected to adhere to the HIG, and should I try to address HIG violations in applications that aren't officially part of GNOME but use the GNOME libraries? It's certainly worth trying IMHO; it can only benefit everyone in the long run. However, there are likely some maintainers of non-core apps out there who will just close your bugs because they're not interested in HIG compliance for one reason or another, which is unfortunate. (But they're perfectly entitled to do so, of course.) Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On Mon, 2006-07-24 at 14:14 +0100, Calum Benson wrote: On 22 Jul 2006, at 07:13, Ryan Paul wrote: There are also some naming inconsistencies within individual programs. Image - Scale and Tools - Resize Images in GThumb, for instance, is a good example. This sort of thing is probably best covered by the Documentation Style Guide's terminology list... I know there are plans to revamp that. I don't know if those guys prefer bugs to be filed in bugzilla, or have a wiki page or something... but it would certainly be good to record this and any other terminology inconsistencies you find. In bugzilla please. Other - gnome-docu - style-guide -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
As long as we are talking about interface consistency, I'd like to bring up another issue I have noticed while working on documentation. There seem to be a lot of inconsistencies in menu nomenclature. I'll start by looking at the first top-level menu in various applications: * In the dictionary, terminal, and character map utilities it is File * In the Calculator utility it is Calculator * In XChat it's XChat * Beagle-Search uses Search * GNOME games all seem to use Game * Totem uses Movie * Rhythmbox uses Music * Glade uses Project There seems to be some confusion about what the first top-level menu should be called in cases where the contents of that menu do not relate to operations that are performed on files. In some cases, particularly in the terminal, using the name File seems a little absurd. Is this something that needs to be addressed in the HIG? Is it something that is already addressed there and I just didn't notice? I have also noticed some inconsistencies in GNOME game applications (for which I'm currently engaged in doc revisions). Users start a new game with either Game - New or Game - New Game depending on the application. I also occasionally notice places where there is no access key for menu items (a violation of the HIG). A few perpetrators that come immediately to mind: Tools - Scale Images in GThumb, Server - Join Channel in XChat, File - Close All Files in Anjuta. There are also some naming inconsistencies within individual programs. Image - Scale and Tools - Resize Images in GThumb, for instance, is a good example. Assuming that the program needs two separate menu items for this in the first place (rather than just using one and having it behave differently depending on whether or not multiple items are selected) using Resize for one and Scale for the other could confuse users. I'm not entirely sure myself whether or not the naming distinction represents a difference in behavior aside from operating on a single vs multiple files. I don't mean to complain or step on any toes, I just want to know how I can help to resolve these problems. Since I have not previously contributed in this context, I'm not entirely sure about how I should help to address these issues, or if they should even be considered issues at all (I worry that this is just my OCD making an ass out of me ;-). I apologize in advance if it is inappropriate for me to bring this up here. Should I be filing bug reports, or attempting to submit patches to resolve these issues myself? I also apologize in advance for including in my list of issues applications that are not officially part of GNOME. It's hard for me to tell sometimes which apps are part of the desktop and which are included by my distribution. Is that relevant for usability issues? At what point is an application expected to adhere to the HIG, and should I try to address HIG violations in applications that aren't officially part of GNOME but use the GNOME libraries? Thanks for your patience with my n00b questions! -- SegPhault On Fri, 2006-07-21 at 13:42 -0400, Matthias Clasen wrote: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Ryan Paul [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
Ryan Paul wrote: * In XChat it's XChat XChat is not part of Gnome, nor tries to integrate with it in any way. I'd suggest you to take a look at XChat-Gnome, which is a spin-off project trying to respect the HIG... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Menu consistency [was Re: consistency (or lack thereof)]
(This should maybe be moved to the usability list but rather than CC'ing and making the discussion too hard to follow I'll respond here.) On Fri, 21 Jul 2006, Ryan Paul wrote: Date: Fri, 21 Jul 2006 23:13:08 -0700 From: Ryan Paul [EMAIL PROTECTED] To: desktop-devel-list@gnome.org Cc: Matthias Clasen [EMAIL PROTECTED] Subject: Re: consistency (or lack thereof) As long as we are talking about interface consistency, I'd like to bring up another issue I have noticed while working on documentation. There seem to be a lot of inconsistencies in menu nomenclature. I'll start by looking at the first top-level menu in various applications: * In the dictionary, terminal, and character map utilities it is File * In the Calculator utility it is Calculator * In XChat it's XChat * Beagle-Search uses Search I must be looking at the wrong thing because I dont see any menus http://beagle-project.org/Image:Best-shot-thumb.png (Further googling suggests that page may be out of date.) * GNOME games all seem to use Game * Totem uses Movie[1] * Rhythmbox uses Music[1] * Glade uses Project Also File roller uses the a menu labelled Archive, unlike Stuffit, Winzip, Winrar and others popular archiving applications. To better organise things into two shorter menus I suggested using a standard File menu for the basic file operations and an archive menu for Archive specific operations (Add, Remove, etc). http://bugzilla.gnome.org/show_bug.cgi?id=164505 There are also a few multimedia applications which use the menu Disc consistently. If I recall correctly Gnomemeeting/Ekiga uses Call and various Chat applications use either Chat or connect. Generally speaking I think there is room for an additional top level menu and it is better to group things out rather than having an overly long first menu. Microsoft office had a fairly consistent menu layout: File, Edit, View, Insert, Format, Tools, %VARIABLE%, Window, Help. The menu that varied was the most application/document specific: Table in Word, Data for Excel, and Slide show in Powerpoint (ugly use of two words for a top level menu). Similarly most applications could have a standard File menu and another menu for more application specific items, like how EoG has both a File menu and an Image menu. Part of the problem is there is a truck sized hole in the HIG which developers have happily been driving through. Developers do great work and like to think they are exceptional, which for them trumps consistency. The HIG doesn't strongly advise against not using a File menu, so it isn't like other cases where we might argue they should push for changes in the HIG first before making their application inconsistent. http://developer.gnome.org/projects/gup/hig/1.0/menus.html#standard-menus If your application does not operate on documents, name this item for the type of object it displays. For example, many games should have a Game instead of a File menu. A file menu makes little sense in a calculator. It doesn't make much sense in a Game either but if a game did save games which could be saved out and loaded in then in that case I would say it should have a File menu. http://bugzilla.gnome.org/show_bug.cgi?id=172297 The general idea is that in a task based program there are none of the basic file operations like Open, Close or even Save sometimes, in which case there is less of a strong reason for a File menu. However in document based applications there are these file operations but rather than simply having a File menu and there was some suggestion that it might be better to replace the file menu with a document specific menu. Another part of the problem is the lack of stock top level menus which I believe would make things easier and encourage developers to follow the path of least resistance. I have also noticed some inconsistencies in GNOME game applications (for which I'm currently engaged in doc revisions). Users start a new game with either Game - New or Game - New Game depending on the application. Gnome games has its own stock items and I'd expect them all to be using Game, New Game although I did suggest they avoid the redundant repitition. Other games are probably using the stock new item. GThumb [...] (rather than just using one and having it behave differently depending on whether or not multiple items are selected) There are several cases where gthumb has two menu items for the one file and multiple file versions of very similar tasks. I think this may have been improved in relation to some of the keybinding requests I made but I'm not sure. issues at all (I worry that this is just my OCD making an ass out of me ;-). I apologize in advance if it is inappropriate for me to bring this up here. Should I be filing bug reports, or attempting to submit patches to resolve these issues myself? Submitting patches will get things part of the way but in cases where developers disagree with the suggestion you would need
consistency (or lack thereof)
Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
2006/7/21, Matthias Clasen [EMAIL PROTECTED]: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... Unless the user testing told that Finish is right there, I'd go for consistency until a know right text is found. Or just dump the button and rely on the window manager (yeah, IIRC user testing proved that one wrong too...). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On Sex, 2006-07-21 at 13:42 -0400, Matthias Clasen wrote: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? No, please let's fix this. Besides the lack of consistency with other capplets, it makes absolutely no sense at all to have a Finish button, especially since it uses the stock icon for Apply. This is very confusing even for me because I think this is an apply button with a different wording: I have to click on it for settings to be saved; or, if I don't click on it, my changes are reverted. Of course none of those are true. The Finish button only makes sense in a task-oriented interface. It makes some sense when using the Change Desktop Background desktop popup menu, because it is worded like a task description. It makes no sense when accessing the same preference through Preferences-Desktop Background. This highlights another inconsistency: Change Desktop Background in the desktop popup menu should be Desktop Background Properties instead. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On Fr, 2006-07-21 at 13:42 -0400, Matthias Clasen wrote: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? We have had an argument about this in #gnome-de some time in the past, I'll repeat my opinion here. Well, the HIG say Close IIRC, so, I think everything should be the way the HIG say. The question Finish vs. Close should not be a control-center specific question but a HIG-specific question on the usability list. Regards, Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
Op Fri, 21 Jul 2006 20:51:12 +0200, schreef Sven Herzberg: We have had an argument about this in #gnome-de some time in the past, I'll repeat my opinion here. Maybe you had it in #gnome-de, but it was definitely discussed on this list or the usability list too (it's too hot now to go look it up). Ask dobey for the details, but IIRC Novell user testing showed convincingly that a majority of test subjects didn't know/expect that Close would save their changes. Therefore, first it was made explicit-apply but after a storm of protest, it became instant apply again but with different wording. So if we want to make things consistent, we should consider making every instant-apply Close button a Finish button instead. Well, the HIG say Close IIRC, so, I think everything should be the way the HIG say. The HIG is a set of guidelines that are evolving, they are not set in stone. regards, -- Reinout van Schouwen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
Matthias Clasen wrote: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? I think there are a number of ways you could interpret the results of that user study. A user stating that 'Close' didn't make them think that their changes would be saved could mean that you change the button from 'close' to 'finish' or 'save' or 'done'. But you could also do lots of other things to ensure that a person feels their changes in the background capplet are saved. I think it would be advantageous and fair for people to discuss the root problem and prototype the changes, then decide the right change that other capplets could take advantage of. It seems hasty and incorrect to just change the one capplet and not the others, did user testing show that people felt the other capplets were saving even with only a close button? ~ Bryan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On 7/21/06, Reinout van Schouwen [EMAIL PROTECTED] wrote: So if we want to make things consistent, we should consider making every instant-apply Close button a Finish button instead. Well, the HIG say Close IIRC, so, I think everything should be the way the HIG say. The HIG is a set of guidelines that are evolving, they are not set in stone. The correct way is then to bring it up to the HIG and say User testing shows XYZ. Once it is changed in the HIG then all relevent things can be changed and consistency is maintained. The incorrect way is this way, change one, and then leave it there. iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On Jul 22, 2006, at 9:42 AM, Reinout van Schouwen wrote: ... Ask dobey for the details, but IIRC Novell user testing showed convincingly that a majority of test subjects didn't know/expect that Close would save their changes. ... But it *didn't* save their changes, and renaming it to Finish doesn't change that. I can close the window using the button in the title bar instead, or even using xkill, and my new choice of background doesn't revert itself. Anyway, there are several bigger unfixed problems with this window. http://mail.gnome.org/archives/usability/2006-March/msg00213.html -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
