Alternative menu; I call her 'Ami'
Klein Duijmpje
this month about introducing a 'Print One Copy' option to Aphrodite's
menu eventually triggered me to give this whole menu idea some more
thought.
"What if it were all op to me?" I wondered. How would I resolve this
specific issue and how in a more broader sense would I have set up the
menu structure....
Well I decided to take it all a bit further and work it out some...
Should anyone here be curious and/or interested in what my crazy gray
cells have come up with, you can have a look here:
http://home.zonnet.nl/p.duijm/ami/
Yes I call 'her' 'Ami'.... an Alternative Menu Initiative :-)
Just thought I'd share her with you.
Peter
pete collins
>
All i can say is wow . . .
Simon P. Lucy
the css and dtd files in the chrome/navigator directory tree to your hearts
content, but take a copy of it first as its one of the easiest ways to
produce a dead lizard. If you created the web pages on your URL giving the
menu structure then you have the sufficient skills to do it.
Simon P. Lucy
-----Original Message-----
From: Klein Duijmpje [mailto:kleind...@yahoo.com]
Sent: 24 March 2000 22:54
To: mozil...@mozilla.org
Subject: Alternative menu; I call her 'Ami'
The discussion in this group that started somewhere around the 15th of
this month about introducing a 'Print One Copy' option to Aphrodite's
menu eventually triggered me to give this whole menu idea some more
thought.
"What if it were all op to me?" I wondered. How would I resolve this
specific issue and how in a more broader sense would I have set up the
menu structure....
Well I decided to take it all a bit further and work it out some...
Should anyone here be curious and/or interested in what my crazy gray
cells have come up with, you can have a look here:
http://home.zonnet.nl/p.duijm/ami/
Yes I call 'her' 'Ami'.... an Alternative Menu Initiative :-)
Just thought I'd share her with you.
Peter
Steve Morrison
Umm, I looked at your site and couldn't tell what Ami looks like or, really,
what problem it's trying to solve. Do tell?
-Steve
Klein Duijmpje
> >
> > The discussion in this group that started somewhere around the 15th of
> > this month about introducing a 'Print One Copy' option to Aphrodite's
> > menu eventually triggered me to give this whole menu idea some more
> > thought.
> >
> > "What if it were all op to me?" I wondered. How would I resolve this
> > specific issue and how in a more broader sense would I have set up the
> > menu structure....
> >
> > Well I decided to take it all a bit further and work it out some...
> >
> > Should anyone here be curious and/or interested in what my crazy gray
> > cells have come up with, you can have a look here:
> > http://home.zonnet.nl/p.duijm/ami/
> >
> > Yes I call 'her' 'Ami'.... an Alternative Menu Initiative :-)
> >
> > Just thought I'd share her with you.
> >
> > Peter
Steve Morrison wrote:
>
> Umm, I looked at your site and couldn't tell what Ami looks like or, really,
> what problem it's trying to solve. Do tell?
>
> -Steve
Hmmm I didn't realize that the navigation on my little site was so
unclear or confusing...(is it really??)
'Ami' is a menu structure design for the Navigator component of Mozilla
and can be viewed as HTML
pages under 'Navigator' --> 'Menu structure' if you go to:
http://home.zonnet.nl/p.duijm/ami/ (the home page) or click on 'Menu
structure' if you go directly here:
http://home.zonnet.nl/p.duijm/ami/navigator/
When you click on 'Menu structure' the menu bar will be displayed and
from here you can select any menu choice you wish.
Any pulldown and any submenu within the pulldown. Just let your mouse
glide over these elements and you'll realize there are hyperlinks :-)
As to 'problem' that I'm trying to resolve.... Well I wouldn't consider
it a 'problem' as such but I have tried to create a simplified menu
structure that I feel is more pleasant to work with and well more
intuitive from my perspective anyway :-)
Peter
Matthew Thomas
-- but it crashed on me after about a dozen paragraphs. Still, it was
the closest I'd ever got to actually sending a message using Seamonkey.
Klein Duijmpje wrote:
>...
> Should anyone here be curious and/or interested in what my crazy gray
> cells have come up with, you can have a look here:
> http://home.zonnet.nl/p.duijm/ami/
>
> Yes I call 'her' 'Ami'.... an Alternative Menu Initiative :-)
>...
Well, there's a lot of work here. Very impressive. Competition is
good. :-)
A few comments:
* If you're going to use custom colors in a Web site, please do so
either with CSS, or with BODY BGCOLOR and BODY TEXT -- not with BODY
BGCOLOR and then FONT COLOR. Your site has white writing on a white
background when I visit it, so I have to go into the color prefs to
turn off `Always use my colors' before I can read it.
* | Furthermore if we take the term 'documents' literally we may as well
| throw this whole idea of the File menu out the window as there are
| many applications that don't deal with documents at all.
If we *really* took the term `documents' literally, even applications
which did deal with documents wouldn't have a File menu until you had
printed the document!
In graphical user interfaces, a `document' is whatever object the app
deals with most, and computer users are used to that and understand
it. For example, in a word processor it's documents which are dealt
with most. In Mozilla's Bookmarks window, it's bookmarks (even though,
underneath, all the bookmarks are stored in a single file). In the
Address Book, it's address cards (ditto). And so on.
In Navigator, the main item being dealt with is not actually Web pages
-- they're the main item in Composer, but not Navigator. No, in
Navigator the main item dealt with is Navigator windows themselves.
Web browsers are almost unique in this regard. It's because in Web
browsers, unlike most other apps, switching from one document to the
next doesn't involve closing one window and opening a new one. It's
just following a link, which opens a new document in the same window.
(German Bauer doesn't seem to have grasped this fundamental difference
between browsers and other apps yet. That's why, in Mozilla, when you
use `Open File' from the File menu or `View Image' from the context
menu, the file or image is loaded into a new window instead of the
current one. This is contrary to the behavior of other Web browsers,
including all previous versions of Netscape, but it's in German's spec
that the file or image should be opened into a new window. Until
recently, this happened with `Open Location' too.)
So when you choose `File' > `New' in Navigator, you're talking about a
new browser window, not a new Web page. And when you choose `File' >
`Close', there is zero probability that Mozilla will ask you if you
want to save changes to the Web page -- because the page is not the
document in question, the window is. It is the window you are closing,
not the page.
* | My point here is that we have trouble applying this concept of the
| File menu to browsers and it seems to me that the term 'file' really
| is a bit illogical and too much of a technical reference.
Actually, that's not what it means. The word `File' as a menu title
isn't used as a noun; it's used as a verb.
Generally, titles of menus should be verbs. Why? Because that's the
basic grammar of a graphical user interface: you select an object (a
noun), and then you perform an operation (a verb) on that object.
That's why File, Edit, View, Insert, and Format, the common menu
titles, are all verbs. Parts of speech other than verbs are generally
only used where there isn't an appropriate verb -- such as the
`Special' menu in the MacOS Finder, the `Tools' menu in many apps,
and of course `Help' (which is a verb, but the wrong way round -- if
used as a verb it would imply that you were giving help rather than
receiving it). The other occasion is when the verb `change' is implied
-- for example, many word processors have a `Font' menu, where the
menu title implicitly means `change the font'.
In Aphrodite, I'm assuming that `bookmark this page' is in common
enough usage now that `bookmark' is considered a verb. That's why
Aphrodite has a `Bookmark' menu, and not a `Bookmarks' menu. I do,
however, break the verb rule for the {component-name} menu -- the
`Navigator' menu in Navigator, the `Messenger' menu in Messenger, and
so on. I use that menu title to help identify the component, so the
only way it could be a verb would be if the components were renamed to
be verbs. And that would be kinda silly.
So anyway, `File' is a verb. Filing is the general housekeeping you do
with items -- no matter whether they are word processing documents,
images, browser windows, or whatever.
I'm actually not surprised you didn't realize this -- the user
interface people at Commodore didn't get it either. When they
published the Amiga interface guidelines, they suggested that the
first menu in an Amiga app be `Project', rather than `File'. But
`project' has quite the wrong meaning when considered as a verb, and
even Commodore switched back to `File' for the Amiga Workbench itself
by the time AmigaDOS 3.0 came out.
* | I would expect a word processor (e.g. Word) to use the term
| 'document' and hence have a 'Document menu', I would expect a
| graphical application (e.g. Paint Shop) to use the term 'image' and
| thus have an 'Image menu', and yes I would expect a disk management
| tool (e.g. Explorer) to use the term 'file'.
Not only are none of your suggested titles verbs (well, `file' is, but
you're not using it as one in this case), but such a scheme would also
be (if you'll excuse me for saying so) a right pain to use.
Firstly, the keyboard mnemonics would be different in every app. With
a consistent File menu, I can press Alt+F+P (on Windows or Unix) in
any app, and be reasonably sure that I'll get a Print dialog. But with
your scheme, this keyboard sequence would be Alt+D+P in Word, Alt+I+P
in Paint Shop Pro, Alt+F+P in Explorer, Alt+P+P in Navigator, and so
on. This inconsistency would make using the keyboard to access menu
commands decidedly more difficult.
And secondly, using the menus with the mouse would be more difficult
too. You have kept the `Edit' and `View' menus from the traditional
menu layout; but because the first menu would have a different name
(and therefore the menu title would be of a different width) in each
app, the position of the Edit and View menus would be different
between apps.
This would constantly thwart any attempt by a user's brain to develop
a muscle memory of the movement required to get to these menus. (In
addition, on MacOS the Edit and View menus would jump around merrily
on the menu bar as you switched between apps.) This would be
especially bad since the names of most apps are quite long, and
therefore the variability in the pixel-lengths of their names is quite
large.
* | The bottomline is that I feel that we should no longer refer to it
| as the File menu and I would favor a generic component/application
| menu, which in the case of the browser component of Mozilla would
| hence be the 'Navigator menu'. This menu should only contain options
| that are directly related to global aspects of the application and
| its behavior. In the case of Navigator what we find here is 'window
| handling' and quitting the application.
Actually, MacOS X apps have an Application menu, to the left of the
File menu, which largely does what you describe. (The icon for the
app, rather than the app name, is used as the menu title so that
the jumping menus problem is not an issue.) The Application menu
contains About, Preferences, Quit, and assorted other global items.
But MacOS X apps still have a File menu, for items involving the
filing of documents.
* | With Aphrodite's menu Matthew Thomas had originally introduced a
| different method of capitalizing the menu items. Unlike the common
| practice of capitalizing every noun and verb, Matthew chose to
| capitalize the 'important' words within a menu option.
Yes, but I changed my mind. The reason I did so is not only because
several people on n.p.m.ui didn't like it, but also that it doesn't
really work. For example,
------
Add bookmark
Add bookmark As ...
------
is quite logical under my original scheme, because `As' is the
important word in the second item (differentiating it from the first
item). But that doesn't stop it from looking exceedingly strange.
--
Matthew `mpt' Thomas, usability weenie
http://critique.net.nz/
Marshall
View Source wasn't under the view menu. Its under the Page menu. Of
course I'd expect Page Info to do under the Page menu :P
Sjoerd Visscher
> | File menu to browsers and it seems to me that the term 'file' really
> | is a bit illogical and too much of a technical reference.
>
> Actually, that's not what it means. The word `File' as a menu title
> isn't used as a noun; it's used as a verb.
Really?
As far as I know the verb File means something like 'Archive' or
'Save' even. I don't think new or open would be in the File menu
if it means that. But I do not speak English natively, so I may
be wrong.
And, in all software-translations I know file is translated
as a noun.
Sjoerd
Klein Duijmpje
Thank you for taking the time to have a look at 'Ami' and for your
feedback. 'Ami' is indeed 'different' and hence there are bound to be
things that one has to get used to…
In my perspective of the 'View' menu this should contain options that
are of relevance to the way the page is shown within the browser, thus
the page rendering. Now this obviously means things as 'increase font',
'decrease font', 'styles' and 'character set'. It also includes options
that change the browser in terms of available 'real-estate', such as
which toolbars you wish to have visible. All these influence the way you
see (view) the page.
In this respect (in the context that I see it) 'Page source' has no real
business being on the 'View' menu as with this option you intend on
looking 'under the hood' so to speak.
As I state on my site I felt that the 'View' menu needed some 'cleaning'
up and hence both 'Page source' and 'Page info' can now be found under
the newly introduced 'Page' menu.
Peter
Klein Duijmpje
>
> Ummm if you want to play with your friend then you can edit netscape.xul,
> the css and dtd files in the chrome/navigator directory tree to your hearts
> content, but take a copy of it first as its one of the easiest ways to
> produce a dead lizard. If you created the web pages on your URL giving the
> menu structure then you have the sufficient skills to do it.
>
I realize the possibilities are there (of course) but it is a matter of
knowing how and where to make adjustments to achieve the desired result
(a different menu structure).
I did fool around a bit with Aphrodite's menu to see if I could manage
it but with little luck so far. This is how I discovered that indeed
editing the XUL file is rather a sensitive issue and I managed to
produce a 'dead lizard' several times (yes I did save the stuff first).
The fact that it was not as easy as I thought (just yet) made me create
my site in the first place. At least I know how to show what I mean
through HTML :-)
So yes I did create the pages myself but hey IMHO HTML editing isn't
exactly the same as XUL.......
Peter
Klein Duijmpje
>
> Well. I actually got a looong way through a reply to this in Seamonkey
> -- but it crashed on me after about a dozen paragraphs. Still, it was
> the closest I'd ever got to actually sending a message using Seamonkey.
Thank you for taking the time to have a look at 'Ami' and more so taking
the time to give me your feedback (twice). Sorry to hear about your
problems with Seamonkey and I'm more than convinced it was a wonderfully
elaborate and well founded reply.
I'm no 'usability weenie' myself and do enjoy seeing the time and effort
(and passion) you put into your replies here in the newsgroup. I don't
always agree with them but that's a different story….
>
> Klein Duijmpje wrote:
> >...
> > Should anyone here be curious and/or interested in what my crazy gray
> > cells have come up with, you can have a look here:
> > http://home.zonnet.nl/p.duijm/ami/
> >
> > Yes I call 'her' 'Ami'.... an Alternative Menu Initiative :-)
> >...
>
> Well, there's a lot of work here. Very impressive. Competition is
> good. :-)
>
As to competition…. One thing I do know we both seek simplicity of the
menu structure and we both seek a certain degree of consistency across
the components. But as the saying here goes 'there are more roads that
lead to Rome' :-)
And thank you :-)
> A few comments:
>
> * If you're going to use custom colors in a Web site, please do so
> either with CSS, or with BODY BGCOLOR and BODY TEXT -- not with BODY
> BGCOLOR and then FONT COLOR. Your site has white writing on a white
> background when I visit it, so I have to go into the color prefs to
> turn off `Always use my colors' before I can read it.
>
Okay first you are right that using CSS would have been nicer or perhaps
even better. But to tell you the truth things kinda got out of hand. I
started on it late one night just to see if I was able to 'get my
message across' with HTML and before I knew it I had indeed created a
little site…
If I had known this form the onset I would have create more correct code
with CSS and all.
I'll put your comment on my 'wish list' but it doesn't really have the
highest priority at the moment…
Anyway I guess I 'forced' you to see it the way I wish it to be seen…
> * | Furthermore if we take the term 'documents' literally we may as well
> | throw this whole idea of the File menu out the window as there are
> | many applications that don't deal with documents at all.
>
> If we *really* took the term `documents' literally, even applications
> which did deal with documents wouldn't have a File menu until you had
> printed the document!
>
> In graphical user interfaces, a `document' is whatever object the app
> deals with most, and computer users are used to that and understand
> it. For example, in a word processor it's documents which are dealt
> with most. In Mozilla's Bookmarks window, it's bookmarks (even though,
> underneath, all the bookmarks are stored in a single file). In the
> Address Book, it's address cards (ditto). And so on.
>
> In Navigator, the main item being dealt with is not actually Web pages
> -- they're the main item in Composer, but not Navigator. No, in
> Navigator the main item dealt with is Navigator windows themselves.
> Web browsers are almost unique in this regard. It's because in Web
> browsers, unlike most other apps, switching from one document to the
> next doesn't involve closing one window and opening a new one. It's
> just following a link, which opens a new document in the same window.
I don't agree with you that Navigator's mainly deals with windows and
not pages.. Hmmmm…
File --> New window okay that I follow. And closing a window I can also
grasp… But then what about Print --> Window? Saving ---> Window? Surely
we are dealing with pages… are we not? And we find these also under the
File menu…. Well my mind boggles but perhaps it is just me…
>
> (German Bauer doesn't seem to have grasped this fundamental difference
> between browsers and other apps yet. That's why, in Mozilla, when you
> use `Open File' from the File menu or `View Image' from the context
> menu, the file or image is loaded into a new window instead of the
> current one. This is contrary to the behavior of other Web browsers,
> including all previous versions of Netscape, but it's in German's spec
> that the file or image should be opened into a new window. Until
> recently, this happened with `Open Location' too.)
>
> So when you choose `File' > `New' in Navigator, you're talking about a
> new browser window, not a new Web page. And when you choose `File' >
> `Close', there is zero probability that Mozilla will ask you if you
> want to save changes to the Web page -- because the page is not the
> document in question, the window is. It is the window you are closing,
> not the page.
Of course I do and did realize that the term 'documents' must not be
taken that literally and in the 'spirit' of computer applications one
actually means 'whatever object the application deals with most'.
My examples of 'Document', 'Image' and 'File' are I believe fitting in
an OO-design concept. I had a look at IBM's CUA guidelines for OO
interface design and there they have an example of an application for a
car dealership and the first menu item is actually called 'Car'…
I did consider for a moment that with 'File' one actually means the verb
and not the noun. Though I am sure it all started out like this (I will
assume this), I still have the impression that with what we find on the
'File' menu in certain applications seeing this as a verb is really
stretching it a bit. Actually even as a noun it doesn't always make
sense.
I have to agree with Sjoerd who states in his response:
"As far as I know the verb File means something like 'Archive' or 'Save'
even. I don't think new or open would be in the File menu if it means
that."
It would be interesting to find out how many people actually perceive it
as a verb and how many see it as a noun (and how many really don't give
a hoot).
As far as I know all applications translated into Dutch perceive it as a
'noun' and hence use the word 'Bestand' (literally file).. So surely
illogical for non English users don't you think. Like I said it is too
much of a technical reference.
I think it is a nice guideline to try and make all the menu titles verbs
but one shouldn't 'force' this. And I also don't believe many
applications actually conform to this anyway (as stated certainly not in
translated versions).
Anyway seems to me there is enough reason for confusion and that in
itself sort of proves my point that I would prefer to no longer call it
the File menu and hence prefer the component/application menu.
> * | I would expect a word processor (e.g. Word) to use the term
> | 'document' and hence have a 'Document menu', I would expect a
> | graphical application (e.g. Paint Shop) to use the term 'image' and
> | thus have an 'Image menu', and yes I would expect a disk management
> | tool (e.g. Explorer) to use the term 'file'.
>
> Not only are none of your suggested titles verbs (well, `file' is, but
> you're not using it as one in this case), but such a scheme would also
> be (if you'll excuse me for saying so) a right pain to use.
>
> Firstly, the keyboard mnemonics would be different in every app. With
> a consistent File menu, I can press Alt+F+P (on Windows or Unix) in
> any app, and be reasonably sure that I'll get a Print dialog. But with
> your scheme, this keyboard sequence would be Alt+D+P in Word, Alt+I+P
> in Paint Shop Pro, Alt+F+P in Explorer, Alt+P+P in Navigator, and so
> on. This inconsistency would make using the keyboard to access menu
> commands decidedly more difficult.
I agree that the change in keyboard mnemonics is a bit of a bother. This
is a bit unfortunate and one is bound to run into this problem if you
wish to rearrange things through out the various menus. It is the price
of change. Going back to the 'File menu' would only resolve that for
those options. But not all can be found there anymore with Ami…. So yes
some re-learning.
>
> And secondly, using the menus with the mouse would be more difficult
> too. You have kept the `Edit' and `View' menus from the traditional
> menu layout; but because the first menu would have a different name
> (and therefore the menu title would be of a different width) in each
> app, the position of the Edit and View menus would be different
> between apps.
>
> This would constantly thwart any attempt by a user's brain to develop
> a muscle memory of the movement required to get to these menus. (In
> addition, on MacOS the Edit and View menus would jump around merrily
> on the menu bar as you switched between apps.) This would be
> especially bad since the names of most apps are quite long, and
> therefore the variability in the pixel-lengths of their names is quite
> large.
I wonder how much of a bother it really is if the menu items shift left
or right a tad bit per component/application due to the width of the
name op the application menu title. Is muscle memory really that
sensitive? I doubt it…
I think in terms of consistency it is very important that the menus are
always in the same order so that you don't suddenly discover something
has moved all the way to the right or to the left in a different order
on the menu bar.
So you know Help is always the option most to the right and the
application menu is the one most to the left.
It is also important that one always finds an option within the same
menu across components. It can't be that in one instance preferences is
under 'View', in a different component under 'File' and then again in
another component under 'Tasks'.
It would be great if within the menu it is always at the same 'slot' but
hardly a real necessity.
I don't feel that consistency should be translated into 'place holder
implementation', always making sure it is at exactly the same location.
The same menu? Yes of course. Same sequence of menu's on the menu bar?
Yes of course as much as possible.
I don't see how it would really bother anyone if it is called
'Navigator' in the Navigator component and 'Composer' in the Composer
component. The change in width won't be that much of a disturbance I
don't think and one does still know what kind of options on can find
under this menu.
>
> * | The bottomline is that I feel that we should no longer refer to it
> | as the File menu and I would favor a generic component/application
> | menu, which in the case of the browser component of Mozilla would
> | hence be the 'Navigator menu'. This menu should only contain options
> | that are directly related to global aspects of the application and
> | its behavior. In the case of Navigator what we find here is 'window
> | handling' and quitting the application.
>
> Actually, MacOS X apps have an Application menu, to the left of the
> File menu, which largely does what you describe. (The icon for the
> app, rather than the app name, is used as the menu title so that
> the jumping menus problem is not an issue.) The Application menu
> contains About, Preferences, Quit, and assorted other global items.
> But MacOS X apps still have a File menu, for items involving the
> filing of documents.
I do realize that my proposal for a component/application menu comes
'close' to the MacOS implementation of an Application menu. Pretty neat
huh… :-)
>
> * | With Aphrodite's menu Matthew Thomas had originally introduced a
> | different method of capitalizing the menu items. Unlike the common
> | practice of capitalizing every noun and verb, Matthew chose to
> | capitalize the 'important' words within a menu option.
>
> Yes, but I changed my mind. The reason I did so is not only because
> several people on n.p.m.ui didn't like it, but also that it doesn't
> really work. For example,
> ------
> Add bookmark
> Add bookmark As ...
> ------
> is quite logical under my original scheme, because `As' is the
> important word in the second item (differentiating it from the first
> item). But that doesn't stop it from looking exceedingly strange.
>
I know that you ran into some 'resistance as to your way of
capitalization and hence decided to go back to what we are all currently
used to.
Well 'Ami' is a stubborn little girl isn't she…. I would still like to
introduce this new scheme and see how it works. The question of
aesthetics is obviously a rather subjective one.
I make no distinction between 'important' and non-important' words. The
guideline is simple, just the first word and proper nouns.
It makes no sense to be to capitalize practically every word and I don't
see how this is easier to read..
I do recall at least one response in the newsgroup that actually did
like your capitization scheme (and not it was not me).
Once again thanks for your feedback. I read your posting on simplifying
Aphrodite some more… Good luck with that.
Sorry but I just find it too hard to resist… My response to your posting
is (obviously) ==> 'Ami' :-)
Greetings,
Peter
pete collins
> it but with little luck so far. This is how I discovered that indeed
> editing the XUL file is rather a sensitive issue and I managed to
> produce a 'dead lizard' several times (yes I did save the stuff first).
> The fact that it was not as easy as I thought (just yet) made me create
> my site in the first place. At least I know how to show what I mean
> through HTML :-)
Your site looks great dude . . .
To edit aphrodite menus do this:
in your favorite text editor open "aphrodite/content/default/include/menus.xul"
All of the menus are in this xul overlay file.
Now as an experiment just change the text where it says:
<menu value="File">
to say:
<menu value="FuBar">
save it and then launch aphrodite.
This is a good way to slowly familiarize yourself with xul.
It is not much different from saying: <button value="FuBar">
I would suggest editing one thing at a time so you can catch any mistakes you
might make initially.
The most common mistakes are forgetting a quote " or mismatching a tag.
But if you run aphrodite in console modemozilla will dump out any xul syntax
errors with the line number.
On windows you would do this:
mozilla.exe -console -chrome chrome://aphrodite/content/
Any menu changes you want to make to aphrodite should be passed over to Matthew
Thomas.
He is writing the menu spec i am following and he is open to all improvements.
Aphrodite is a joint effort so everyone who wants changes can do so as long as
the community agrees it is a good change.
Like i said we should vote on this stuff like the apache guys do.
I really would like to encourage people to hack away at this stuff. The more
developers hacking the better the chances of building something useful.
Post any questions you have to the ng so others can benefit.
pete
pete collins
> up and hence both 'Page source' and 'Page info' can now be found under
> the newly introduced 'Page' menu.
>
I have to admit, i haven't had a chance until now to really check out the
menu stuff you posted (no time).
I like it a lot.
Everything seems to be grouped in their proper logical places.
Also it breaks tradition (got to like that!).
I would like to see some of this incorporated into aphrodite.
Matthew comments??
It seems that the strength of AMI is in the logical categorizing of all of
the menitems.
This make a whole lot of sense. And is more intuitive.
pete
Klein Duijmpje
>
> > I did fool around a bit with Aphrodite's menu to see if I could manage
> > it but with little luck so far. This is how I discovered that indeed
> > editing the XUL file is rather a sensitive issue and I managed to
> > produce a 'dead lizard' several times (yes I did save the stuff first).
> > The fact that it was not as easy as I thought (just yet) made me create
> > my site in the first place. At least I know how to show what I mean
> > through HTML :-)
>
> Your site looks great dude . . .
Thanks :-)
>
> To edit aphrodite menus do this:
>
> in your favorite text editor open "aphrodite/content/default/include/menus.xul"
>
> All of the menus are in this xul overlay file.
>
> Now as an experiment just change the text where it says:
>
> <menu value="File">
>
> to say:
>
> <menu value="FuBar">
>
> save it and then launch aphrodite.
>
> This is a good way to slowly familiarize yourself with xul.
> It is not much different from saying: <button value="FuBar">
>
> I would suggest editing one thing at a time so you can catch any mistakes you
> might make initially.
>
Yes this is actually what I had been doing. I guess I just went from one
small step to suddenly too much at once.... I knew I had to be in this
file :-)
Just name changing was easy but removing whole options... oops :-)
> The most common mistakes are forgetting a quote " or mismatching a tag.
>
It 'looked' good to me even still matching tags. So I started to think
there was a link to some other file that also needed mending... and well
that part I haven't figured out yet.
> But if you run aphrodite in console modemozilla will dump out any xul syntax
> errors with the line number.
>
> On windows you would do this:
>
> mozilla.exe -console -chrome chrome://aphrodite/content/
>
Wow thanks. Now this I definitely need. I need to SEE what I am doing
wrong. Will give this a go thanks Pete.
> Any menu changes you want to make to aphrodite should be passed over to Matthew
> Thomas.
> He is writing the menu spec i am following and he is open to all improvements.
>
> Aphrodite is a joint effort so everyone who wants changes can do so as long as
> the community agrees it is a good change.
Well I do know that Matthew is Aphrodite's menu owner and you and he are
the ones responsible for what becomes of Aphrodite. Of course based on
community input don't get me wrong here.
I do like Aphrodite's UI and besides I'm the one that posted the screen
shots remember :-)
Matthew I believe does accept some 'competition' from 'Ami'. I do 'fear'
though that Ami is a tad bit too radical in its new grouping of menu
items to be adopted in any way in Aphrodite's menu. I may find it more
logical an intuitive but hey that is just me..
I think I would have to get Matthew drunk to adopt most stuff for
Aphrodite :-) And NZ is a bit far away.
Besides there would have to be enough community support for the whole
concept anyway and it seems to me efforts on Aphrodite have been around
a while (including the menu spec's) and as far as I can tell most folks
seem to like it or certainly don't place comments to such an extent that
radical changes are called upon (hence my own initiative for what I
would like it to be).
Ami just might lead a life of her own and who knows when I finally grasp
the secrets behind XUL and all that I can actually implement it within
the skin or package that I like. At the moment that is the Aphrodite
look I must admit.
So in future I see my brand of Mozilla with Aphrodite as the package yet
my personal reordering of the menu as proposed by Ami :-)
Klein Duijmpje
>
> > As I state on my site I felt that the 'View' menu needed some 'cleaning'
> > up and hence both 'Page source' and 'Page info' can now be found under
> > the newly introduced 'Page' menu.
> >
>
> I have to admit, i haven't had a chance until now to really check out the
> menu stuff you posted (no time).
>
> I like it a lot.
Whew :-)
>
> Everything seems to be grouped in their proper logical places.
>
> Also it breaks tradition (got to like that!).
Don't break with tradition for the sake of breaking it but also don't
let it get in the way, is should not be restrictive and I feel it is
starting to be. Causing bloated and somewhat illogical menus at least
from my perspective...
If I may, I'd like to once again quote the design principles as worded
by Matthew:
"Doing things exactly right means we actually ignore everything done so
far in the world
of user interfaces. We don't ignore the research results and basic
usability principles, but
we should not blindly follow the ways those principles have been
implemented in current
operating systems and applications."
Wonderfully put and indeed a leading principle for Ami.
>
> I would like to see some of this incorporated into aphrodite.
>
> Matthew comments??
>
> It seems that the strength of AMI is in the logical categorizing of all of
> the menitems.
> This make a whole lot of sense. And is more intuitive.
>
> pete
Peter
Matthew Thomas
>...
> I don't agree with you that Navigator's mainly deals with windows and
> File --> New window okay that I follow. And closing a window I can
> also grasp… But then what about Print --> Window? Saving ---> Window?
>...
Actually, no. When we save, we might not be saving a page; we might be
saving a frameset. Similarly when we print, we might not be printing a
page; we might be printing a frameset, or even a directory listing. But
whatever it is, you're saving (or printing) the contents of the window.
This window-as-document idea seems strange when you are first confronted
with it, but it's one of the logical results of hypertext. You go from
document to document so frequently in hypertext, that individual
documents become less important than the windows that contain them.
>...
> Of course I do and did realize that the term 'documents' must not be
> taken that literally and in the 'spirit' of computer applications one
> actually means 'whatever object the application deals with most'.
> My examples of 'Document', 'Image' and 'File' are I believe fitting in
> an OO-design concept. I had a look at IBM's CUA guidelines for OO
> interface design and there they have an example of an application for
> a car dealership and the first menu item is actually called 'Car'...
As useful as the guidelines from Apple, Microsoft, and IBM are, you
should never accept them blindly.
If the first menu in any application is called `Car', that sets off all
sorts of alarm bells in my head, because it's wanton inconsistency with
the use of `File' by the rest of the world.
>...
> I did consider for a moment that with 'File' one actually means the
> verb and not the noun. Though I am sure it all started out like this
> (I will assume this), I still have the impression that with what we
> find on the 'File' menu in certain applications seeing this as a verb
> is really stretching it a bit. Actually even as a noun it doesn't
> always make sense.
That's right, sometimes you often have to stretch the metaphor; but it
makes sense more often as a verb than it does as a noun, and it's in
keeping with the noun-verb grammar of GUIs.
> I have to agree with Sjoerd who states in his response:
>
> "As far as I know the verb File means something like 'Archive' or
> 'Save' even. I don't think new or open would be in the File menu if it
> means that."
To do some filing means to organize documents (whatever `documents'
means:-). Opening them, closing them, making a hard copy of them,
putting them away for safe-keeping. Whatever. So `Quit' doesn't really
belong in the File menu, but just about everything else that's currently
in it does.
>...
> As far as I know all applications translated into Dutch perceive it as
> a 'noun' and hence use the word 'Bestand' (literally file).. So surely
> illogical for non English users don't you think.
>...
Well, that's unfortunate. I guess either there isn't a good common verb
for `deal with documents' in Dutch, or some early influential Dutch
computer program had a misguided translator who unwittingly set a
standard for Dutch menus which is inconsistent with those for English ones.
>...
> I agree that the change in keyboard mnemonics is a bit of a bother.
> This is a bit unfortunate and one is bound to run into this problem if
> you wish to rearrange things through out the various menus. It is the
> price of change. Going back to the 'File menu' would only resolve that
> for those options. But not all can be found there anymore with Ami....
> So yes some re-learning.
No, not just some re-learning. The cost of change should be *just* the
cost of relearning, and *not* also permanent usability loss. And
permanent usability loss is exactly what having a different name for the
`File' menu on each app would introduce, because of the different
keyboard mnemonics in every app, and because the user would have to
constantly go to their memory to fetch the name of the File menu in the
app they happened to be working in at the time.
>...
> I wonder how much of a bother it really is if the menu items shift
> left or right a tad bit per component/application due to the width of
> the name op the application menu title. Is muscle memory really that
> sensitive? I doubt it...
Try using a Mac regularly for a few days, and *then* come back here and
try to say that. When the Edit and View menus are always in the same
place on the screen, as they are in MacOS, you are soon able to take
advantage of that fact -- you learn how to flick the mouse at high speed
(thanks to Fitt's Law) to the same spot every time to access the menu.
But if the Edit and View menus were in completely separate positions
between apps -- as they would be, under your scheme, if I was switching
between Word (with a short `Word' menu) and Navigator (with a long
`Navigator' menu) -- that whole benefit would be lost.
>...
> I do realize that my proposal for a component/application menu comes
> 'close' to the MacOS implementation of an Application menu. Pretty
> neat huh... :-)
Yes, and if you used the icon for the program rather than the program
name itself, like MacOS X does, then the issue of jumping menus would
not be so much of a problem. But you'd still be forcing the user to go
through an extra level of mental effort to remember which menu Print is
in for this particular app.
>...
> It makes no sense to be to capitalize practically every word and I
> don't see how this is easier to read..
>...
I think it's because menu items are very short. So capital letters speed
up your reading by helping to define where the start of words are --
just as in longer sections of text, capital letters help speed up your
reading by defining where the start of sentences are.
I'd be interested in seeing how your menu scheme applies to Messenger.
If you have a `Page' menu in Navigator, then presumably you'd need three
such menus in Messenger: a `Message' menu, a `Folder' menu, and an
`Account' menu. And that could get a bit complicated ...
Matthew Thomas
>...
> If I may, I'd like to once again quote the design principles as worded
> by Matthew:
>
> "Doing things exactly right means we actually ignore everything done
> so far in the world of user interfaces. We don't ignore the research
> results and basic usability principles, but we should not blindly
> follow the ways those principles have been implemented in current
> operating systems and applications."
When I wrote that, I was referring to doing major things. Like, perhaps,
using something *other* than menus to get at commands.
Ooooo. Spooky thinking about that, isn't it?
Coming with such an alternative is a long-term project; in the short
term, it is better to concentrate on using what users already know about
the usual order of menus and menu items.
And if anything radically new is offered, going back to the previous way
of doing things should be relatively painless. That's why the View `as
List' and `as Marquee' menu items in Aphrodite are right underneath the
previous way of doing things, i.e. `as Web Page'.
Actually, I'm toying with the addition of an extra item in that part of
Navigator's View menu right now:
as _Hyperspace Ctrl+Shift+4
;-)
> Wonderfully put and indeed a leading principle for Ami.
>...
Let's take a look at something else I wrote ...
<http://critique.net.nz/project/mozilla/general/principles/consistency/>
|
| Consistency
|
| Last modified: 2000-01-02
|
| Consistency is the single greatest tool for increasing usability of an
| interface, because it decreases the amount a user needs to learn in
| order to use the interface effectively.
|
| Designing for consistency in an application interface often results in
| what might be seen as a slightly-less-than-optimal design.
|...
For example, you might have to put up with a File menu when you're not
really dealing with files.
| But the usability benefit from the consistency almost always outweighs
| the slight usability loss from the sub-optimal design of the interface
| considered by itself.
Just as having a menu consistently called `File' reduces the strain on
the user's memory.
|...
| Consistency with other applications on the same platform
|
| Heavy users of any particular platform expect the user interfaces of
| most productivity applications to be as similar as possible to each
| other, so knowledge about one application can be translated to the
| others.
Actually, the users of IBM's car dealership interface probably wouldn't
be using that many other apps, so maybe they could get away with a `Car'
menu. But as soon as a majority of car salespeople got to the stage
where they had computers at home, `Car' would stop being a good idea
because it would be inconsistent with the apps the salespeople used the
rest of the time.
| An application can get away with being inconsistent with other
| applications on the same platform only where either or both of the
| following apply:
| * a relatively small proportion of time spent using the application
| is spent using the interface itself (example: a video or MP3
| player)
| * the application is the most powerful in its field, and usability
| problems caused by lack of consistency are outweighed by the
| greater usefulness of the application compared to others.
|
| Consistency is especially important for a new application, or one
| (such as Mozilla) where a large amount of the interface is new or
| changed. If a user has to learn too much in order to use a new
| application, and there are alternatives available with a lower
| learning cost, those alternatives will win out.
|
| An application interface which is not consistent with other
| applications on the same platform is like an employee who refuses to
| follow company rules. They're not likely to remain employed for long.
> > I would like to see some of this incorporated into aphrodite.
> >
> > Matthew comments??
Well Pete, it's completely up to you which menu spec you use. But
personally, I have no intention of making Aphrodite like a badly-behaved
employee. :-)
Mozilla is not an island, and it simply can not afford to do anything
which is unnecessarily inconsistent with the rest of the world.
> > It seems that the strength of AMI is in the logical categorizing of
> > all of the menitems.
> > This make a whole lot of sense. And is more intuitive.
But can Peter maintain that categorization in a consistent and workable
manner with his menu layouts for Navigator, Bookmarks, History,
Messenger, Address Book, Composer, Message Composition, and Chat?
And then can he produce proof-of-concept reorganizations of, say, the MS
Word menus and the Paint Shop Pro menus, to demonstrate why the world
should use the Ami menu layout instead of the standard
Apple/Microsoft/Corel/Netscape/Adobe/Aphrodite/Tom/Dick/Harry menu
layout -- so that the world can be spared the inconsistency of two
different layouts?
We wait with bated breath to find out. :-)
pete collins
> | interface, because it decreases the amount a user needs to learn in
> | order to use the interface effectively.
> |
> | Designing for consistency in an application interface often results in
> | what might be seen as a slightly-less-than-optimal design.
> |...
Right, but is remember *where* "File" is before i remember the *name*
"File*.
If i want to open up a doc, i go to the far left menu.
> > > Matthew comments??
>
> Well Pete, it's completely up to you which menu spec you use. But
> personally, I have no intention of making Aphrodite like a badly-behaved
> employee. :-)
Nope, nothing is up to me.(Thank god).
Like i said, it is up to the community. This way *I* can't be blamed for a
bad descision. ;-)
It would be good for you guys to put your heads together and see if perhaps
we can extend Matts current spec to incorporate some of AMI's good ideas.
This i think will result in a better menu scheme.
2 heads are better than one.
And remember Matt and i don't see eye to eye on a lot of issues. We have
banged heads many times in the past.
But look at us now we are working together trying to help create something
good and useful that is truly an open collaboration.
pete
Henri Sivonen
mp...@student.canterbury.ac.nz (Matthew Thomas) wrote:
> Well, that's unfortunate. I guess either there isn't a good common verb
> for `deal with documents' in Dutch, or some early influential Dutch
> computer program had a misguided translator who unwittingly set a
> standard for Dutch menus which is inconsistent with those for English
> ones.
The pattern is that "File" is translated as a noun. In some cases it is
translated to a noun meaning a place where documents are stores (eg. in
Finnish, Swedish and German versions of Mac OS). In other cases it is
translated to the noun that (also or only) means a computer file (eg.
French localizations and the Finnish localization of Windows).
Because English supports parse-time implicit type determination of
identifiers referring to both verbs and nouns, some guessing is involved
when out-of-sentence English words are translated to languages that
require strong typing.
BTW, "Edit" is clearly a verb. Yet, it is translated to a noun meaning
"editing" in Finnish and French localizations.
--
Henri Sivonen
hen...@clinet.fi
http://www.clinet.fi/~henris/
Matthew Thomas
>
> > | Consistency is the single greatest tool for increasing usability
> > | of an interface, because it decreases the amount a user needs to
> > | learn in order to use the interface effectively.
> > |
> > | Designing for consistency in an application interface often
> > | results in what might be seen as a slightly-less-than-optimal
> > | design.
> > |...
>
> Right, but is remember *where* "File" is before i remember the *name*
> "File*.
> If i want to open up a doc, i go to the far left menu.
And if you want to save a doc, you go to the far left menu. Oh, whoops,
Save isn't there any more. It's over the other side of the menu bar, in
the `Page' menu.
And if you want to print a doc, you go to the far left menu. Oh, whoops,
Print isn't there any more. It's over the other side of the menu bar, in
the `Page' menu.
And you make the same mistake, over and over and over again. And you
hardly ever get used to it, because every other application you use
works the other way.
And after a while, if you start using an Ami-tized browser for long
enough, it starts working the other way. Occasionally you go over to the
right side of the menu bar in Word, or Lotus 1-2-3, or Photoshop, or
whatever, expecting to find Print and Save there, before realizing your mistake.
And then you realize just how frustrating this all is, and you start
using Internet Explorer or Opera instead.
>...
> Nope, nothing is up to me.(Thank god).
> Like i said, it is up to the community. This way *I* can't be blamed
> for a bad descision. ;-)
Yeah, but like it or not, you're the maintainer of the Aphrodite code.
If you'd decided to put Print Now in Aphrodite's File menu, for
instance, I would have been powerless to stop you. Quite a few people in
this group wanted it; who says they weren't right? You do, because you
decided not to include it. I decided not to include it in my own spec,
but it was you who decided to use my spec /verbatim/.
In a few days I'll have a keyboard spec ready. (Half-finished version at
<http://critique.net.nz/project/mozilla/general/keys/>.) And some people
will like it, and some people won't. And I'll accept some suggestions
from people in n.p.m.ui for changes (like I changed from Ctrl+: to
Ctrl+; for opening the prefs window, following Henri Sivonen's good
points about i18n), but other suggestions I'll reject.
And then in a couple of weeks or so I'll have a toolbar spec ready,
which (gasp) looks quite different from the current Aphrodite one. And
I'm highly doubtful that n.p.m.ui will *ever* be able to come to an
agreement about that.
And eventually I'll have a status bar spec, and a Messenger spec, and an
Album spec, and an Address Book spec, and a Chat spec, and a Bookmarks
window spec, and (probably the hardest of the lot) a Composer spec, and
whatever else. But all of those will just be my opinions of what's a
good idea -- with some improvements accepted from those in n.p.m.ui, of
course, but with other `improvements' rejected.
And other people may come up with ideas which seem to be equally good,
but which are entirely incompatible with mine, and never the twain will
meet. So it will have to be you, Pete, who decides exactly what you
include in the code and what you don't.
> It would be good for you guys to put your heads together and see if
> perhaps we can extend Matts current spec to incorporate some of AMI's
> good ideas. This i think will result in a better menu scheme.
>...
When Peter finishes his spec for the other Mozilla components, so we can
see if the general layout works across components, then we'll be able to
tell whether there are any useful changes that can be made to the menu
layout of every Aphrodite component. I'll wait and see.
Klein Duijmpje
Eh.... let me take a wild guess here....
You just plain don't like it :-)
Ami is too radical, lacks consistency and hence overall is not workable.
Oh well :-)
"entirely incompatible with mine"
Yup like I said before I do feel deep down we actually do strive for the
same thing but well we go about it in quite a different manner.
Wanting to maintain consistency and yet also introduce change is not all
that easy; at least you can't always take it as far as you may wish.
It is clear that your parameters are different than mine. You work
within the parameters of consistency (common practice as found within
most applications) and I clearly show disregard for this and act like
the rebel that I am. :-)
If you are ever in the neighborhood I'll offer you a beer (okay more
than one) :-)
I think we just need to agree to disagree on this don't we? :-)
As I state on my site my ideas are most probably too much a reflection
of my own character rather than being suited for general usability.
>
> > It would be good for you guys to put your heads together and see if
> > perhaps we can extend Matts current spec to incorporate some of AMI's
> > good ideas. This i think will result in a better menu scheme.
> >...
>
> When Peter finishes his spec for the other Mozilla components, so we can
> see if the general layout works across components, then we'll be able to
> tell whether there are any useful changes that can be made to the menu
> layout of every Aphrodite component. I'll wait and see.
Don't hold your breath :-)
Klein Duijmpje
> | interface, because it decreases the amount a user needs to learn in
> | order to use the interface effectively.
> |
> | Designing for consistency in an application interface often results in
> | what might be seen as a slightly-less-than-optimal design.
> |...
>
> really dealing with files.
>
> | But the usability benefit from the consistency almost always outweighs
> | the slight usability loss from the sub-optimal design of the interface
> | considered by itself.
>
> Just as having a menu consistently called `File' reduces the strain on
> the user's memory.
>
> |...
> | Consistency with other applications on the same platform
> |
> | Heavy users of any particular platform expect the user interfaces of
> | most productivity applications to be as similar as possible to each
> | other, so knowledge about one application can be translated to the
> | others.
>
I apologize for 'abusing' your quote about the design principles of
Aphrodite (your menu spec's). I shouldn't have quoted them yet again and
taken them out of context or clearly only quoting a specific section and
not including the rest (your opinions on consistency that also serves as
a guideline).
> Actually, the users of IBM's car dealership interface probably wouldn't
> be using that many other apps, so maybe they could get away with a `Car'
> menu. But as soon as a majority of car salespeople got to the stage
> where they had computers at home, `Car' would stop being a good idea
> because it would be inconsistent with the apps the salespeople used the
> rest of the time.
>
> | An application can get away with being inconsistent with other
> | applications on the same platform only where either or both of the
> | following apply:
> | * a relatively small proportion of time spent using the application
> | is spent using the interface itself (example: a video or MP3
> | player)
> | * the application is the most powerful in its field, and usability
> | problems caused by lack of consistency are outweighed by the
> | greater usefulness of the application compared to others.
> |
> | Consistency is especially important for a new application, or one
> | (such as Mozilla) where a large amount of the interface is new or
> | changed. If a user has to learn too much in order to use a new
> | application, and there are alternatives available with a lower
> | learning cost, those alternatives will win out.
> |
> | An application interface which is not consistent with other
> | applications on the same platform is like an employee who refuses to
> | follow company rules. They're not likely to remain employed for long.
I've always been a 'rebel' but never got kicked out of a place :-)
>
> > > I would like to see some of this incorporated into aphrodite.
> > >
> > > Matthew comments??
>
> Well Pete, it's completely up to you which menu spec you use. But
> personally, I have no intention of making Aphrodite like a badly-behaved
> employee. :-)
>
> Mozilla is not an island, and it simply can not afford to do anything
> which is unnecessarily inconsistent with the rest of the world.
>
> > > It seems that the strength of AMI is in the logical categorizing of
> > > all of the menitems.
> > > This make a whole lot of sense. And is more intuitive.
>
> But can Peter maintain that categorization in a consistent and workable
> manner with his menu layouts for Navigator, Bookmarks, History,
> Messenger, Address Book, Composer, Message Composition, and Chat?
Yes can he? :-)
>
> And then can he produce proof-of-concept reorganizations of, say, the MS
> Word menus and the Paint Shop Pro menus, to demonstrate why the world
> should use the Ami menu layout instead of the standard
> Apple/Microsoft/Corel/Netscape/Adobe/Aphrodite/Tom/Dick/Harry menu
> layout -- so that the world can be spared the inconsistency of two
> different layouts?
Too bad it can't be different. I feel like the customer who wants to buy
a T-Ford in red but Mr. Ford tells me I can have any color I wish as
long as it is black :-)
If I ever do master this whole 'zool' stuff I just may be the only
individual using the Ami menu :-)
I do like to think though that there is room out there for 'cheeky'
applications.
>
> We wait with bated breath to find out. :-)
>
> --
> Matthew `mpt' Thomas, usability weenie
> http://critique.net.nz/
Peter
Matthew Thomas
>...
> Eh.... let me take a wild guess here....
>
> You just plain don't like it :-)
> Ami is too radical, lacks consistency and hence overall is not
> workable.
> Oh well :-)
No, actually I *do* like it, and I'll tell you why.
I don't mean to sound disparaging here ... Well, shoot, I guess some
would say I lost all hope of not sounding disparaging long ago. But ...
Your menu layout actually reminds me of what I was like about seven or
eight years ago.
At that stage I was, for reasons which I'm still not sure of (other than
some vague and highly misplaced idea of making millions of dollars from
computer software) trying to design the ultimate word processor. Yes,
some teenagers played the electric guitar, others hung out in cafes, but
I ... I designed GUIs for non-existent word processors. Sheesh.
Anyway, the menu bar for my fantabulous word processor looked like this.
# Item Part Set Use View Do
Pretty weird, huh? Not exactly consistent with any other app in the world.
The `#' menu (actually, it was a funky Greek character) was like the
Application menu in MacOS X. It dealt with Preferences, About, Quit, and
stuff like that. (This is all from memory, although I think I still have
the sheets of graph paper with my original designs on them around somewhere.)
The `Item' menu was for dealing with documents (or whatever items the
app dealt with). I saw the renaming of `File' as `Item' as a way of
avoiding the ambiguities of `File' -- just like you did when you renamed
`File' as `Page'. (Of course with a consistent `Item' name, you wouldn't
have the problems with the keyboard mnemonics and jumping menus.:-)
The `Part' menu was the equivalent of the usual `Edit' menu. I tried to
make it as consistent as possible with the `Item' menu, except that it
dealt with parts of items rather than with the whole item itself. So
where the `Item' menu had `Delete' for deleting the file, the `Part'
menu had `Delete' for deleting some the selected text. Where the Item
menu had `New' for creating a new file, the `Part' menu had `New
object ...' for creating an object in the document. Where the `Item'
menu had `Insert' for inserting one item (file) in another, the Part
menu had `Paste' for inserting the contents of the clipboard into the
text. And so on.
`Set' was pretty much the same as a normal word processor's `Format'
menu. `Use' was for tools such as spell-checker, word count, thesaurus,
auto-save, and so on, which would all come as plug-ins. `View' was just
as you'd find it in a traditional program. And the `Do' menu was for
Undo, Redo, and recording and playing macros (which I called `routines').
And I thought this new layout was just brilliantly logical and elegant
... until I actually imagined trying to use it. And I imagined it
sucking rather badly, for the sole reason that it was completely
inconsistent with other programs.
So by the time I gave up on the project, my design had ever-so-gradually
evolved to something like this ...
File Edit Set View Tools Help
... which is almost the same layout as you see in traditional applications.
>...
> Yup like I said before I do feel deep down we actually do strive for
> the same thing but well we go about it in quite a different manner.
> Wanting to maintain consistency and yet also introduce change is not
> all that easy; at least you can't always take it as far as you may
> wish. It is clear that your parameters are different than mine. You
> work within the parameters of consistency (common practice as found
> within most applications) and I clearly show disregard for this and
> act like the rebel that I am. :-)
So, I *do* think it is worth you carrying on your project, and seeing if
you can make your new layout apply to the other Mozilla components. If
it can, and if by itself (ignoring other apps for the moment) it is more
intuitive than the current layout, then maybe we can use it.
Because we can introduce one aspect of it in the first major release of
Aphrodite -- so that it's minorly inconsistent with other apps, but it's
so darn useful that users don't mind the inconsistency. And then we wait
a couple of years, and other apps will come out with the same little bit
of menu rearrangement because it's so useful. So we find ourselves
consistent with the rest of the world again.
And then we introduce the next new bit, and wait for that to filter
through the inertia of other apps' development cycles as the companies
realize what a good idea it is and implement it in their own software.
And so on -- slowly but surely, we change the standard menu layout for
GUI apps.
> If you are ever in the neighborhood I'll offer you a beer (okay more
> than one) :-)
And I'll politely decline, and ask for an orange juice instead. :-)
Cheers
--
Matthew `the Revolution will not have a Help menu' Thomas
http://critique.net.nz/
pete collins
> I ... I designed GUIs for non-existent word processors. Sheesh.
I played electric guitar. Still do actually.
pete