89825 - Edit and View menus should match spec

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Gervase Markham [:gerv]]

mpt has put together a spec for the Edit and View menus; this involves
abolishing the Search and Go menus. I will attach it momentarily.

This bug is to track progress on getting Mozilla's menus to match that spec.

Please don't bother marking any dependencies yet.

Gerv

Comment 1

[Gervase Markham [:gerv]]

Attachment: mpt's spec - version 1

Comment 2

[Gervase Markham [:gerv]]

Taking.

Comment 3

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Comment 4

[Gervase Markham [:gerv]]

OK. This patch is very unlikely to be totally ready yet, but I need help and
comments to get it that way. It would be good to make this happen as quickly as
possible; I'll be pretty responsive this coming week, but not the two weeks
after that - and then I'm in Mountain View ;-) 

Patch status is as follows:

Made no attempt to fix bug 77704 (Find.)
Preferences key binding visible but not working - this is an XBL thing
I decided to remove Apply Theme and "Languages and Web Content".
Use Formatting is not yet present on the Messenger Edit menu - we'll put it in
when we have something to fill it with.
Messenger message change keybindings are still the old ones, because I have
heard no reason to change them yet :-)
Bonus feature: Use Stylesheet is now disabled if there are no author style
sheets

There are severfal things which don't yet conform to the spec; they are due to
be fixed when we turn the Tasks menu into the Tools and Window menus:
Form autofill items still on Navigator Edit menu
Message Filters still on Messenger Edit menu
Translate is still on the Navigator View menu

Search The Web has disappeared completely. As it's just a hard-coded bookmark to
a Netscape search site, I think we can live with this for the moment. It may
come back when the Tools menu appears.

If someone needs a package to install over a nightly which will show the new
changes, I can try and do that.

Gerv

Comment 5

[Håkan Waara]

You need buyoff from jglick before changing the mail/news menus. Jglick?

Comment 6

[timeless]

why isn't it Find _Next?

Comment 7

[timeless]

why isn't it _Delete?
Se_lect >
_Search Messages ...

  Show/_Hide              >
  _Headers                >
good job you created a new conflict.

Messenger needs source view in the menu. This is important for various reasons.

Navigator
---------
/ _Navigation Toolbar
/ _Personal Toolbar
/ _Status Bar
-----------------------
  Side_bar

why not:
/ _Edit Mode Tabs

cmanske should probably sign off for the editor changes.  I await spec v0.2

Comment 8

[Charles Manske]

We aren't supporting the HTML Source view in mail Composer for 6.1.
Seems like a lot of changes at the last minute! I'll look over Composer stuff
more carefully soon.

Comment 9

[Gervase Markham [:gerv]]

I don't know what "the last minute" is for you, but mozilla.org are still in the 
process of defining what Mozilla 1.0 means, let alone having a plan to work 
towards it, and so it won't be all that soon. :-)

Gerv

Comment 10

[scottputterman]

For the most part I think the mail menus are fine as they are in the current
build and don't need to be changed. 

Comment 11

[Matthew T (active 1999-2002)]

Attachment: Example of problems with mail menus in current build: Go menu

Comment 12

[Matthew T (active 1999-2002)]

Attachment: Example of problems with mail menus in current build: View menu

Comment 13

[scottputterman]

The build I'm using right now is about a week old from the 0.9.2 branch, but the
two separators (where you ask if there's any excuse for this sort of thing) have
Text Size in between them.

Comment 14

[Gervase Markham [:gerv]]

The reason for that is that Text Size is broken on the Mac, and has been for 
ages.

Gerv

Comment 15

[jag (Peter Annema)]

I thought I had added an observes element (or attribute) to the second separator
to show/hide it, based on whether the menu item was shown/hidden, specifically
to address this...

In file mailWindowOverlay.xul:

956       <menuseparator><observes element="menu_textZoom"
attribute="hidden"/></menuseparator>

Yep, it's still there. I wonder if this doesn't work on Mac. Let me look into
this.

Comment 16

[Blake Ross]

I would prefer to see the Apply Theme submenu remain for now on the trunk. We 
are working to resurrect dynamic switching.

Comment 17

[jag (Peter Annema)]

Re: double separators:

bug 10893. Fixed, and verified fixed.

This must have regressed at some point. Any ideas when?

Comment 18

[german]

FYI - I do not want to see the changes in the Netscape product at this point in 
time. They have been created without any formative usability testing. 
They are also locally optimized and they do not take into account the overall 
menu framwork as designed for Netscape 6. Furthermore they do not take into 
account the need for Netscape to meaningfully integrated client technologies 
with net based services.
The Netscape client menu framework will receive a design overhaul after the 
mojo client release ships. For Netscape, they will not be based on one person 
thinking designing that around his or her own needs but changes of that 
magnitude must be designed with the proper understanding and testing with users 
and customers.

Comment 19

[Gervase Markham [:gerv]]

Latest patch coming up; fixes a couple of accesskey problems that timeless
spotted. I already had one big bunch of merge conflicts, and this patch is only
48 hours old. :-( Note that Composer menu changes are negligible.

> FYI - I do not want to see the changes in the Netscape product at this point 
> in time. They have been created without any formative usability testing. 

It would be lovely if Netscape agreed to usability test them for mozilla.org :-)
That's the only way any menu changes are going to get usability testing, after
all.

> They are also locally optimized 

I don't understand, I'm afraid. What does that mean?

> Furthermore they do not take into 
> account the need for Netscape to meaningfully integrated client technologies 
> with net based services.

I'm sure you understand that Mozilla's menu framework cannot and should not take
such things into account. :-)

Gerv

Comment 20

[Gervase Markham [:gerv]]

Attachment: Patch v.2 - accesskey fixes, Apply Theme returns at blake's request

Comment 21

[Gervase Markham [:gerv]]

Attachment: Patch v.3 - as above; ROT13 got caught up in the last one. Apologies.

Comment 22

[jglick]

As far as Mail menus, I think there are some good ideas here.  I don't agree 
with all of them though, like eliminating the "Go" menu (this menu is supposed 
to have other items in it which aren't yet implemented).  I also think there 
should be separate bugs for each component and for each menu. Doing it all in 
one bug is too overwhelming and will take forever for everyone to agree on every 
item.  There are also already existing bugs on some of the suggestions.

Also, a lot of work has gone into the existing Mail/News menu spec (QA writing 
the bugs, engineers implementing to the spec and ui keeping it up to date), 
http://www.mozilla.org/mailnews/specs/threepane/MailMenus.html, and I don't want 
to see that get ignored.  

I agree "View: Sidebar" should be moved into the "Show/Hide" flyout. That is Bug 
79639. I also agree that "View: Message" should be moved into the "Show/Hide" 
flyout. I think it should also be renamed to "Message Pane" for better clarity. 
Some good suggestions in the reordering of items as well. "Select All" moving 
into "Select" flyout is good.

And I think we need to be careful about removing menu items before they have a 
definite new home in a different menu.

It would be good if we can take the pluses of the existing spec and mpt's spec 
and agree on the best solution. 

Comment 23

[Blake Ross]

Okay, as far as I can tell (and no one has proven otherwise), none of the specs 
that the Netscape UE team have designed for 6.x have been based off of usability 
studies.  So that's not a reason to reject others' changes.

If you could point me to the results of such studies (I'm now inside the 
firewall, the excuses are gone), I would be ecstatic...

Comment 24

[jglick]

Attachment: Jen's proposal for Mail View Menu

Comment 25

[scottputterman]

I agree with Jennifer's comments in her view menu proposal except that I think
it makes sense to have "Sort" before "Messages".  I think changing the sort
order is a more common occurrence than changing the view.  In the view menu
screen shot, there's a comment about people changing the view before changing
the sort.  My belief is that most people won't change the view whereas many
people will change the sort which means I believe more people will change the
sort first.  I don't think this is that big of a deal either way which is why I
think it's fine to keep it as is since I don't think there is a compelling
reason to change it. 

Comment 26

[timeless]

I'd like to be able to hide the thread pane, otherwise i agree w/ 
putterman/jglick

Comment 27

[jag (Peter Annema)]

Design-wise, I'll let y'all work things out, I won't give my r= for that.

Code-wise, I have a number of comments on the last patch:

In navigatorOverlay.xul:

+        <menuitem id="menu_find" label="&findOnCmd.label;" 
+              accesskey="&findOnCmd.accesskey;" key="key_find"
command="Browser:Find"/>

I think the style is to line the second line up with the first attribute on the
first. In this case, make acceskey line up with id.

+    <menu id="menu_View" accesskey="&viewMenu.accesskey;"
label="&viewMenu.label;" 
+          oncreate="enableStyleSheetMenu(window._content.document.styleSheets,
+                document.getElementById('menu_styleSheet'))">

Here document should line up with window.

Repeat these line-up comments couple of times ;-)

I'll just assume all you did was move stuff around, not actually change
functionality.

In navigator.js:

+  for (i = 0; i < styleSheets.length; ++i) {

That should have a |var| in it. Turn on js strict warnings ;-)
In that if block you could actually add a break and short-circuit that for loop
once you've found what you're looking for.

