107134 - Account Settings should be more obvious

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

[Andy Lyttle]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

I've got a browser window open and I'm looking at my home page.  My e-mail is
not configured yet.  I decide I want to set up my e-mail account.  The obvious
place to do this is Edit/Preferences (that's where it was in Netscape 4.x). 
There are some mail settings there, but nowhere to enter pop/imap/smtp servers.

I'm inclined not to click the Mail & Newsgroups button, because I know the
account is not configured yet, and normally doing that would give an error, or
try to check an old account, or some other undesirable behavior.

With a Mail & Newsgroups window open, Mail & Newsgroups Account Settings appears
under the Edit menu, next to Preferences - perfectly obvious.  However, it's not
obvious that this is where I must go to configure it initially.

Reproducible: Always
Steps to Reproduce:
1. Start from a browser window
2. Go to the Edit menu
3. Click Preferences
4. Look under Mail & Newsgroups section

Actual Results:  Account Settings is not found.  There is no indication of where
to enter pop/imap/smtp servers.

Expected Results:  Either Account Settings should be in the Preferences dialog,
or should always be next to Preferences in the Edit menu, or there should be a
button from Preferences to open Account Settings, or something like that. 
Suggestions?

Comment 1

[Boris Zbarsky [:bzbarsky]]

It would make sense for mailnews to overlay itself into the browser menus to add 
that option if it's installed...

Comment 2

[Andy Lyttle]

That sounds good to me.  Note than on Mac OS X, the Account Settings option
should go above Preferences in the Application menu, not the Edit menu (see bug
68098).

I think a button linking to the Account Settings dialog or maybe just a text
reminder, within the Mail & Newsgroups section of Preferences, would be
appropriate.  If the user is on a browser window, they'll see the Account
Settings menu item before they go to Preferences, but if they're already in
Preferences for some other reason and then decide to set up their mail, they'll
be lost.

Comment 3

[scottputterman]

+'ing for adding to browser and then adding something in prefs to point to
account manager.

Comment 4

[Matthew T (active 1999-2002)]

I've got Microsoft Excel open and I'm looking at a spareadsheet.  My e-mail is
not configured yet.  I decide I want to set up my e-mail account.  The obvious
place to do this is Tools/Options in Excel ...

Um. Mail/news prefs don't belong in Excel's menus, they don't belong in 
WinZip's menus, they don't belong in Composer's menus, and they don't belong in 
Navigator's menus. The right way to fix this bug is for the mail/news prefs to 
get out of our browser prefs dialog. Completely. Shoo!

Comment 5

[Andy Lyttle]

Except that while it's obvious to the user that Excel and WinZip are separate
applications and will behave as such, it is not so obvious that Navigator and
Messenger are separate applications, for a number of reasons.  They appear to be
two features of a single application which has application-wide preferences.

On Windows, Navigator and Messenger windows both have the same icon in titlebars
and taskbar buttons.  On Mac OS, the name of the application and its icon are
clearly displayed in the Application menu, and it behaves as a single
application (even more obvious on the Mac than Windows).  Mozilla (including all
of its components) are one application.  Although Excel and Word are both parts
of Office, Excel and Word are clearly seperate applications and behave as such.

Netscape 4 was a single application with multiple components just as Mozilla is.
 In Netscape 4, mail servers were configured under Preferences.  A user familiar
with Netscape 4 will look here and find the familiar "Mail & Newsgroups" section
of Preferences, but the settings for mail servers are missing.

I appreciate the logic that mail settings do not belong in the browser or
elsewhere.  However, at the very least, there should be something in the Mail &
Newsgroups section of Preferences that informs the user of where to go for those
settings, preferably with a clickable link that will open the appropriate dialog
box directly (like the links that are, for example, scattered throughout System
Preferences in Mac OS X for exactly this same reason).

As for the overlay into the Edit menu system-wide, A) I think it's reasonable
for something like this, and B) I'd like to hear more user feedback on the idea,
maybe Netscape's UI people have some input?

Ideally I think it would be nice for Mail & News Account Settings to be moved
into Preferences somehow (though I'm not sure the best way).  That would solve
this problem (while creating different ones most likely).

Comment 6

[Aaron Lawrence]

Just because in Netscape 4 the programs were really one program, does not make
it the right thing to do. For example, Office is a suite of programs, but you
don't get Excel options in the Word menus. 

That said, it tooks me a while to get used to the separate mail/news account
settings. Perhaps a button in the mail/news general preferences
 [Account Settings]
to launch the mail/news settings?

Comment 7

[Aaron Lawrence]

Isn't this a dupe of <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=40712">40712</a> which says
there should be mail/news settings in all Edit menus?

Comment 8

[Andy Lyttle]

Hmm, yep, although...  the idea of putting a button in Preferences to open
Account Settings is a good idea too, if that one gets wontfix'd.

Comment 9

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

mass re-assign.

Comment 10

[Stefan Borggraefe]

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

Comment 11

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420