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