Re: [Usability] Re: program binary names



> Nautilus File Manager 
> GIMP Image Editor
> Gnome Mines
> Evolution Mail
> Evolution Calendar
> Aisle Riot    (Maybe Ailse Riot Solitaire but I'm not sure that is
needed)
> Time Tracking Tool 
> Same Gnome or Gnome Same Game (it's called Same Gnome partly to
>                                distinguish it from the KDE original)

I'm not sure the distinction is confusing, and I think we would be
better off nixing "Gnome" from names wherever possible. Other than that
I substantially agree with Maciej. Perhaps in the future I can imagine
switching almost entirely over to functional descriptions, but that
isn't really feasible in the present, and Maciej's arrangement of the
words is less awkward.

However, as I pointed out in the previous message, application
developers don't necessarily need to be actively concerned about this.
The functional description field in .desktop will be indepedent on the
name and the two will be composed by the panel. Perhaps you should think
how it would sound to tack the functional description on to the end of
the name though, in case we go with that approach. (I think most good
functional description / name pairs will work without having to plan for
it though)

> As for the tooltips, the user action verb phrase nomenclature can be a
> bit awkward for games and for more complex applications. What would
> you say for Gnumeric or AbiWord or Evolution?

There are exceptions to almost every language...*shrug*

Evolution Mail you could say "Send and Receive Email"
Evolution Calendar you could say "Manage your schedule"

I can't think of a good one for Gnumeric. If you wanted to stick
stringently to the "rule" you could say "Create spreadsheets" or
something dumb like that.

> On an unrelated note, the section on MIME type integration should
> probably mention that you should not install .keys or .mime files that
> are already in the master gnome-vfs database, only for custom types
> not yet in the database. In particular, gnome-vfs has an entry for
> html already and an application should not install it's own.

right, good point. Actually, this raises one technical issue, how do we
deal with conflicts (or does it already?)? For example, as this database
starts being used I can imagine multiple programs registering the same
new type.

-seth






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]