Re: GNOME 2.0 Menu design

["Guillermo S. Romero / Familia Romero" <famrom infernal-iceberg com>]

snickell stanford edu (2001-08-13 at 0019.54 -0700):
> > Internet Web Browser (Mozilla X.X) (Netscape/Mozilla browser) 
> > [Use to browse the Internet or local html documents] 
> Mozilla X.X -> Mozilla
> Why would we put version numbers here? I hope we're not suggesting that
> multiple versions of the same application should be installed at once.
> Otherwise it seems a little pointless...

A small note about versions, people have problems to discover the
version. So putting it in the launch place could help. That or make
the About window be useful always, so users discover it will be always
interesting, not a list of authors (from user POV: do I care who did
it?).

<a bit OT>
I think selectable (copy & paste) version info, package which owns the
files, emails and websites for extra info / bugs, licenses / copyright
and even command line params (eer, excuse me, "launcher params", for
the launch button) are more important that a list of names.

And you will tell me the user does not need to know the version,
really... sure? Have you seen lots of messages like "I bought a book /
got a tutorial for program Foo, but my Foo does not have the same"
(the book / tutorial says "for Foo v X.Y or later") or "it crashes,
are you going to fix it? It is not old, it came in the latest distro"
(the version is old, but he though he has one not much different than
the one announced in the website) or just "it looks different now"
(updated, and user have not realized it yet).

Yes, I know bug buddy, but how do you report problems without
connection (ie problem in PPP tools)? Going to a computer that has
connection, and if you can get the info in a floppy, better than a
paper. Or how do you send the info to something that is not bugzilla,
like the creator of the tutorial? Users, if allowed, discover new
usages.
</a bit OT>

So there is a problem somewhere. Maybe there is a better solution than
launcher with info version, or than a really useful About, but I do
not know it. Splashs screen is not, IMHO, too fast sometimes, disabled
sometimes (a waste for some users, due the multitask system), not
under user control at all.

Also, sometimes multiple versions are useful, different features,
different bugs, customers have different version and you want to check
the look of what you send. Just by saying "you only need one" you are
not solving the other problems.

> > Calendar [Keep track of appointments] 
> Change to "Calendar (Evolution) [Keep ...]"
> Since we're already assuming Evolution will be a defacto install with
> GNOME (for the E-mail client) we might as well use its calendar and
> deprecate the other.

Is it going to appear as Evo with calendar open or as plain calendar?
The deprecation could be a change, something like the old interface
with the component inside, and thus a real demo of components at work.
IOW the integration should work without the need of having all inside
the same app, like DnD a colour from Gimp selector to the panel colour
config, not only from the selector the panel config tool opens.

> > Image Editor (GIMP X.X) (GIMP) 
> > [Create and edit images] 
> GIMP X.X -> GIMP

See above about numbers. This is one of the best examples of that
problem, has some books and many tutorials, and users have the problem
of "unknow version" frequently.

> "Create and edit images" -> "Retouch photographs or create new images"

Eeer, only photographs? Then 3D images are photographs? Or another app
is needed to change them? ;] I think the original phrase is not so
bad, maybe change "edit" to "retouch" or "modify", just that.

> > Font Selector(not sure of the usefulness of this one - removed from
> > GNOME 2.0? - alternatively it could go under developer tools?) 
> Lets kill it.

Just a doubt: suppose a font for an app is needed, and that app is not
a GNOME one, use the xfontsel then? No, thanks. I do not think every
app in Unix will end with a GNOME version. Also it could do a nice job
like calendar: just provide font descriptions, for whatever the user
wants, no just integrated as the coder though.

The colour selector, the character picker and others also fit into
this multipurpose category: be able to do something, and discover new
usages too. There are methods for all them (change colours, change
fonts, insert non typical characters) but the app must have them
first, while having a common tool and DnD or c&p could also work.

I would call that integration has the same level everywhere, not more
integration in some places than in others.

GSR