Closed Bug 32502 Opened 24 years ago Closed 22 years ago

Simplify task menu to three-level menus

Categories

(SeaMonkey :: Passwords & Permissions, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 108099
mozilla1.0

People

(Reporter: mpt, Assigned: bugzilla)

References

()

Details

(Whiteboard: se-radar [need info][adt3])

Build: 2000031908, MacOS 8.6

The ability to change the Master Password should not be in a submenu of a submenu 
of the Tasks menu. It should be a button in the Password Manager instead.

Reasons:

* Doubly-nested hierarchical menus are really, *really* bad UI design. See URL.

* It is much easier to explain the purpose of a master password, and the
  usefulness of setting it, inside a dialog devoted to storing the things which
  the master password protects, than in a parsimonious menu.

* Changing your master password isn't something you're going to do often enough
  for it to deserve its own menu item.

So, make a `Change Master Password' button in the Password Manager dialog, and 
turn the `Tasks' > `Password Manager' > submenu into a `Tasks' > `Password 
Manager' menu item.
The layout of the task menu is temporary -- German has promised us a special 
line in the chrome to access the wallet functions sometime in the future.

But accessing it from the signon viewer as well is a good idea.  I'll try to get 
that in before the beta2 freeze (M16).
Status: NEW → ASSIGNED
Target Milestone: M16
On second thought, I'm not so sure this is a good idea.  The password is shared 
between single-signon and wallet.  So should we also put a button in the wallet 
editor to change passwords.  What about the wallet previewer?

It seems like the best place for invoking the change-password function is 
someplace that is common to both of them.  An obvious suggestion is the pref 
panel in the advanced/password-manager pane.

But this should really be UE's call.  Reassigning to German.
Assignee: morse → german
Status: ASSIGNED → NEW
Yep - what I would recommend:
We leave the menu as is, but would not make this the only means of accessign the
Master Password.
We add a 'bridge' button labelled 'Change Master Password...' to the bottom of
the 'Password Manager'pane in prefs. Any future addtion to 'Personal Managers'
that will have prefs will hopefully fit into the same prefs pane. (which should
then get relabeled 'Personal Managers' just like the Menu)
Re-assigning to Steve.
Assignee: german → morse
Target Milestone: M16 → M15
Fix in hand.  Will check it in as soon as the tree opens today.
Fix checked in.  Files affected are pref-wallet.xul and pref-wallet.dtd.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
there's now a "Change Passwords" button in the Forms & Passwords panel in prefs
(although there are still issues --see bug 33545). the menu item is [still
remains as per german]  Tasks > Personal Managers > Password Manager > Change
Master Password...

verified with the following opt comm bits:

linux 2000.03.28.09
macOS 2000.03.28.10
winNT 2000.03.28.09
Status: RESOLVED → VERIFIED
Ironically, the main thing I was concerned about was the yukky nested submenus, 
and that's the only part of the bug report which hasn't been fixed. :-)
I happen to agree with you on that one.  But that was German's call.

Here is my proposal for eliminating the three levels of menus.  German, what's 
your opinion on this?

Currently we have:

  Navigator
  Mail
  Composer
  -----
  Address Book
  Newsgroups
  Personal Managers
    Security Manager
    Password Manager
      View Stored Passwords
      Change Master Password
    Cookie Manager
      View Stored Cookies
      Allow Site to Set Cookies
      Block Site from Setting Cookies
    Image Manager
      View Sites that can/cannot Display Images
      Allow Site to Display Images
      Block Site from Setting Images
    Form Manager
      View Stored Form Data
      Prefill Form Safely
      Prefill Form Quickly
      Capture Data From Form
      Interview
      Demonstration
  -----
  Tools
    History
    Import Utility
    Java Console
  Password Mozilla

I would prefer to see:

  Navigator
  Mail
  Composer
  -----
  Address Book
  Newsgroups
  -----
  Security Manager
  Password Manager
    View Stored Passwords
    Change Master Password
  Cookie Manager
    View Stored Cookies
    Allow Site to Set Cookies
    Block Site from Setting Cookies
  Image Manager
    View Sites that can/cannot Display Images
    Allow Site to Display Images
    Block Site from Setting Images
  Form Manager
    View Stored Form Data
    Prefill Form Safely
    Prefill Form Quickly
    Capture Data From Form
    Interview
    Demonstration
  -----
  Tools
    History
    Import Utility
    Java Console
  Password Mozilla
Absolutely. And then we wouldn't have the problem of trying to decide whether to 
call the main menu item `Personal Managers', or `Personal Data Managers', or 
`Privacy Managers', or `Security Features', or ...
heh! it would be nice to get rid of the Personal Managers parent menu.

