A bit of progress made with AMI
Klein Duijmpje
to a site that shows my own personal idea on a new and somewhat
different menu structure for our new browser than is currently being
offered by Mozilla and Aphrodite.
It is my little 'Alternative Menu Initiative' (AMI) which is current
just a conceptual idea 'on paper' so to speak. I've finally found the
time to continue with it a bit again.
I've decided to 'tone down' a bit and have removed the rather radical
'Page' menu that I had introduced for Navigator (for those who have seen
it).
The site now offers you my ideas on the menu's for Navigator and
Messenger.
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/
KD
Pete Collins
I wish you and Matthew could merge your brains and work together on this
stuff for some (comm)unity gain.
However, i have an idea . . .
How about i offer your menu as an alternative menu for Aphrodite.
Where the user can have a choice. Swap out their menubar.
It is creating more work for me but i will do it.
The whole purpose of Aphrodite is to get everyone involved and learning to
do this stuff.
What would be even better is if you implement AMI yourself.
I will gladly help out.
It is not that hard. Aphrodites menu is all contained in an overlay. So you
could copy that overlay call it "ami.xul" and start hacking it in.
Sound good??
SLAP? (Sound Like A Plan?)
pete
Matthew Thomas
>...
> Klein Duijmpje wrote:
>...
> > The site now offers you my ideas on the menu's for Navigator and
> > Messenger.
> >
> > 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/
Looks good ... and considerably less crazy than the previous version.
:-)
It's reminded me of three things:
* new ideas are always good;
* I really, *really*, need to get around to turning my spec from plain
text into HTML and CSS;
* the Aphrodite menus need to be Even Simpler than they are now.
The main thing I think you need to work on in AMI is the titles of the
submenus. For quite a few of your submenus, the submenu title gave me
little idea about what the submenu would contain.
This is important, since you have used submenus extensively in order to
simplify the main menus. In some cases this is a rough fit -- who would
have guessed, for example, that the menu item for wrapping long lines
would be in the same submenu as the menu item for viewing the source of
a message?
Another thing which stands out is that you seem to have a `Language
Support' submenu (hint: the user doesn't care that a program `supports'
something, the user just wants to *do* something!), and then a separate
`Character Set' menu item somewhere else. Bug, or feature?
<...
> I wish you and Matthew could merge your brains and work together on
> this stuff for some (comm)unity gain.
There's quite a few good ideas in AMI for me to pick off, at least.
>...
> How about i offer your menu as an alternative menu for Aphrodite.
> Where the user can have a choice. Swap out their menubar.
>
> It is creating more work for me but i will do it. The whole purpose of
> Aphrodite is to get everyone involved and learning to do this stuff.
>...
Wow Pete, do you not sleep or something? You're doing Aphrodite, the
Script Editor, you released the first version of Crash Recovery a day or
two ago ... and you're volunteering for even *more* work?
My own to-do list at the moment, for those interested:
* try to work around/help people to fix bug 36928 (so I can actually
/run/ this `Mozilla' thing that everyone keeps talking about)
* bug 20862
* finish spec for bug 2800
* Mozilla UI FAQ v0.2 (no, Waldo, I haven't forgotten)
* some long-overdue bug-fix verification and filing work (~76 bugs)
* file a steaming heap of drag-and-drop RFEs against Ben Goodger
* fix the `Mozilla bug' bookmarklet on Bugzilla's home page, which
hasn't been quite as useful as it could be for several months
* write spec for bug 34175 (if you have a degree in maths specializing
in calculus, please e-mail me, I need some funky maths done for that)
* update Tardis prefs dialog spec
* update/HTMLize Aphrodite menu spec (see, that's how low priority it
is, isn't it shameful)
* toolbar specs for Aphrodite Navigator
* design an interface to Bugzilla which could be implemented in XUL/JS
-- is anyone interested in implementing such a beast?
* redesign the Web interface to Bugzilla (keeping as sensibly consistent
as possible with the XUL interface design), fixing a crapload of
Bugzilla-component bugs in the process
* first attempt at design for Aphrodite's Find dialog (aka `Moriarty')
* context menu specs for Aphrodite Navigator
* first attempt (un-anti-aliased) at colorful toolbar icons for
Aphrodite Navigator
* first draft of end-user help for Aphrodite
And that should keep me busy for a couple of months, at least ...
--
Matthew `mpt' Thomas, Mozilla user interface QA
<http://critique.net.nz/project/mozilla/>
pete collins
Sure id do, I'm actually not spending as much time hacking as i would like
to . . .
> You're doing Aphrodite,
Future tense, haven't started hacking on it yet . . . ;-(
> the Script Editor,
Haven't touched in in months . . ;-(
> you released the first version of Crash Recovery a day or
> two ago ...
This i am pleased about. :-)
> and you're volunteering for even *more* work?
Actually if you read deeper, i was trying to volunteer Klein. ;-)
Like i said it would be much more productive if you guys worked together on
the menus.
> * design an interface to Bugzilla which could be implemented in XUL/JS
> -- is anyone interested in implementing such a beast?
*cough* Sounds like a noble idea to me . . . Maybe one day i can help out
on this. It is an important project IMO.
pete
Dean Tessman
> > two ago ...
>
> This i am pleased about. :-)
Geez, the things you miss when you go on holidays for a couple of days.
Off to alphanumerica.com I go...
dean
Klein Duijmpje
>
> Hey man, glad to see you back working on this again.
Well me too :-) I'm hoping to be able to spend some more time on AMI
again and finally get the menu spec's of all components worked out and
'posted' on my little site.
> I wish you and Matthew could merge your brains and work together on this
> stuff for some (comm)unity gain.
Well I'm a 'late comer' to the newsgroup and kinda looked at what was
going on with Aphrodite from the 'side line' so to speak. Matthew has
put far more effort and most certainly FAR more thought into everything
than I have. Also, if I'm not mistaken, Matthew's spec's have come about
through community debate and support.
What I've been doing with AMI is just based on my own (possibly wacky)
intuition.
I was and am glad to see a simplification of the menu but well from my
perspective it just ain't simple enough yet and hence not the way I'd
like to see it.
As stated on my site, my whole purpose is just to show how I would do it
if it were all up to me and hereby possibly triggering off some new and
different ideas than we have seen thus far.
>
> However, i have an idea . . .
>
> How about i offer your menu as an alternative menu for Aphrodite.
> Where the user can have a choice. Swap out their menubar.
>
I certainly would not complain :-) It does sound good.... However...
> It is creating more work for me but i will do it.
> The whole purpose of Aphrodite is to get everyone involved and learning to
> do this stuff.
>
Right I am sure you are WAY too busy yourself. I doubt that I have any
right to put a claim on your time:
A) I am sure you have lots to do on behalf of Alfanumerica.
B) You have plenty you already wish and need to do with Aphrodite.
C) There is (at the moment) no community support for AMI.
So all in all I would think there is currently insufficient
justification for using your time and hacking skills for AMI. Mind you
I'm very appreciative of your offer.
> What would be even better is if you implement AMI yourself.
> I will gladly help out.
>
> It is not that hard. Aphrodites menu is all contained in an overlay. So you
> could copy that overlay call it "ami.xul" and start hacking it in.
Yes you are undoubtedly right that it would be far better if I did do it
myself.... But alas I don't have the skills as yet (not an experienced
developer like I believe most are in this newsgroup).
I should give it a go I guess, but will do so after I've completed the
spec's and have put them all on the site. My few quick attempts at
hacking the XUL file were not all that successful. I came to the
conclusion that I have to try each little change out directly and backup
the last version that DID work cause one little mistake causes the
Lizard to crash upon launch... A tad bit frustrating...
Of course just taking the time to try and understand it all first might
help also :-)
>
> Sound good??
>
> SLAP? (Sound Like A Plan?)
>
Yup it is a plan. Hope to get around to it.
KD
Klein Duijmpje
>
> Looks good ... and considerably less crazy than the previous version.
> :-)
Perhaps indeed it was a tad bit 'over the top'. I tried to pay a bit
more attention to the constructive criticism that you had given me and
working on Messenger indeed made me want to achieve more consistency
between the two components (Navigator and Messenger).
>
> It's reminded me of three things:
> * new ideas are always good;
> * I really, *really*, need to get around to turning my spec from plain
> text into HTML and CSS;
> * the Aphrodite menus need to be Even Simpler than they are now.
Personally I'm happiest with point 'three' :-)
When I'm (finally!) done with AMI's spec's (it is alas slow going) I
would be willing to create a copy of the AMI site for Aphrodite's menu
and thus displaying Aphrodite's menu structure in a similar way...
Of course you are more than welcome to use any (HTML) coding that I have
to achieve the same result if you so wish. But it is not CSS and not
'perfect' coding as at the moment I just use a plain text editor and am
more interested in the lot being rendered than complying to perfect code
(yup short term goal).
>
> The main thing I think you need to work on in AMI is the titles of the
> submenus. For quite a few of your submenus, the submenu title gave me
> little idea about what the submenu would contain.
I will try and have a look at the submenu titles again.
>
> This is important, since you have used submenus extensively in order to
> simplify the main menus. In some cases this is a rough fit -- who would
> have guessed, for example, that the menu item for wrapping long lines
> would be in the same submenu as the menu item for viewing the source of
> a message?
Well perhaps... then again all the options as to how you actually view
the message are in the same submenu. And let's face it viewing the
source of the message is a way of viewing it is it not? :-)
> Another thing which stands out is that you seem to have a `Language
> Support' submenu (hint: the user doesn't care that a program `supports'
> something, the user just wants to *do* something!), and then a separate
> `Character Set' menu item somewhere else. Bug, or feature?
Yes well MS uses the term 'Encoding', Netscape uses 'Character Set' and
Mozilla uses the term 'Character Coding'. When I was working on this I
wondered how many 'average users' actually have any idea at all what is
meant by this.
"Character Coding?!?!?" Is what I imagined their reaction would be. Are
they really interested in the coding or do they wish to have a language
displayed properly?
Hence I came up with 'Language support'.
As to 'Character Set' under the 'Tasks' --> 'Preferences' menu well this
is not a bug. In the Mozilla 'Character Coding' submenu you find an
option 'Customize'. This option gives the user a separate dialog window
in which character sets can be selected and 'reordered'.
Within AMI all the options that are intended to set preferences of one
sort or another and 'customization' options are grouped together under
the 'Tasks' --> 'Preferences' menu.
I admit I have not been consistent by calling the one 'Language support'
and the other 'Character set'. Within the preference menu I should also
have been more clear in the description by perhaps using the words
'Customize character set...'.
I will make these changes and adopt the term 'Character set' as you have
within Aphrodite.
>
> <...
> > I wish you and Matthew could merge your brains and work together on
> > this stuff for some (comm)unity gain.
>
> There's quite a few good ideas in AMI for me to pick off, at least.
Can't wait to see the new spec's :-)
KD
Matthew Thomas
>
> Matthew Thomas wrote:
> >
>...
> Perhaps indeed it was a tad bit 'over the top'. I tried to pay a bit
> more attention to the constructive criticism that you had given me and
> working on Messenger indeed made me want to achieve more consistency
> between the two components (Navigator and Messenger).
I think you'll find that as you do menus for Composer, Bookmarks,
History etc that the menus start looking even more, shall we say,
`traditional' in order to be consistent with each other.
>...
> > This is important, since you have used submenus extensively in order
> > to simplify the main menus. In some cases this is a rough fit -- who
> > would have guessed, for example, that the menu item for wrapping
> > long lines would be in the same submenu as the menu item for viewing
> > the source of a message?
>
> Well perhaps... then again all the options as to how you actually view
> the message are in the same submenu. And let's face it viewing the
> source of the message is a way of viewing it is it not? :-)
`Source' and `Info' are the `odd ones out' in the `Display message'
submenu because they open new windows, whereas the other items in the
submenu just adjust the display of the message in the existing window.
And as far as most users are concerned, I don't think showing the source
of a page or message is really a serious way of `displaying' the
page/message.
> > Another thing which stands out is that you seem to have a `Language
> > Support' submenu (hint: the user doesn't care that a program
> > `supports' something, the user just wants to *do* something!), and
> > then a separate `Character Set' menu item somewhere else. Bug, or
> > feature?
>
> Yes well MS uses the term 'Encoding', Netscape uses 'Character Set'
> and Mozilla uses the term 'Character Coding'. When I was working on
> this I wondered how many 'average users' actually have any idea at all
> what is meant by this. "Character Coding?!?!?" Is what I imagined
> their reaction would be. Are they really interested in the coding or
> do they wish to have a language displayed properly? Hence I came up
> with 'Language support'.
I have a part-time job in an Internet cafe. Many of the customers are
from Asian countries, so they use Internet Explorer's `View' >
`Encoding' submenu quite often.
I don't think you could give this menu item any name which would save me
from having to explain to each of these customers, the first time, why
the Japanese/Chinese/Korean pages initially look like gibberish (or
conversely, having to explain to the next English-using customer on that
computer why the English pages have the occasional erroneous Japanese
glyph in them). It doesn't even occur to them to look in the menus at all.
But once it's explained, the first time, that they need to choose the
relevant alphabet from the `View' > `Encoding' menu, they can do it by
themselves quite happily in future.
So the reason I don't like `Language support' isn't because it's not
obvious enough ...
> As to 'Character Set' under the 'Tasks' --> 'Preferences' menu well
> this is not a bug. In the Mozilla 'Character Coding' submenu you find
> an option 'Customize'. This option gives the user a separate dialog
> window in which character sets can be selected and 'reordered'.
> Within AMI all the options that are intended to set preferences of one
> sort or another and 'customization' options are grouped together under
> the 'Tasks' --> 'Preferences' menu.
>...
... it's because a manual encoding enforced for the current page could
legitimately be considered a `preference' too, and `Character set' is a
more obvious wording for a menu item to change the character set for the
current page than `Language support' is. So I might easily choose the
wrong menu item by mistake.
I don't like Seamonkey's approach to this either -- giving the user the
ability to manually edit the `Character Coding' submenu is completely
unnecessary. Instead, the submenu should just contain the few most
recently used encodings, as they are almost always the encodings most
likely to be used in the future.
Based on my experience in the cafe, in the next revision of the
Aphrodite menus I plan on turning `Character Set ...' (which was
intended to always open a dialog) into a `Text Encoding' submenu, which contains
* the four most recently used encodings
* a separator
* an `Other ...' item for selecting an encoding which is not one of the
four most recently used (of course, using it automatically makes it
one of the four most recently used encodings, so it ends up going into
the submenu).
Klein Duijmpje
>
> Klein Duijmpje wrote:
> >
> > Matthew Thomas wrote:
> > >
> >...
> > Perhaps indeed it was a tad bit 'over the top'. I tried to pay a bit
> > more attention to the constructive criticism that you had given me and
> > working on Messenger indeed made me want to achieve more consistency
> > between the two components (Navigator and Messenger).
>
> I think you'll find that as you do menus for Composer, Bookmarks,
> History etc that the menus start looking even more, shall we say,
> `traditional' in order to be consistent with each other.
Yup quite possible...
>
> >...
> > > This is important, since you have used submenus extensively in order
> > > to simplify the main menus. In some cases this is a rough fit -- who
> > > would have guessed, for example, that the menu item for wrapping
> > > long lines would be in the same submenu as the menu item for viewing
> > > the source of a message?
> >
> > Well perhaps... then again all the options as to how you actually view
> > the message are in the same submenu. And let's face it viewing the
> > source of the message is a way of viewing it is it not? :-)
>
> `Source' and `Info' are the `odd ones out' in the `Display message'
> submenu because they open new windows, whereas the other items in the
> submenu just adjust the display of the message in the existing window.
True enough. They are in this sense indeed 'the odd ones out'. This
different behavior however IMHO does not justify having to create a
separate submenu just for these two options. The user DOES know what is
going to happen does he/she not? Not like he/she is going to get a major
shock "Oh my golly' a window just opened for this...." :-)
>
> And as far as most users are concerned, I don't think showing the source
> of a page or message is really a serious way of `displaying' the
> page/message.
Nope perhaps not 'a serious way of displaying' yet I still believe it is
a way a displaying. I agree that most likely very few would use these
options but still can't see that this thus means they need to be put
elsewhere.
I agree that there probably is no way of giving this option a clear
enough name that will not need extra clarification. I must add that I
used the term 'Language Support' because I had also included the option
'Translate' within this submenu. So basically all the 'language related'
options.
But anyway based on your feedback I will return to the term 'Character
Set' and will include 'Translate' as a separate option under the 'View'
menu [back to 'tradition' I guess :-)].
>
> > As to 'Character Set' under the 'Tasks' --> 'Preferences' menu well
> > this is not a bug. In the Mozilla 'Character Coding' submenu you find
> > an option 'Customize'. This option gives the user a separate dialog
> > window in which character sets can be selected and 'reordered'.
> > Within AMI all the options that are intended to set preferences of one
> > sort or another and 'customization' options are grouped together under
> > the 'Tasks' --> 'Preferences' menu.
> >...
>
> ... it's because a manual encoding enforced for the current page could
> legitimately be considered a `preference' too, and `Character set' is a
> more obvious wording for a menu item to change the character set for the
> current page than `Language support' is. So I might easily choose the
> wrong menu item by mistake.
Agreed. Though where do you draw the line between something being a
'preference' and not being a 'preference'?
Showing toolbars or not is in this sense also a preference for instance
is it not?
Under 'Tasks' --> 'Preferences' I will now call it 'Customize Character
Sets'.
>
> I don't like Seamonkey's approach to this either -- giving the user the
> ability to manually edit the `Character Coding' submenu is completely
> unnecessary. Instead, the submenu should just contain the few most
> recently used encodings, as they are almost always the encodings most
> likely to be used in the future.
>
> Based on my experience in the cafe, in the next revision of the
> Aphrodite menus I plan on turning `Character Set ...' (which was
> intended to always open a dialog) into a `Text Encoding' submenu, which contains
> * the four most recently used encodings
> * a separator
> * an `Other ...' item for selecting an encoding which is not one of the
> four most recently used (of course, using it automatically makes it
> one of the four most recently used encodings, so it ends up going into
> the submenu).
Sounds good to me. 'Text Encoding' is a nice compromise and the way you
are planning it now it looks to me that for this aspect of the menu MS
did a pretty good job with IE :-)
KB