In mailWindowOverlay.js:


 function InitEditMessagesMenu()
 {
   document.commandDispatcher.updateCommands('create-menu-edit');
-}
-
-function InitSearchMessagesMenu()
-{
   document.commandDispatcher.updateCommands('create-menu-search');
 }

So if search actually is removed, you should merge the code that gets executed
for create-menu-search with create-menu-edit at the back-end level. Maybe a
seperate bug should be filed on it once this is checked in.

+  var folders_menuitem=document.getElementById('menu_showFolders');

+      if(folders_menuitem_hidden != "true"){

Space style issues.


In walletNavigatorOverlay.xul:

-    // Can't use generic goToggleToolbar (see utilityOverlay.js) for form menu
because
+    // Cant use generic goToggleToolbar (see utilityOverlay.js) for form menu
because

It was correct before you "fixed" it :-)

In editorOverlay.xul:

Adding this line looks wrong to me:

+    <key id="cmd_preferences"/>

That should either be key_preferences, or <command/>, or perhaps both. Though if
it worked (I assume you tested all this), I now wonder if the line is needed at
all...

Generic comments:

Shouldn't accel+; (also) be in the mac platform HTML bindings?

Fix these things and attach a new patch please. I'm talking to mpt at the
moment, so some more comments may be coming up.

Comment 28

[Matthew T (active 1999-2002)]

Gerv, the remaining thing Jag mentioned was to revert `Source' back to `Message
Source'. Jennifer was right, that is clearer, for an e-mail app where the idea
of source code isn't as familiar is it is on the Web.

Comment 29

[Gervase Markham [:gerv]]

jglick said:
> I think "Messages/Sort by/Headers" group of items belongs closest to the 
> "Show/Hide" item since they are similar.  

I think that it's good to keep menus having the same structure across the app
suite unless there's a good reason not to; the current layout matches Navigator
and Composer.

> I think "Text Size" is more descriptive to users than "Text Zoom".

Zoom makes more sense for something which is a percentage, by analogy with
graphics apps. Text sizes sound to me like things you set in points or pixels in
Preferences, and are permanent.

>  I don't think the "Go" menu should be combined with the View menu. As I 
> mentioned in the bug, this menu is supposed to have other items in it that are
> not yet implemented.

Are these Mozilla things? It would help if you could let us know what they are.

New patch coming; this addresses many of jglick's comments. Jag's comments have
been addressed. I should have mentioned earlier; one of the things in this patch
which isn't quite ready is the Preferences keybinding. I've had several goes at
getting this working and can't figure it out. Can someone either point me at
some docs or tell me what I'm doing wrong? Jag?

Gerv

Comment 30

[Gervase Markham [:gerv]]

Attachment: Patch v.4 - addresses raised concerns

Comment 31

[jglick]

Attachment: Jen's comments on the Edit menu suggestions

Comment 32

[Håkan Waara]

FYI: just posted a patch to change "Search Mail/News Messages" to "Search 
messages... Ctrl+Shift+F" in bug 88525.

Comment 33

[timeless]

Text Zoom rings really badly.  Text Size is ok, 'Zoom' alone will probably be 
ok once we get support for it.

Comment 34

[Gervase Markham [:gerv]]

> ("File menu is too large").

Cleaning up the File menu and the Tasks menu are next on the list. Fear not :-) 
Things which are destined for the Tasks menu are staying where they are in this 
phase. See the patch - or I could attach a screenshot if you like.

"Accounts" is only to appear in the Mail menus, because it is a feature relevant 
only to Mail. So we don't need to worry about the short name. "Edit | 
Accounts..." seems grammatically sensible.

I agree about renaming Delete (and possibly about renaming Properties) based on 
context, but those are separate RFEs if they don't work at the moment. I'm 
trying not to expand the scope of this patch any more. ;-)

Gerv

Comment 35

[jag (Peter Annema)]

Gerv, would you mind fixing your indentation style so something like:

<element attr1="val1" ...
 attr3="val3" .../>

becomes

<element attr1="val1" ...
         attr3="val3" .../>

?

It would make reviewing your patch much easier for me, and will make the file
more maintainable.

Comment 36

[scottputterman]

Would anyone object to there being a separate (maybe more than one) mail bug? 
The mail changes aren't really related to the browser changes and I'd like to
have a bug where we could just have discussion of those and get more mail folks
involved.

Comment 37

[Matthew T (active 1999-2002)]

Putterman, the main point of this patch is to make Mozilla's menu structure 
more consistent -- not just improving consistency with other applications on 
the user's system, but (even more importantly) improving consistency between 
the various apps in Mozilla itself. Splitting it up into several bugs would 
serve only to ensure continued inconsistency between Navigator and Messenger 
for the forseeable future, since it would massively increase the amount of time 
taken to fix all the problems (the time required to diff, review, super-review, 
and commit several patches instead of one).

A lot of work has gone into this change -- the design phase has taken more than 
a year, and Gerv has spent long hours on the implementation. As it is, this 
patch fixes a large number of reported bugs. It would be shame to see it 
rejected in a pincer-like fashion, between German complaining that it is too 
localized and you complaining that it is not localized enough. :-)

Jennifer, most of the concerns you have are errors on my part with
context-sensitivity of wordings (e.g. Delete/Cancel/Unsubscribe) and keyboard 
shortcuts in the spec; Jag and I have established, however, that Gerv has not 
repeated any of these errors in his patch, so all is well. I'll attach an 
updated spec shortly which incorporates your feedback.

As for your questions about movement of menu items, this bug was deliberately 
confined to improving cross-app consistency of the `Edit' and `View' menus, 
because (a) they're worst at the moment, and (b) changes can be made to them 
without disturbing other menus *too* much (`Properties', `Edit Draft', and 
`Search the Web ...' being the main exceptions). Fixing the `File' and `Tools' 
menus, as Gerv said, will be dealt with in later bugs; and given Gerv's current 
excellent performance, I'm confident that those bugs will be fixed months 
before Netscape needs to make its next branch from the Mozilla trunk.

Comment 38

[scottputterman]

The patch for the mailnews menus won't be allowed in without jglick's and
sspitzer's approval.

I don't know if you will believe me on this, but I hope that the fact that
Jennifer and I have been participating to varying degrees in this bug shows that
we are not viewing this as a Netscape vs Mozilla type argument. For us this is
solely about the mail app. We are not trying to prevent changes from going in
and we aren't trying to prevent improvements from going in if we agree with
them. The current mail menus are 3+ years in the making and have been worked on
by a number of people.  I'm not ready to see them change so radically without
some more discussion.  I believe it would be better to have a mail specific bug
so that it would be easier to discuss browser and editor changes in this bug. 
We don't have to, but as I said above, jglick and sspitzer have to buy off on
this, regardless.

Comment 39

[Matthew T (active 1999-2002)]

Attachment: Updated version of http://mozilla.org/mailnews/specs/threepane/MailMenus.html incorporating Jennifer's suggestions

Comment 40

[Gervase Markham [:gerv]]

> I don't know if you will believe me on this, but I hope that the fact that
> Jennifer and I have been participating to varying degrees in this bug shows 
> that we are not viewing this as a Netscape vs Mozilla type argument. 

Why would we have thought you were? And if you did view it as a Netscape vs.
Mozilla argument, who would have been participating instead of you? Or do you
mean no-one from Netscape would have participated at all?

Anyway, in the Mozilla tree, there are no Netscape vs. Mozilla arguments. There
are Mozilla vs. Mozilla arguments. ;-)

> For us this is
> solely about the mail app. 

Could it not be that this is part of the issue? Do you believe that, as an
application suite, Mozilla's menus should be consistent between applications? If
so, then it can't be solely about the mail app.

> and we aren't trying to prevent improvements from going in if we agree with
> them. 

Er... it would be a very perverse person who did try to prevent improvements
going in if they agreed with them.

> The current mail menus are 3+ years in the making and have been worked on
> by a number of people.

Again, have you considered that this could be a problem rather than a good
thing? Having a number of different people working on something at different
points often means that the original vision and consistency is lost. 

There is no way everyone is going to agree on every change. In this situation,
people have two options. They can dig their feet in and say "It'll be exactly
how I think it should be", in which case no changes will be made and our menus
will not improve. Or, people can recognise that others have different views, and
some issues are not worth holding things up over, and that the final patch may
contain things which are not quite as they would have liked.

We (basically, I) have a very long row to hoe, here. Once Edit and View have
been improved, then we have to do the Tasks/Tools/Window menu split, and then
clean up the File menus. No doubt other things that need doing will be found
along the way. All of this needs to be done as quickly as possible, to minimise
inconvenience to a) me, as the person dealing with the patches and merge
conflicts and b) Mozilla distributors who, I am sure, would like the menus to
stabilise. 

I would just ask everyone contributing to this bug to ask themselves, before
they do anything that will raise a barrier to getting these improvements checked
in, to ask themselves whether it is really worth adding that obstacle, and to
consider whether any objections they make have are really major enough to hold
the whole process up.

When it comes down to it, the best way to see if new menu ideas are improvements
or not is to implement them and get feedback from the testing community. Our
menus are not set in stone now, and they will not be after this patch. If things
don't work, we'll fix them.