so, with this recent exchange, shall we reopen this or open a new bug (prolly
better, as this seems to be morphing :-)?
Reopening per Sara's suggestion.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Reassing to German to make a decision on the menu change.  German, if you agree 
that we should change the menu as described above, reassign to me and I'll 
implement it.
Assignee: morse → german
Status: REOPENED → NEW
Summary: Put `Change Master Password' in Password Manager dialog, not menu → Simplify task menu to three-level menus
This is not a stability blocker for M15 branching... so I'm pushing this to M16
Target Milestone: M15 → M16
Keywords: nsbeta2
Problem is there is (sorry marketing) a bunch of other useless $$$ stuff 
sprinkled into the menu which is not in there yet for the Netscape version. I am 
just worried about the overall length of the menu. Other than that the suggestion 
is very reasonable. I'll try to get the proposal from PM and work with them to 
reduce it such that we can have the proposed easier to access menu structure.
Whiteboard: will decide by 5/7
[nsbeta2-]
Whiteboard: will decide by 5/7 → [nsbeta2-]will decide by 5/7
M16 has been out for a while now, these bugs target milestones need to be 
updated.
nominating nsbeta3
Keywords: nsbeta3
I still much prefer the current implementation which uses "Privacy and Security" 
as the umbrella term. Reason: that will likely make it understandable for end 
users what's underneath there without scaring them with a cluttered menu full of 
'managers'. That ways it looks both less complex as well as it gives a context 
what these are for. 
Clearing nsbeta2.
Status: NEW → ASSIGNED
Keywords: nsbeta2
Whiteboard: [nsbeta2-]will decide by 5/7
Target Milestone: M16 → M18
It might give them a clearer understanding but it will also insure that they 
will never use features such as wallet because its just too tedious to get to 
the menu entry.
adding dependency; also adding mostfreq --i know there aren't any dups (yet), 
but this issue crops up so frequently that i want it easily accessible when i 
query my bugs.
Blocks: 48860
Keywords: mostfreq
Yes, I don't care much how understandable it is for the end user if it isn't 
easily accessible.  They only need to learn to use it once, but they will need 
to access it often.  I think we need to reach a better compromise between 
accessibility and learning curve.

Please reassign to me when a UI/UE decision is reached so I can make the 
necessary change.
Removing mostfreq - this bug does not yet qualify for this keyword under the 
established criteria.

Gerv
Keywords: mostfreq
adding se-radar to status so that i can find this bug more easily. pls don't
remove it [yet], thx.
Whiteboard: se-radar
Marking nsbeta3- while assigned to german.
Whiteboard: se-radar → [nsbeta3-] se-radar
spam: mass-moving open password manager (single signon) and form manager
(autofill) bugs to Terri for qa contact. unfortunately, i cannot cc myself with
this form, so feel free and add me if you want to keep me in the loop with any
(but, pls not all :) of these... will also go thru 'em meself, a bit later...
QA Contact: sairuh → tpreston
If German isn't going to do anything with this bug in 5 month's time, maybe 
Matthew will.  reassigning to him.  Give me one clear description of how the 
Tasks menu needs to be (and maybe some ascii art ;) and I'll give you a patch.
Assignee: german → mpt
Status: ASSIGNED → NEW
Hmmm, this bug is morphing more and more -- but whatever, here's what I think 
should happen to the Tasks menu.

In general:

_Tools
------
  {applications}
------------------------------
  {application-specific tools}

In particular, for Navigator:

_Tools
------
  _Navigator                         Ctrl+1
  {user's chosen mailer}             Ctrl+2
  {user's chosen editor}             Ctrl+3
  {user's chosen chat client}        Ctrl+4
---------------------------------------------
  _Search the Web ...          Shift+Ctrl+F
  _Bookmarks                         Ctrl+B
  _History                           Ctrl+H
  U_tilities                                >

Utilities submenu
-----------------
  _Auto-Fill Manager
  _Password Manager
  _Cookie Jar
  _Java Console
  _Script Console
  _Import/Export

Brief answers to the `where did they go?' questions for the existing menu items 
will follow after I reboot (Mozilla is currently refusing to show me the submenus 
at all).
Ok. Here's where all the items in the old Tasks menu should go, where they're not 
the same in the new Tools menu:

* `Address Book': one of the {application-specific tools} for Messenger, but not
  for Navigator. (If your chosen mailer is Eudora, having this item in
  Navigator's menus doesn't make a lot of sense.)
* `Personal Security Manager': If someone can explain what this item is for (it
  doesn't seem to do anything), then I'll find a place for it.
