Re: consistency (or lack thereof)

[Ryan Paul <segphault sbcglobal net>]

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 <segphault sbcglobal net>