Gerv

Comment 41

[Matthew T (active 1999-2002)]

Attachment: Further update to http://mozilla.org/mailnews/specs/threepane/MailMenus.html (fixes a couple of accesskey clashes)

Comment 42

[Gervase Markham [:gerv]]

Attachment: Hopefully, the final patch

Comment 43

[timeless]

> it would be a very perverse person who did try to prevent
> improvements going in if they agreed with them.
Perhaps, but that doesn't mean it hasn't been done or isn't correct behavior on 
occasion.

definitely not the final patch
+    <key id="key_find" key="&findOnCmd.commandkey;" 
+         command="Browser:Find" modifiers="accel"/>
use keycode iirc.

label="&findOnCmd.label;" 
ok. findOnCmd.* predates you, but I think we should get rid of On, can anyone 
justify retaining it?

note that other places use:
+      <menuitem label="&findCmd.label;" key="key_find" 
+       accesskey="&findCmd.accesskey;" observes="cmd_find"/>

blake would probably ask for a ; in the
+          oncreate="enableStyleSheetMenu(window._content.document.styleSheets,
+          document.getElementById('menu_styleSheet'))">

I'll ask for a different whitespace convetion since the one you used is really 
wide
+          oncreate="enableStyleSheetMenu(
+                      window._content.document.styleSheets,
+                      document.getElementById('menu_styleSheet')
+                    )">

+              accesskey="&useStyleSheetMenu.accesskey;" disabled="false">
why bother with false?
 
Personally I don't see the need for people to stick their name all over code 
since I believe that CVSBlame/CVSLog better serve that purpose.
+        <!-- These are to move out later - Gerv -->
Please rewrite this, include an understandable comment and a bug# ref.

I'm still 100% against moving the go menu.  Since i'm not @nscp I guess that 
makes this a mozilla conflict.  So i propose the following compromise.   
Move the go menus into overlays (one for browser, one for mail, ...).  Using an 
overlay the go menu placement is a single xul line and can be easily changed.   
 For now please leave it as a top level menu.

This compromise allows vendors, distributors and developer end users to easily 
make their own determination.

Since there are ZERO comments about locale switching here, I consider your 
removal of the locale switching code a merge conflict -- please change your 
patch to not remove that.

Severity
  This field describes the impact of a bug. 

Blocker         Blocks development and/or testing work 
Critical        crashes, loss of data, severe memory leak 
Major           major loss of function 
Minor           minor loss of function, or other problem
                where easy workaround is present 
Trivial         cosmetic problem like misspelled words or
                misaligned text 
Enhancement     Request for enhancement 

The severity doesn't match the above table => clobber.  I've decided not to 
select trivial which seems to accurately describe this bug, so Enhancement it 
is.

According to my understanding of the UID component it is supposed to handle 
spec design and not implementation work. Given that there are still serious 
concerns about this as a specification I would like to request that we limit 
this bug to spec work.

mpt: your mail spec html document is corrupted, I expect to see a collection of 
tables holding menus, but this is not the case for Edit and View.

The other thing you managed to do was totally change the layout which means it 
will be extremely hard for me to get any useful information from cvsblame or 
cvsdiff.

I suggest that you take one of the following two approaches:
a. rewrite the current spec to match your new layout and attach that to be 
checked in as an interim cvs revision followed by some corrected version of 
your current proposed spec (after approval and fights etc).
b. backport your current proposed spec into the current layout and attach that 
to be checked in as an interim cvs revision followed by some corrected version 
of your current proposed spec (after approval and fights etc).

ok. so that leaves no live attachment proposals.

Comment 44

[Matthew T (active 1999-2002)]

Timeless, try using a standards-compliant browser. I hear Mozilla is quite good
these days. Opera and iCab similarly have no trouble with the spec, and even 4.x
does a passable job of it. `Fix the HTML errors in the parts of the mail/news
menu spec which mpt didn't touch' should be filed as a separate bug, it has
nothing to do with this one.

All the Navigator UI changes have already been approved by Ben Goodger. All
that's holding this up now is review, and approval from jglick and sspitzer.

Comment 45

[Gervase Markham [:gerv]]

Attachment: Patch v.6

Comment 46

[Gervase Markham [:gerv]]

This is the latest version of the patch. I have to go away for a few days (until
Sunday) but I hope that this is in an r=-able state, and perhaps progress can be
made on sr=ing it as well.

Gerv

Comment 47

[jglick]

Comments on mpt's attachment id=42293 (my name should come off this doc since 
only the items this bug does Not deal with are my work):

Edit Menu

If "Filters..." is eventually moved to a Tools menu, will the Tools that appear 
be specific to Mail only, or global across all apps?  If global across apps, 
"Message Filters..." is probably better.

"Properties" should remain in the Edit menu until the File menu is reworked.

Getting rid of the Search menu in Mail and moving all the items into the Edit 
menu.  German Bauer was part of the original decision to move these items to a 
separate Search menu, so I think his input before that is changed is 
appropriate.

I don't think "Search Previous" is necessary since there is already a 'search 
backwards' checkbox on the Find dialog. 


View Menu

Scott Putterman and I both feel the "Go" menu should remain separate not be 
merged into the View menu.

I think the Sort by/Messages/Headers group (in that order) of flyout menus 
belongs directly under Show/Hide flyout for Mail since these items are strongly 
related. 

I understand Text 'Zoom' is more accurate to the engineering of it, but I think 
Text 'Size' will make more sense to most users.

Encoding vs Character Coding. I think this decision needs to be agreed upon by 
someone from International.

User Formatting: I don't understand the future purpose of this menu item well 
enough to comment.

Comment 48

[Gervase Markham [:gerv]]

> will the Tools that appear be specific to Mail only

Yes :-)

> "Properties" should remain in the Edit menu until the File menu is reworked.

Any particular reason? It is unavoidable that the menus will be in a state of flux
during this process; that's what development means. 

> I don't think "Search Previous" is necessary 

That's another bug; I haven't implemented this option.

> Scott Putterman and I both feel the "Go" menu should remain 
> separate not be merged into the View menu.

The reason you have given for this view is that there are more menu items to
come. It would be helpful to know what these are (and, if they are the sort of 
thing I suspect, why they aren't better off as Bookmarks ot Tools.) I would say 
the burden of proof here is on you to say why Go should not be grouped with 
Stop and Reload, and why these functions are important enough to need a 
top-level menu.

> I think the Sort by/Messages/Headers group (in that order) 
> of flyout menus belongs directly under Show/Hide flyout 
> for Mail since these items are strongly related. 

I think it's very important for the menus in Mozilla to be as consistent as possible between apps in the suite. The current proposal achieves this. Is the relation 
between Show/Hide and Sort by etc. so strong that this is worth breaking?

> I understand Text 'Zoom' is more accurate to the engineering 
> of it, but I think Text 'Size' will make more sense to most users.

Zoom was not chosen for engineering reasons, but by analogy with graphics 
apps etc. which also provide an option to temporarily change your view of your document in this way (specifying a percentage). Text Size sounds to me like 
something permanent you set as a pref, whereas Text Zoom sounds like 
something temporary that doesn't  affect the underlying document in a 
fundamental way.

Gerv

Comment 49

[Gervase Markham [:gerv]]

( **** Pocket IE. Grr. Try this. )

> will the Tools that appear be specific to Mail only

Yes :-)

> "Properties" should remain in the Edit menu until the File menu is reworked.

Any particular reason? It is unavoidable that the menus will be in a state of flux during this process; that's what development means. 

> I don't think "Search Previous" is necessary 

That's another bug; I haven't implemented this option.

> Scott Putterman and I both feel the "Go" menu should remain 
> separate not be merged into the View menu.

The reason you have given for this view is that there are more menu items to come. It would be helpful to know what these are (and, if they are the sort of thing I suspect, why they aren't better off as Bookmarks ot Tools.) I would say the burden of proof here is on you to say why Go should not be grouped with Stop and Reload, and why these functions are important enough to need a top-level menu.

> I think the Sort by/Messages/Headers group (in that order) 
> of flyout menus belongs directly under Show/Hide flyout 
> for Mail since these items are strongly related. 

I think it's very important for the menus in Mozilla to be as consistent as possible between apps in the suite. The current proposal achieves this. Is the relation between Show/Hide and Sort by etc. so strong that this is worth breaking?

> I understand Text 'Zoom' is more accurate to the engineering 
> of it, but I think Text 'Size' will make more sense to most users.

Zoom was not chosen for engineering reasons, but by analogy with graphics apps etc. which also provide an option to temporarily change your view of your document in this way. Text Size sounds to me like something permanent you set as a pref, whereas Text Zoom sounds like something temporary that doesn't affect the underlying document in a fundamental way.

Gerv

Comment 50

[scottputterman]

I don't have much time to add discussion right now, but there was one comment in
Gervase's last comment that I strongly disagree with.

The burden of proof for getting these changes checked in lies with those trying
to get these changes in.  The go menu has been where it's been for the last 3
years and even longer if you consider that this is based on Netscape products
from before Mozilla's existence.  I've read a couple thousand feedback responses
to Netscape 6.0 and 6.1 and don't recall any saying that they wish the Go menu
was moved.  I'm not trying to argue that just because it's always been this way
it shouldn't change.  I'm just saying that you need to convince the mail UI
design (jglick) and technical (sspitzer) owners, as well as other mail news
participants such as myself, that these change are necessary.  As far as I can
see this hasn't happened yet.  Anyway, this is just an argument about what it
will take to get this in.  I will try to add comments later that actually
address the issues you raised.  If I can't, maybe Jennifer can continue adding
comments.

Comment 51

[(not reading, please use [e-mail] instead)]

jumping in here, I'd like to repeat what I've said before in several other bugs:

the mozilla mailnews module owners (mscott, sspitzer, bienvenu) stand behind
jglick's UI decisions.

she's the owner of the mailnews UI specs.  and we're (the mozilla mailnews
contributors) are working hard to implement her specs.

http://www.mozilla.org/mailnews/specs/

based on reading her comments on 2001-07-17 15:11, she still has issues with the
design.

her issues need to be addressed before anything lands.

as co-module owner and super reviewer for mailnews, I want to review / approval
the changes to mozilla/mailnews.

Comment 52

[Gervase Markham [:gerv]]

I completely agree with sspitzer, and quite understand that he and jglick will
need to sign off on any changes. I apologise if my message implied otherwise;
I have never thought different. 

The point I was trying to make is that it's rather frustrating to see what I see as
an obvious UI improvement (grouping of related functions, removal of 
unnecessary top level menu) rejected without any reason specified. 

Gerv

Comment 53

[Matthew T (active 1999-2002)]

Naturally, no-one is going to admit to you `I think your program should have
fewer menus', because if they're the sort of person daunted by superfluous
menus, they won't be using your app long enough to feel able to comment.