* `View Stored Passwords' --> `Password Manager'.
* `Change Personal Security Password ...' --> a `Change Master Password ...'
  button in the Password Manager window (as this bug originally requested).
* `Log Out' --> `File' > `Quit'.
* `Encrypt Sensitive Information' and `Obscure Sensitive Information' -->
  /dev/null. This is already in the prefs dialog, and doesn't deserve a more
  prominent interface (ideally it shouldn't be necessary at all).
* `Clear Sensitive Information' --> the Delete key when in the Password Manager
  or the Forms Manager.
* `View Captured Form Data' --> one of three tabs in the Auto-Fill Manager.
* `View Sites' --> the other two tabs in the Auto-Fill Manager.
* `Interview' --> somewhere on mozilla.org. No-one (*no-one*) is going to bother
  carrying out the interview, for the same reason that no-one reads the manual
  before they use an app: they just want to *use* the program, dammit.
* `Demonstration' --> somewhere on mozilla.org.
* `View Stored Cookies' --> `Cookie Jar'.
* `Allow Cookies from this' [sic] and `Block Cookies from this Site' --> the
  `Always Accept' and `Always Reject' buttons in the cookie confirmation dialog.
* All the items in the `Image Manager' submenu --> the `Filters' subcategory of
  the `Display' category in the prefs dialog.
* names of open windows --> the taskbar of your friendly local window manager, or
  bug 53505 if you are unlucky enough to be on a Mac.

Reassigning to Blake. Give this menu the slapping it so thoroughly deserves.
Assignee: mpt → blakeross
Also note that this bug is now practically a dup of bug 17767.
Make sure you have PSM installed.  The `Personal Security Manager' item does do 
something.
Status: NEW → ASSIGNED
No enabled menu item should ever do nothing, no matter what I do or do not have 
installed. At the very least, the item should ask me if I want to install PSM.
Matthew: File a separate bug on that to the security crypto team and cc me.
Priority: P3 → P2
Target Milestone: M18 → mozilla0.9
Priority: P2 → P3
Target Milestone: mozilla0.9 → mozilla1.0
See also bug 67416.
A few thoughts:
- address book access does make sense for all apps, as it's not just for mail. 
People entries are used throughout the product for example for presence 
information in IM buddy lists which can be used from Navigator.
- PSM manages all your certificates (your own and the ones you receive), again 
used in apps throughout
- The interview thingie has been taken out and superseeded by a editable "View 
stored contents" lists in the Forms manager
- I do not particularly care for whether it's Tools or Tasks, although Tools is 
very win32-esque. Win32 users might expect prefs/options there.
- I do care about taking out the Open Windows, that is a regression from what 
we had in 4.x and we should leave it in.
- I also believe the Privacy/Security/Data Entry convenience tools should not 
be lumped together with JS and Java stuff, I believe they are important enough 
to warrant their own umbrella term. Under 'utilities' it is virtually 
guaranteed that a large percentage of users will never touch these.
A few responses:
- Mozilla doesn't have buddy lists, and it will not in the forseeable future.
  So there is no point in having the Address Book available anywhere other than
  in Messenger. I know of no other Web browser which includes an address book
  in its menus.
- Tools might once have been Win32-esque, but once every Microsoft Mac app
  included one, it ceased to be so. If Windows users expect the prefs to be
  there, that's because -- on Windows -- the prefs *should* be there.
- Taking out Open Windows isn't a regression, it's making Mozilla simpler and
  more consistent with the rest of the OS. Outlook Express for Windows doesn't
  give me a list of the windows which I have open in Opera, or vice versa.
  There is no need to: it's a job for the OS, not the app. Except for Mac OS
  (which is covered by bug 75546), window managers list open windows quite well
  enough by themselves.
- I don't believe that having `Privacy/Security/Data Entry convenience tools'
  (what logic groups *those* together??) in their own submenu will make them
  any more accessible -- if anything, it will make them less accessible, since
  users will no longer see them when they go for the other items in my
  proposed `Utilities' submenu. Ideally, Web users wouldn't have to deal with
  any of that stuff at all ...
Keywords: nsbeta3
Priority: P3 → P1
Whiteboard: [nsbeta3-] se-radar → se-radar
Target Milestone: mozilla1.0 → mozilla0.9.1
Priority: P1 → P2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Priority: P2 → --
Target Milestone: mozilla0.9.3 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla0.9.5
See also bug 102592, "Please make Tasks > Tools a toplevel menu".
Target Milestone: mozilla0.9.5 → mozilla0.9.6
morse, aren't you doing menu reorg type stuff? If not, send back.
Assignee: blakeross → morse
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.6 → ---
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
Yes, the window list needs to go away, and the "managers" need to be more
accessible, they're useless how deep they're buried... I can get to them through
prefs quicker: alt-e, e is alot faster then alt-t, p, c, v or trying to actually
navigate that mess with a mouse.

The stuff in image manager is useless. You VERY rarely want to block images from
the current server, as most things you want to images are eaither third party,
or from a differant host (static instead of www, etc). Image manager should
launch the viewer, which would have a manual entry textbox. If you really want
to block an image your seeing, it should be in the context menu. There, image
manager is down to 1 item.

Password manager: reset/change password, and obscure/encrypt do not belong in
the menus. They require a little explaination, and aren't used much (er...EVER,
for 98% of users). Log out is debateable... (just close mozilla, alot more
obvious and failsafe, but take it out and down to one item there too (view
stored passwords).

As far as the top entries in the menu... I don't care eaither way, but I didn't
see it mentioned address book would be useful in the browser for web mail, or
sending greeting "cards" (ugg, my parents love those dumb things).

As far as mpt's suggestion on using chosen editor/mailer/chat program there, I
don't think we should be turning Mozilla into some generic application launcher.
I don't install mailnews or chatzilla at all and never plan to, so I'm quite
content with those entries just not appearing. I launch my mailer with
'm<enter>' (short for mutt) from the command line. I don't see why I'd want
Mozilla to do that for me.

Some of the Tools (well, History at least), would be nice in the main tasks
menu. I tend to just hit ^H anyway, though.
Depends on: 106577
Moving to 1.0 because the bug it depends on (bug 108099) has been moved to 1.0.  
And if that bug is fixed late in the 1.0 cycle, this one won't go in until 1.1
Target Milestone: mozilla0.9.8 → mozilla1.0
Keywords: nsbeta1
Nav triage team needs info from UE: is this work covered in the menu spec we all
discussed in PixelJockeys, and agreed to?
Whiteboard: se-radar → se-radar [need info]
Nav triage team: yes  (although it's now called tools menu not tasks, and some
details may not be finalized, however the goal will be to reduced submenus in
any event)
thanks - nsbeta1+
Keywords: nsbeta1nsbeta1+
Whiteboard: se-radar [need info] → se-radar [need info][adt3]
morse, have you already begun working on this, or can I take it? I'd hate to see
this get cut.
No, I haven't done anything here yet.  I've been waiting for a final
spec from Marlon.  It's on the landing plan.

If you want it, and you have the time, then go for it.
The spec <http://www.mozilla.org/mailnews/specs/proposals/MenuFrame.html> is
nearly final, will be discusse at PixelJockeys next week.
*** Bug 102592 has been marked as a duplicate of this bug. ***
-> me

As I understand it,
http://www.mozilla.org/mailnews/specs/proposals/MenuFrame.html is supposed to
now be complete. But I don't see how it can be deemed complete without most of
the accesskeys specified...
Assignee: morse → blaker
Status: ASSIGNED → NEW
And could someone who was at the meeting please explain this to me:

"1.  File Menu. "New <component window>" is the first menu item, plus the first
menu item in New flyout menu. Remove it as first menu item and only have it as
first menu item in New flyout menu. Top items in New flyout are specific to that
app. Items below the splitter are applicable to other apps. Pixeljockeys
3/20/02. Agreed to give this a try. If there are problems, will re-evaluate."

With this change, there is no quick way to open a Navigator (or any type of)
window anymore (Tasks > Applications switches windows once you have 2 open).  I
think this is a really bad idea, and apparently others at the meeting did too. 
What does "if there are problems" mean?  We're going to ship to the world and if
people complain, we'll reconsider?  That doesn't seem good enough to me for a
menu item with such a high frequency of usage.
I'd like to attach a patch for this but I'm getting mixed messages from people
who were at the meeting.  Is
http://www.mozilla.org/mailnews/specs/proposals/MenuFrame.html the final spec or
not? Since it was apparently updated Friday, I'd guess yes, but it still lists
Work Offline under Tools and I was told that that was going to stay under File.
That spec  currently has a mod date of 2AM GMT on March 22, which is well before
Friday's PJ meeting.  I think UE has not yet updated it to reflect the latest
decisions; which is quite understandable considering they were made in a late
Friday afternoon meeting. 
Spec hasn't been updated yet. Pixeljockies meeting was late friday. I'll be 
finishing up the spec based on the meeting and hopefully get it posted to 
mozilla shortly.
dup'ing against bug 32502 since both are nsbeta1+ and cover the same menu work
(but that one's more general)

*** This bug has been marked as a duplicate of 108099 ***
Status: NEW → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → DUPLICATE
Verified Duplicate
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.