I've been trying to find any other GUI e-mail program (other than past
incarnations of Mozilla) which has a `Go' menu or equivalent. No luck so far.
Eudora Lite doesn't. Pegasus Mail (judging by screenshots) doesn't seem to.
Neither does Lotus Notes. This is hardly surprising, since those who can use the
keyboard will use the keyboard shortcuts (Space, N, B, etc), and those who can't
use the keyboard will use the mouse (or the `Next' button) to select the
relevant message. The only reason the `Go' menu exists at all is to advertise
the keyboard shortcuts -- something which obviously doesn't need a top-level
menu reserved for it. The only e-mail app where I can find navigational menu
items is Outlook Express, which has `Previous' and `Next'. And where does it
have these items? Why, in the `View' menu, of course. :-)

As for `Text Size', the problem with that wording is that some people (judging
by bug reports and n.p.m.* postings) are expecting it to be persistent across
sessions, because they are used to MSIE where this is the case (since MSIE
doesn't have font size prefs). As the person who chose the `Text Size' wording
in the first place, I think I'm entitled to admit I was wrong. `Text Zoom'
reduces the confusion by emphasizing that it is a temporary magnification, while
at the same time paving the way for when graphics are zoomed as well and it
becomes just `Zoom'.

Jennifer, the rest of your concerns have largely already been covered in this bug.
*   What `Filters ...' ends up being called once in the `Tools' menu is outside
    the scope of this bug, since this patch does not touch that menu (see Gerv's
    2001-07-08 comment).
*   Moving `Properties' to the `File' menu is a one-item change, and Gerv has
    already given his commitment that he will clean up the rest of the `File'
    menu before distributors need to make their next branches from the trunk. I,
    for one, believe him.
*   A top-level menu (`Search') containing only three items, two of which
    (`Find' and `Find Again') a majority of users would expect to find in
    another menu (`Edit'), and the other of which (`Search the Web') is a
    hard-coded bookmark, clearly does not belong in any app which aspires to
    professional quality.
*   `Find Previous' is outside the scope of this bug, since it has its own bug
    and is not included in this patch (see Gerv's 2001-07-08 comment).
*   The lock-step consistency introduced between the `View' menus of Navigator
    and mail/news, brought about by moving the mail-specific `Sort by'/
    `Messages'/`Headers' items further down the menu, would surely outweigh any
    relationship which might be perceived between those items and `Show/Hide'
    (see my 2001-07-13 comment).

Comment 54

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 55

[jglick]

I think you guys have done a great job and I agree with most of the changes you 
are proposing.  The few remaining issues that Scott and I have mentioned in this 
bug are based on what we honestly feel is in the best interest of the Mail 
client.  Is it possible to just agree to disagree on these issues?  

To reiterate:

Please leave the Sort by/Messages/Headers (in that order) group below Show/Hide. 
You argue that in the View menu the Sort by/Messages/Headers group should not be 
below the Show/Hide item but above the Message Source item for consistency with 
the Navigator and Composer apps.   Scott and I feel that this group of items 
belongs directly below Show/Hide for several reasons. One, it is directly 
related to the layout of the window like the items in the Show/Hide menu are.  
Two, in the Mail application, we feel that these items are used more often that 
Stop/Reload/Load Images.  Three, the Navigator and Composer apps don't have this 
group of items so Anywhere this group is inserted for Mail breaks up the 
consistency with the Nav and Composer apps. We'd prefer to have it inserted 
below Show/Hide where we feel it makes more sense, than above Message Source, 
which also breaks up the consistency with Nav and Composer.

Please leave the Go Menu.  If you take a look at 4.x, you'll see some of the 
additional menu items that may be added to the Go menu. I don't think we should 
remove a whole menu item unless we are sure it is the right decision.

As for Text Size vs Text Zoom, I agree it might be a problem that some people 
are expecting it to be persistent across sessions,  but I don't think the term 
Zoom makes that fact any more clear than Size.   Instead, if people are 
expecting the setting to be persistent, why not make it persistent?  In 
addition, people who use graphics programs may understand Zoom, but I think 
you'll make things clear for a larger audience if you stick with Text Size for 
now.

Encoding vs Character Coding. I'm fine with this change, but as I have mentioned 
before, an OK from someone in International is probably good.

Again, you guys have some good changes here, and I hope we can come to an 
agreement.

Comment 56

[Kathleen :Brade]

to jump into the conversation briefly on one issue:  Initially I thought "zoom" 
made more sense to novice users, however, I have been thinking about this.  Now I 
think we use the term "zoom" when we actually refer to zooming the entire content 
of the window (not just the text--are we ever going to do this?).  Zooming just 
the text strikes me as very odd; that's not what graphics packages do so it seems 
strange that we'd use the same terminology.  Given we are only affecting the text 
size, we should probably stick with "Text Size."

cc Kat Momoi re: character encoding vs coding menu since long ago he had 
specifications on related changes.

Comment 57

[Gervase Markham [:gerv]]

> One, it is directly 
> related to the layout of the window like the items in the Show/Hide menu are.

Well, all the items in that menu are related to the way you View things. I don't 
think the link is that strong, personally.
 
> Two, in the Mail application, we feel that these items are used more often 
> that Stop/Reload/Load Images.  

That's certainly true.

> Three, the Navigator and Composer apps don't have this 
> group of items so Anywhere this group is inserted for Mail breaks up the 
> consistency with the Nav and Composer apps. 

This doesn't follow; there are six common items across the three platforms, and 
mpt's spec has them as the six topmost items. Therefore, consistency is 
maintained. If you move Stop etc. down, and the other three up, it's not.

(I don't care about this issue enough for it to stop this patch getting checked 
in, but mpt may have other views.)

> Please leave the Go Menu.  If you take a look at 4.x, you'll see some of the 
> additional menu items that may be added to the Go menu. I don't think we 
> should remove a whole menu item unless we are sure it is the right decision.

Looking at the Go menu in my 4.x, I can't see any menu items we don't have 
already. Could you say which ones you are referring to? 

How do we get to the state of becoming sure it's the right decision?  

> Instead, if people are 
> expecting the setting to be persistent, why not make it persistent?  

Because then it would be a different feature, poorly duplicating the function of 
the size part of the fonts preferences panel, and confusing people when the two 
settings interacted.

> you'll make things clear for a larger audience if you stick with Text Size for 
> now.

I'm happy to concede this one, if you insist. :-)

Gerv

Comment 58

[Matthew T (active 1999-2002)]

Attachment: Comparison of browser and mail/news `View' menus

Comment 59

[Charles Manske]

Just to stick in my 2 cents:
From considerations of UI design as well as my own usage patterns, I agree with 
jglick's reasons for placing the  "Message, Sort by, Headers" group second. 
They are much more important and used much more often than "Go to, Stop, 
Reload..."  group and most other items. I think this wins over any cross-module 
consistency argument. In a menu this long, I think well-designed groups of items
and the location of individual items within each group is what the user 
remembers, not the exact location of individual items from the top of the menu.

Comment 60

[jglick]

Attachment: Jen's counter comparison :-)

Comment 61

[Gervase Markham [:gerv]]

Jennifer - that's a fair point, and I'm happy to concede this one in the name of 
peace ;-). However, we still need to talk about the Go menu, I'm afraid. Both 
mpt and I really think this is important.

It cannot be denied that this menu sucks on Navigator, and is not worthy of a 
top-level menu position. It would also be hard to deny that, given that, where 
we are moving it to on Navigator is the right place to put it. 

When we come to Mail/News, we then have to ask: is the need for the Go menu to 
be a top-level menu so great as to introduce a cross-app UI inconsistency for 
these sorts of functions? I think this would really confuse the user. mpt 
asserts, and I agree, that this menu exists to advertise the hotkeys - no-one is 
going to select Go | Next Message every time they want to read a new message; 
they'll either use the hotkey, the toolbar button or the mouse, all of which are 
easier. 

Do you have any figures from your usability tests as to how used the Go menu 
actually is?

You said we shouldn't move it until we are sure it's the right thing to do. As I 
understand it, you (if sspitzer is delegating to you and doesn't have a personal 
view) are the only person with whom the buck stops who remains to be convinced. 
;-)

Gerv

Comment 62

[Matthew T (active 1999-2002)]

Yes! Let's have a half-inch empty space at the top of Navigator's `View' menu, 
as shown in Jennifer's mockup. That would look really kewl ... Alternatively, 
we could put the menu bar at the bottom of the window, rather than the top, so 
that the menus open upwards instead of downwards and we achieve the consistency 
shown in that mockup. (Might require a bit of extra work on Mac OS, though.)

But seriously, I'm finding it very difficult to imagine how people could change 
their headers/messages/sort with the menu noticably more often than they 
change, say, their text zoom level. I receive HTML mail in Verdana 6pt (or 
something heinously small like that), where I wish I could change the text size 
(bug 39117), about once every couple of weeks. For multilingual/Oriental users, 
changing the encoding is probably even more frequent than that. But `Headers' 
display is something you should only have to set once in the lifetime of your 
prefs.js file, with temporary forays into full headers once in a blue moon if 
you want to investigate the source of a spam or something. (I suspect half your 
problem is that bug 47422 hasn't been fixed yet -- with the result that you 
have to switch header mode when you want a workaround for bug 84237, or if you 
are on a small screen and you want a decent amount of screen real estate.) 
Similarly, `Messages' is something you're only likely to use if you're a heavy 
Usenet user, or if you receive gargantuan amounts of e-mail. Of the three 
functions, `Sort by' is probably the most common -- but sorting will usually be 
done by clicking the column header, not by using the submenu. Like the `Go' 
submenu, the `Sort by' submenu exists mainly for accessibility reasons. So what 
am I missing here?

Comment 63

[timeless]

I change my messages view very frequently while reading through my huge bugmail 
folder. Perhaps a view>refresh would do what i'm actually doing, probably not 
since it doesn't in nc4.

The next thing i do is view headers. then sorts then view source.  I do not 
change my font size frequently.  I shouldn't need to.  [Always use my fonts, 
pick a sane default]

As for the go menu i'm still opposed to moving it for Navigator.

Comment 64

[(not reading, please use [e-mail] instead)]

in addition to jglick's approval on any mail changes, we'll need to wait for ben
googder and german (the module owners and spec owner for navigator front end)
approval.

they're a bit overloaded, so there might be a delay.  thanks for being patient.

Comment 65

[Viswanath Ramachandran]

adding Ben here as Navigator UI module owner. 

Comment 66

[german]

Among other things I do not agree with removing the Go menu from the top level.
As  usability lab tests show it is still used by a large number of (admittedly
not tenured) users in Navigator to do basic back navigation. In fact I want it
more robust by including various levels of history such as Go > Back, Go Back To
>... as has been spec'd out, and I want it to remain at the top level.
It is argusable that the same benefit cannot be had for Mail, but for the sake
of consistency across apps I prefer that it should stay there.

Comment 67

[german]

I also do not agree with removing the Search menu as was stated in mpt's
concept. The search menu serves as a central clearing house to finding and will
do so even more in the future. It's meant to integrate all find/search activites
into one place as was requested by Netscape customers since 4.x. Being a menu
menu consistently used across apps it helps less tenured users discover search
functionality and helps us integrate local and web based searches. For the
Longer term UI we want integrate search across protocols and components to help
users find information relevant to their current context. The Search menu is a
stepping stone to doing that.
I do like the simplifications to the view menu, although I am hesitant to give
my nod to removing the show/hide My Sidebar from the top level. While I agree
that from a logical/code perspective it falls into the other show/hides in the
menu, I would also say that showing/hiding the sidebar is more important and
needs more discoverability then the other items under that submenu, maninly
because of the new-ness of My Sidebar and mainly because of the proportion of
real estate it takes up. 
But the most important key point is usability testing with real customers. These
are very fundamental changes to the product, and can't just make it in there
because somebody thinks they look cool. Usability testing of the product in such
depth however won't be conducted until after .9.4, therefore I ask that we hold
off on these changes, even the ones where we agree that they might be an imrovement.

Comment 68

[Viswanath Ramachandran]

Adding Steve Morse as Wallet module owner. Also - you are changing Character
Coding to Encoding. I think that the wording change there requires some thought
and consultation with people who work on Mozilla Internationalization as well as
people who work on Mozilla documentation. Can you please have that discussion
with Frank Tang and Jatin Billimoria. 

Comment 69

[Stephen P. Morse]

Having just been made aware of this bug, let me jump in here with a few 
comments.

1. The discussion is very long and it's extrememly difficult to figure out what 
the latest thinking on this is.  A screen shot of the proposals seems necessary 
here.

2. Removing the form-manager functions from the edit menu was mentioned in some 
places but I'm not sure if it's in the patches.  If it is, then that would 
remove the only remaining means of discoverability for the wallet feature (we 
already lost the wallet toolbar).  So the only way I would approve this as 
wallet module owner is if wallet itself were removed from the product.

3. The menu item that really needs cleaning up badly is the three-level task 
menu for performing privacy functions 
(tasks->privacy->cookies-manager->view-stored cookies).  Yet nowhere in this 
proposal do I see that being cleaned up.

Comment 70

[jag (Peter Annema)]

German said:
"But the most important key point is usability testing with real customers.
These are very fundamental changes to the product, and can't just make it in
there because somebody thinks they look cool."

I strongly doubt these changes are made solely on the basis of "looking cool",
and I also strongly doubt Gervase and Matthew have making it "look cool" as
their main motive for these changes.

Morse said:
"3. The menu item that really needs cleaning up badly is the three-level task
menu for performing privacy functions (tasks -> privacy -> cookies-manager ->
view-stored cookies).  Yet nowhere in this proposal do I see that being cleaned
up."

I think that is because this bug focusses on Edit, View, Go and Search. The
issues you mentioned should be dealt with (if they aren't already) in another
bug.

Comment 71

[matt]

mpt said:
*   A top-level menu (`Search') containing only three items, two of which
    (`Find' and `Find Again') a majority of users would expect to find in
    another menu (`Edit'), and the other of which (`Search the Web') is a
    hard-coded bookmark, clearly does not belong in any app which aspires to
    professional quality.


The search menu was originally designed to enhance the mosted used function on 
the web.  That menu is significaly used.   Rather then take it out why don't we 
improve it.   Netscape finds it adds value to the user experience and I don't 
see what makes you think that mozilla can't do the same.

Comment 72

[Ben Goodger (use ben at mozilla dot org for email)]

There are only three items in the search menu in Mozilla - Find and Find Again 
(both of which should be under "Edit") and "Search the Web"

This is not enough to warrant this menu's inclusion in /Mozilla/. It should be 
placed in the Netscape commercial tree and be included using overlays. Search 
may be the most frequently performed task, but the content present in this menu 
does not aid that as far as Mozilla is concerned. 

Rather than inventing new features to justify an unfair compromise for the sake 
of Netscape, why not let's clean it up in cooperation with Netscape and 
solidify Mozilla's UI? 

Comment 73

[Matthew T (active 1999-2002)]

[e-mail], I wholeheartedly agree that Search is one of the most common
activities in a Web browser, and it is unfortunate that Mozilla's current search
UI is too complicated and inconvenient to be worth using (in comparison to, say,
bookmarks on the Personal Toolbar for the user's two or three favorite search
engines). To be sure, the `Search' menu is just part of the problem, but this
bug *is* concentrating solely on the menu structure. I would be delighted to
work with you on making Mozilla's search function easier to use.

[e-mail], thankyou for your offer to do usability testing on these
changes. Feedback comparing 0.9.3 (with the menus as they are currently) and
0.9.4 (with Gerv's patch checked in), both from stopwatch usability testing and
from comments by Mozilla testers, would be very useful. If the changes are
delayed, of course, such feedback will not be possible. So, let's get this
checked in and see how well it works.

Comment 74

[Gervase Markham [:gerv]]

It is sad that german feels the need to belittle our professionalism, 
commitment and contribution to this project.

I personally volunteer to revert any of these changes which are shown to be 
usability regressions by any usability testing data that any entity contributes 
to the Mozilla project. In the absence of such data, there is nothing to say 
that one person's design is any better than another's.

We all know these menus are not ideal, in one way or another, now. There's no 
reason why they should be ideal after this change, or why they can't change 
further or change back in some areas. This is the first section of a 
three-pronged change - Tasks/Window and File are next up. When all three are 
done, I think the overall effect will be very good.

mpt is right. Let's make these changes and get feedback.

Final UI decisions in this product have to be made by a small number of people 
(obviously after taking advice), because there is no way that mpt, ben, matt, 
jag, morse, vishy, german, seth, timeless, jglick, charlie, brade, blake, gerv 
and everyone else commenting in this bug are going to agree on anything. :-)

As I understand it, for _Mozilla_, the buck stops with:
Navigator menus: Ben Goodger and Blake Ross
Mail/News menus: sspitzer, who delegates to jglick
Composer menus: (We are making no changes, to a first approximation)

Is this correct?

Gerv

(Morse: The Tasks menu is next on my list, and the Wallet will have much better 
UI there. But I can't get to it until this menu is finished with.)

Comment 75

[matt]

mpt says:
Mozilla's current search
UI is too complicated and inconvenient to be worth using (in comparison to, say,
bookmarks on the Personal Toolbar for the user's two or three favorite search
engines). 

When reading these comments I notice that you are addressing usibility of the 
menu's in the overall product.   By removing the search menu you impact the over 
design of search. You haven't addressed that at all other then say the above 
comments.  Now that we have the functionality of search in the product the next 
step was to address the places that search is as you say "to complicated and 
inconvenient."  Where are you getting your data from that says the search menu 
is the problem?  Our data suggests otherwise.  Before we rip part's of search 
out I would suggest that we get data that points to this being the right thing 
to do. So far all I have seen is peoples opinions including my own.  Also how 
are you going to collect the data other then newsgroup feedback which we all 
know is biased to advanced users.

Comment 76

[Ben Goodger (use ben at mozilla dot org for email)]

Gerv: I would suggest leaving Wallet's UI in place until you can fix the Task 
Menu UI. When you do that, you can do what you need to do in the Edit menu. 
That way Wallet is continuously available, and we suffer no 'down-time.'

Comment 77

[Matthew T (active 1999-2002)]

> Where are you getting your data from that says the search menu is the problem?

Firstly, this statement from Marlon Bishop:
|
| apparently users relied heavily on a simple button, as the [Netscape 6.0
| usability] report implied the relatively complex search facility in 6.0 did
| not perform as well.

Secondly, this statement from Ben Goodger:
|
| Netscape.com has informed CPD that the search layout of 6.0 and Seamonkey is
| less beneficial to them, and they would like improvements made.

And thirdly, the obvious fact that the menu contains only three items, only one
of which belongs there. (To be fair, the hard-coded nature of that item is a
separate bug, which will hopefully be fixed as part of the Tasks menu cleanup.)

If Netscape would like to contribute to making the search function easier to
use, rather than leaving it all up to volunteers, allocating resources to fixing
bug 49543 (which would make room for a simple unambiguous `Search' button in the
 main Toolbar) would be an excellent place to start. This bug, however, is just
about the *menu structure*. Gerv's patch, in itself, does not make Mozilla's
search UI perfect; nor does it achieve world peace or find a cure for cancer.

Now, is there anyone else who would like to torture this bug with Catch-22s,
trying to claim that these improvements can't be checked in until we have
usability data which (realistically) can only be collected after checking them
in? If not, then Gerv I think we're ready for your final patch.

Comment 78

[timeless]

> thirdly, the obvious fact that the menu contains only three items,
> only one of which belongs there.
The mozilla seamonkey help menu contained ONE item for a long period of time 
iirc. And I don't remember anyone filing a bug suggesting its removal.

eventually we got about plugins and finally a real help item. which leaves us 
w/ Help (very relevant) About (technically wrong for MacOS) and About Plugins 
(also not particularly correct for MacOS or sane specs).

There is indeed a bug to make the Apple Menu about mozilla item work but there 
has not been a bug to make the Help menu not contain about mozilla (or about 
plugins) for windows.

I suspect that one of the reasons no one filed a bug to remove the mozilla help 
menu was the understanding that we would eventually add additional items. Which 
is along the lines of the justification for retaining search.

We're ready for gerv's final patch in two circumstances, (a) it's the final 
patch he's making for mozilla because he's absolutely sick fo 100k bugs (I hope 
not, gerv does excellent work), (b) it follows the instructions/requests of 
jglick, cmankse, morse, ben, and probably german.  -- Otherwise please don't 
dictate when a patch is final, you are not in a position to do so.

also it looks really bad when people right 'final patch' 'hopefully final 
patch' 'whoops, really final patch' ...

Comment 79

[Gervase Markham [:gerv]]

Latest patch coming up.

I can confirm the Wallet UI hasn't moved (and won't until we work out where it
might move to). 
I've reverted Text Size to Text Zoom - we can revisit this issue when we also
zoom images.
I've moved Messages/Sort/Headers/whatever as jglick requested.

Gerv

Comment 80

[Gervase Markham [:gerv]]

Attachment: Patch v.7

Comment 81

[jag (Peter Annema)]

From a code point of view, this patch looks fine, r=jag for the code part of it.

You'll have to get Ben's and Seth's module owner r= though for the UI part.

Personally I like the Search and Go menus as top level menus. Finding things and
going places are the raison d'etre of browsers, you want those things to be in
the top level I think.

Comment 82

[jglick]

>I've reverted Text Size to Text Zoom - we can revisit this issue when we also
>zoom images.

If we're revisiting this issue later, please leave it as is for now (Text 
Size) instead of changing it.

Comment 83

[Gervase Markham [:gerv]]

Sorry, my mistake. That should read "Reverted Text Zoom to Text Size" (as in, 
left it as it was.)

My apologies.

Gerv

Comment 84

[Ben Goodger (use ben at mozilla dot org for email)]

As UI Module Owner, these changes look promising, and I'd love to see them
integrated. 
As a Netscape employee however, I must ask that these changes not be checked in
until Netscape's UE representatives are satisfied that there is no adverse
impact on Netscape commercial products. 

I am bound to represent two parties but in this case I can only represent one,
my employer. As a result I must vacate my position as Mozilla UI Module owner in
this instance as I believe I cannot fairly represent Mozilla. 

Comment 85

[Zach Lipton [:zach]]

This is the reason why netscape has a comm tree. This should be landed 
in mozilla if approved in the useual way and simply left out of comm until 
all is fine on that end. I know that this is possible, wasn't the same thing 
done with My Sidebar->Sidebar?

Zach

Comment 86

[scottputterman]

Netscape has a commercial tree so we can put in features that we can't release
to open source.  We don't have it so that we can undo the UI changes we don't
like.  Sometimes that happens but it wasn't the reason for it.  In our ideal
world, we would never have any split in the UI (unless for proprietary reasons)
because it makes life hard for all of us (both Netscape and non-Netscape
Mozilla) to maintain differences.  I do not believe that most people would like
a world where the UI started diverging seriously.  I know I wouldn't.  

Comment 87

[(not reading, please use [e-mail] instead)]

taking to brendan and jglick, let's do this:

any UI issue that has been approved (by jglick), should be spun off to another
bug.  feel free to log one big "approved changes" bug and cc the usual suspects.

any open issues, that currently do not have approval, should either remain here,
or be spun off to seperate bugs / threads, for discussion.

that should unblock gerv / mpt on mailnews issues we've got jglick to agree too.

same goes for navigator:  any issues with approval from ben & german, spin off
and fix.

any open issues, keep open and let discussion continue.

I encourage contributors to put more energy into things are *really* broken,
(query bugzilla, I've got pleny of UI bugs to go around, or see
news://news.mozilla.org/[e-mail] for a laundry list of
issues in the addressbook).
anyone is welcome to send me mail if you want to fix something that everyone
agrees needs fixing.

Comment 88

[Brendan Eich [:brendan]]

putterman: just want to point out that not everyone will be happy with any UI,
but if there are too many valued contributors outside netscape.com in the
Mozilla community who are so unhappy that they want something kicked into
netscape.com's commercial, it may be worth the trouble because of the benefits
of sharing the rest of the UI.

I'm not saying that moving a UI feature to the ns tree because Mozilla hackers
don't like it should be done lightly, but it's conceivably for the good of the
project.  I can think of past UI and non-UI examples -- and I believe the Search
and Go menus are current examples in the opinions of gerv, mpt, jag, blake, and
ben, who are all valued members of the community.

/be

Comment 89

[Brendan Eich [:brendan]]

forgot to add (plus, I love watching bugzilla process the cc: list :-) that we
at mozilla.org are open to hosting the commercial overlays and other UI sources
that are not encumbered by license or proprietary considerations, as optional
add-ons or alternatives.  If these files were mostly on cvs.mozilla.org, then
people could more easily QA, improve, test, modify-when-making-syntax-changes,
etc.  Everyone would win, even if the "commercial" features never were folded
back into the default Mozilla UI.

I believe the only obstacle to mozilla.org hosting the commercial bits is
getting a week of leaf's time to change the build goop.

/be

Comment 90

[Ben Goodger (use ben at mozilla dot org for email)]

I would consider the current menu structure to be "really broken" as far as 
Mozilla is concerned. It's not in my top 3 "must haves" for 1.0, but it's 
certainly #4 or #5. Netscape does not agree and as a result has not devoted any 
engineering resources to it, so all the better to have other people doing the 
work, rather than let the status quo stagnate.

Comment 91

[scottputterman]

I would argue that Jennifer has put a lot of time into the mailnews menus and as
far as I can tell it hasn't stagnated and doesn't need an overhaul.  

Comment 92

[german]

Brendan:
the quality of UI is directly contingent upon knowing about and targeting to a
well-known end-user and verifying suitability through uability testing, not so
much to whether not those making the proposals are valued members of a developer
community.
Nobody from Netscape that I have heard from is implying that the proposed
changes don't have some good ideas in them, i's just that there is much more to
changing the UI in such profound way that requires careful consideration for the
larger UI framework as well as usability testing, and therefore should not be 
rushed, because somebody thinks they 'look good' on paper.

Comment 93

[Viswanath Ramachandran]

Ben, we should not rush these changes in a hurry into Mozilla Navigator because:

- The person who designed the menu framework that Mozilla has been using for the 
last few years (German) has objections to it, which are valid and well founded

- One of the primary goals for Mozilla Navigator right now is to build on the 
stability we've enjoyed recently so that a major commercial release can be 
shipped off the mozilla0.9.4 trunk (which I think staff@mozilla has agreed to). 
A change like this really doesnt fit in with that. This commercial release is 
also beneficial to Mozilla because it is a vehicle for distributing millions of 
copies of Mozilla technology. Mozilla is not just for its developers, its also 
for the users who do not yet know about it. 

I agree with Seth that any parts of this bug that have agreement from ben & 
german (for Nav) shd move to a separate bug and get checked in so that they are 
not hostage to the overall discussion. 

On Brendan's idea of moving Netscape's proprietary chrome to a special 
extensions area on Mozilla's CVS server, that's a great idea, let's start 
working on that. I think that Netscape MailNews and Nav people should start 
figuring out how to do this soon. 

Comment 94

[Blake Ross]

German: wow, you sure do love to throw that usability studies argument around,
don't you?

All you ever do is talk about how silly people are for basing things on personal
opinion (and most of the time, they're not) instead of usability studies.  Then
you're asked what kinds of usability studies you conducted, and suddenly, oops!
You're too busy doing something else to answer!

Because the truth is that, with the exception of one, usability studies were
last conducted about four years ago:
http://gooey/usability/studies/index.html#client.

The community is not waiting a year or two for your usability testing, which is
always 'on the way'.  You'll have to find a new excuse.

Comment 95

[Viswanath Ramachandran]

I'd like to rephrase my first point to 

- The person who designed the menu framework that Mozilla has been using for the 
last few years (German) has objections to it, which are well founded and bear 
investigation/consideration

Comment 96

[Blake Ross]

I found one browser one from September of last year that was unrelated to menus.
 Is menus one of the ones that is happening 'after 0.9.4'?  Who is conducting
these usability tests?  Are you?  Because the one who did that one no longer
works here.

Also, why is it that you belittle Mozilla contributors every time an issue like
this comes up?  Do you expect that any of them have the money and resources
necessary to conduct a usability test?  Or is the plan just to stunt Mozilla's
development until a Netscape usability study is done for the browser (which
seems to be happening on a yearly basis)?

Comment 97

[Blake Ross]

I've filed bug 93182 to handle the Edit and View menus in MailNews.  This bug
should focus on Edit and View for Navigator.  Other menus that this patch
touches (like Go) should be handled in separately filed bugs.

Comment 98

[Asa Dotzler [:asa]]

"One of the primary goals for Mozilla Navigator right now is to build on the 
stability we've enjoyed recently so that a major commercial release can be 
shipped off the mozilla0.9.4 trunk (which I think staff@mozilla has agreed to). 
A change like this really doesnt fit in with that."

I don't think that this is likely to impact stability in any significant
measure. If it does then better to get it in well before Mozilla 1.0 (and early
in any Milestone cycle) so that we can get some testing and talkback data on
whether it does or does not affect "the stability we've enjoyed recently". 

[e-mail] are in agreement that building on stability is a good thing. 
I don't think that this change goes against that in any way.  If there is
genuine concern about stability here (I just can't see how this is gonna
destabilize us more than say the imagelib removal) then maybe we should do some
testbuilds. 

Comment 99

[Blake Ross]

This is too out of hand to make any progress on in this bug.  I think the main
problem here is the patch attempts to cleanup all of our menus under the
pretense of a bug dealing with just two.  I filed bug 93184 to handle issues
with browser's Edit and View menus and bug 93185 to deal with issues in Editor's
versions of these menus.  Bug 93182 will continue to handle MailNews issues with
those two menus.  The appropriate module owners have been cc'd on each, and they
will make the necessary decisions.  

Closing this bug.

Comment 100

[Ben Goodger (use ben at mozilla dot org for email)]

Gerv, can you split your patches appropriately and update the bugs that blake 
has created? 

Vishy - your points are valid from a Netscape point of view and I have supported 
them to the best of my ability (see my comment regarding the patch, dating 
2001-07-31 23:57) However I don't believe that in this instance I cannot singly 
consider both Netscape and Mozilla responsibly, so I'm doing the only 
responsible thing I can do - excuse myself. [Dis]approval of the Navigator 
patches will come from mozilla.org.

Comment 101

[Ben Goodger (use ben at mozilla dot org for email)]

putterman: I was primarily referring to Navigator menus with my comment on 
stagnation. I haven't investigated the mailnews menus. 

Comment 102

[Zach Lipton [:zach]]

Rubberstamp verif. Move along all, nothing to see here...

Comment 103

[Ben Goodger (use ben at mozilla dot org for email)]

Also, end users are never far from my mind when I'm developing UI. I'd argue 
that I take more consideration for them than a good deal of the developers 
working on UI for this project. 

Any refinement of the term "target user" from German or the Netscape UE team is 
welcome however, since Mozilla's UI seems to be restrained to this invisible 
definition. 

I don't imagine it's drastically different from what I've been developing to all 
along...

Comment 104

[Matthew T (active 1999-2002)]

Reopening. Blake, I suggest you re-read my 2001-07-13 11:58 comment and Ben's
2001-08-01 17:41 comment.

No, this bug does not attempt to clean up `all of our menus'. As has been stated
several times already, the `Tasks' menu and the `File' menu will each be dealt
with in separate bugs following this one. They are our top priority once this
bug is fixed, because the current overall menu structure is perhaps the 4th
biggest UI problem with Mozilla (after bug 49141, bug 49543, and bug 54171, none
of which we have the expertise to do anything about). The current menus suffer
from exactly the same problems as their author's comments in this bug: they are
unnecessarily complicated and jargon-filled, they lack logical flow, and they
shamefully claim authority from usability testing which doesn't actually exist.

This initial patch fixes (to use sspitzer's words) the most *really* broken
things first. (Putterman, if you have forgotten what these problems are, my
2001-07-11 09:25 and 2001-07-11 09:27 attachments are still there for your
perusal.) The change is *as small as it can be* in this regard, while still
making sense across Mozilla applications. If any patch tried to fix the menus in
just one app, it would be rejected -- and rightfully so -- because it would
introduce inconsistency across apps.

So, we are waiting for sr= from Brendan for the Navigator improvements (because
of Ben's declared conflict of interest), and for sr= from sspitzer for the
mail/news improvements. Seth, I think the current patch is a good compromise
between jglick and the rest of the Mozilla project -- it gives jglick the
`Message Source' that she wanted, the `Text Size' that she wanted, and the
inconsistency in ordering of the `View' menu that she wanted. Any further
inconsistency would, I think, raise questions about why mail/news was part of
the same suite as the rest of Mozilla at all.

Comment 105

[Matthew T (active 1999-2002)]

*** Bug 93184 has been marked as a duplicate of this bug. ***

Comment 106

[Matthew T (active 1999-2002)]

*** Bug 93185 has been marked as a duplicate of this bug. ***

Comment 107

[Matthew T (active 1999-2002)]

*** Bug 93182 has been marked as a duplicate of this bug. ***

Comment 108

[Brendan Eich [:brendan]]

german: "the quality of UI is directly contingent upon knowing about and
targeting to a well-known end-user and verifying suitability through uability
testing," -- agreed -- "not so much to whether not those making the proposals
are valued members of a developer community."  Nice try, but I'm talking about
*specific* members of *our* community who know about and target well-known
end-users, members such as ben and mpt.  The community values members based on
their work, not for random qualities at odds with usability.

I can't find formal usability study results from anyone involved in this bug on
a public website, so all I can go by is demonstrated end-user knowledge and
targeting ability.  Also, it is clear from the specs that are available, and
from bug and news traffic, that the browser UI has evolved quite a bit over the
last several years for many reasons other than usability study results.

mpt: if I sr= the v.7 patch and it goes in, then some small-ish amount of work
in the netcape.com commercial tree will have to take place to restore the
removed UI elements to netscape.com's Mozilla-based product.  Before sr'ing, I
would like to get agreement from the netscape.com owners who would likely have
to do that work, that they can do such work now.  This agreement shouldn't take
long (more than a day) to secure.

/be

Comment 109

[Gervase Markham [:gerv]]

Wow.

I agree with mpt - this bug should not be lots of little ones, because one of 
the aims is cross-app consistency. We have restricted ourselves to two menus, 
and I repeat my promise to fix the other ones as well, so things are not left in 
an inconsistent state.

If you would like to do Go as an overlay of some sort so it can be in different 
places in the Mozilla and Netscape builds, that would be great. I might even put 
my hand up for working out how to do it. :-) But I'm not going to do that work 
before the initial checkin of this patch.

I now hope that, after this discussion, sspitzer will consent to sr= the 
Mail/News changes.

Gerv

Comment 110

[scottputterman]

I'm reopening 93182.  If you want to get the mailnews changes in you will have
to go through the mailnews module owners.  Please do not checkin the mailnews
changes regardless of whether brendan sr='s them until the issues are resolved
in 93182.  There has been no mailnews module owner approval yet.

Comment 111

[Blake Ross]

Yes, it would be great if we had a[n] individual/team responsible for ensuring
consistency throughout the UI.  That's the ongoing pixeljockies discussion, and
it  doesn't belong here.

So, for now, the answer is that module owners will approve.  If MailNews, for
example, wants to keep its Go menu, then they will.  There is no reason that a
bug to do different things to two different menus for each of three apps should
be handled in a single bug until a person or persons exist who have the
authority to make such a cross-app decision.

Comment 112

[Gervase Markham [:gerv]]

Why can we not do what I suggested - eventually do Go as a 
dynamically-positioned overlay, with different contents.rdf (isn't that how it's 
done) for the two trees? That way, everyone's happy. Aren't they?

Gerv

Comment 113

[(not reading, please use [e-mail] instead)]

Everyone wants to make progress on this bug.  (or the nav / mailnews spin offs.)

Here's my plan:

I'll apply patch v.7 and sit down with German today and go over the changes to
the UI on my build.

Based on previous comments from jglick and feedback german has on the changes,
we'll come up with a list of what is ready to land, and what changes are still
open for discussion.

Some additional comments:

I'm continually appalled by the lack of professionalism and courtesy I see in
this bug report.  

When did open source become an open license for being rude?  Bugzilla isn't the
place for that.  It doesn't add any value.  If anything, it slows progress.

heated discussions are acceptable.  we're all trying to come up with the best
product for our users.

I apologize (especially to jglick and german who take most of the crap) on
behalf any contributors (internal to netscape or external) who don't fully
understand the concept of "The Mozilla Community".

while german and I work together to make progress, I suggest everyone else go
re-read http://www.mozilla.org/community.html

Especially the first item:

*  Be civil.

No personal attacks. If you feel the need to flame someone, please do it in
private email. Do not feel compelled to defend your honor in public.

enough said.

Comment 114

[Blake Ross]

Sorry for getting frustrated.  It's just that everyone is continuously told to
hold off on UI changes because everything must be backed up with results from
usability studies.  But, as I understand it, Netscape don't even have a
usability lab anymore, and most or all of the usability team it had (that
conducted such studies) are no longer here.  I and others have repeatedly asked,
in bugs and personal e-mail what is being done about this, and where the studies
are that the UE team wants the community to base their changes around.  And
every time, such questions are ignored (in fact, I asked on 7/11, in this bug,
where the usability studies are, and I received no answer).  I think it is
unreasonable to continuously deny everyone the right to improve the UI of the
product unless the UE team shows that they have a genuine interest in doing more
usability studies.

Comment 115

[jglick]

The last usability study we had was 11/00.  The results as they related to Mail 
were posted on mozilla on 12/00:
http://www.mozilla.org/mailnews/specs/meetings/MailIssues12_6_00.html

There is actually a usability study being conducted next week, August 8 and 9.  
It will cover installing the product and some basic tasks from each of the 
components.  I'll post a summary to the above mentioned area once the study is 
completed.

Comment 116

[Gervase Markham [:gerv]]

Usability studies are also very much what you make them. If you find a problem, 
there are a number of different possible solutions (as jglick's document handily 
demonstrates) and there may be things you can do to improve the UI that a 
usability study will not tell you to do (mpt's example about always making 
checkboxes turn something _on_ springs to mind.)

No usability study will give you some metric on whether Go | Next | Message is 
better than View | Go to | Next Message. (As a side point, I would point out 
that the Go changes proposed do not require any extra clicks to reach any of the 
menu items.)

Gerv

Comment 117

[german]

Usability lab studies are not all designed to tell you how to design something, 
they record observable user behavior and thus are help to spot problems. The 
reason we need them is not whether one or the other is faster (that would be a 
usability benchmark test), but to to make sure that any severe re-design like 
this is going to impede previous users of 6.0 as well as users of 4.x.
You are right in that it still takes a UI designer to conceive and redesign a 
robust interaction design model.

Comment 118

[Gervase Markham [:gerv]]

> but to to make sure that any severe re-design like 
> this is going to impede previous users of 6.0 as well as users of 4.x.

Oh, now I understand what you are saying :-) You are saying we should make all 
the changes (including the File menu fixups and Window/Tools) and then do a 
usability study to compare the two menu systems - say between 0.9.3 and 0.9.4.

What a good idea :-) I totally agree.

Gerv

Comment 119

[(not reading, please use [e-mail] instead)]

I sat down with german and we compared two builds side by side.

His issues with these changes are very reasonable.

The big question is this:

Do we want "Search" and "Go" in top menu (with "File", "Edit" and "View") or do
we want those items underneath "Edit" and "View"?

The current implementation (mozilla trunk, Netscape 6.x) follows what Netscape
4.x did.  ("Search" and "Go" are top level.)

This patch moves those items from the top level into places below "Edit" and
"View".  (Following what IE 5 does.)

jglick and german have voiced their opinions about this.  They're for keeping
"Go" and "Search" the top level.  

Speaking as the mailnews front end module owner:  I agree with putterman, jglick
and german, the "Go" and "Search" should stay where they are.  I agree that
having them top level makes those items more discoverable.

As far as the navigator changes, I also agree with german.  but the decision for
navigator falls to ben & german.  (personally, I agree with german on that
issue, too.)

there is more to just that in this patch.  gerv, feel free to spin off any
changes that were approved by jglick into seperate bugs so we can get them
reviewed and landed.

Comment 120

[Asa Dotzler [:asa]]

"The current implementation (mozilla trunk, Netscape 6.x) follows what Netscape
4.x did.  ("Search" and "Go" are top level.)
"

This is blatantly wrong.  Search was absolutely not a top level menu in 4.x. 
I've got mac, win32 and linux 4.x builds in front of me at this very minute and
not one of them has Search in the top level.

So other than "voiced their opinion" that it "makes those items more
discoverable" (which is plainly obvious. any menu item would be more
discoverable in a top level than not) what is the justification for straying
from the 4.x and IE model on the Seach menu location? 

Comment 121

[(not reading, please use [e-mail] instead)]

> "The current implementation (mozilla trunk, Netscape 6.x) follows what Netscape
> 4.x did.  ("Search" and "Go" are top level.)"
> This is blatantly wrong.

sorry, I was looking at 6.x classic.  "Go" was at the top level, "Search" was
not, it was under "Edit", as was "Find...".

moving "Search" to the top level was an mozilla improvement over 4.x.  In
mailnews, we wanted to unify search (search messages, search the web, search in
the message) to one place:  "Search".

I'm standing by the decision to leave "Search" at the top level, and unify all
"Search" stuff under it.

Comment 122

[Gervase Markham [:gerv]]

> moving "Search" to the top level was an mozilla improvement over 4.x.  In
> mailnews, we wanted to unify search (search messages, search the web, search 
> in the message) to one place:  "Search".

"Improvement" is a loaded word. To make this "improvement", you have to move two 
menu items which _everyone_ expects to find under "Edit" to under "Search" (Find 
and Find Next). I agree that Mail has "Search Messages" but it was under Edit in 
4.x. I can think of no other searches (Search The Web is a hard-coded bookmark, 
and belongs in bookmarks) which could justify a top-level search menu in Nav or 
Mail/News. I'm with mpt in saying that Search Bookmarks should be in the 
Bookmarks menus, and Search History should be in the History menus. Or we should 
have a multi-tabbed Search dialog, with a tab for each. 

Gerv

Comment 123

[Gervase Markham [:gerv]]

I've had enough of this.

Do you have any idea (maybe some of you do) how complicated disentangling this
80k patch into three is? Particularly as you then have to specify which order
they have to get checked in in, and that the same file has to appear in more
than one patch. Trying to do it that way is patently stupid, and I don't have
the time or resources.

sspitzer: You want Mail to have Search and Go menus, right? Fine - I'll put them
back. Is there anything else you want me to reverse in order to get a=?

Gerv

Comment 124

[Gervase Markham [:gerv]]

Reopening for tracking purposes.

Gerv

Comment 125

[timeless]

*** Bug 106868 has been marked as a duplicate of this bug. ***

Comment 126

[Gervase Markham [:gerv]]

Any large-scale reorg of the menus will have to wait until after Mozilla 1.0.

Gerv

Comment 127

[Blake Ross]

This is fixed.