Open Bug 57578 Opened 24 years ago Updated 3 years ago

Left clicking on an email address in Mail shouldn't show a context menu

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

User Story

What do the others do?
--------------------------
Knowing what others do wih leftclick on email address in email might help to decide wht optimum would be for SM
1. GMAIL (in SM Browser):  Opens Composer dialog for new email to that email address
2. **Thunderbird**: like  in SM leftclick on email address opens Composer window for new email to clicked address
Steps to Reproduce:

(1) Open MailNews
(2) Click on a message
(3) Left click on an email address in the message header

Result: The same context menu appears that does when you right click, with 
items "Add Address to Address Book" and "Send Mail To".  I don't think this is 
right.  Left clicking should do the default action, in this case probably "Send 
Mail To", and right clicking should give an extended list of possible actions 
(as it already does).  No need for the user to go through two clicks to 
complete the most likely action.  Matthew...?
this is working as designed. marking won't fix.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
a little more explanation. It was found in useability testing that nobody new 
you could right click and everyone expected to be able to left click to get a 
list of choices.
Really?  So how are they figuring out that they can right click on links in 
emails and in the browser?
And why don't they expect a context menu to appear when they left click on 
links anywhere, as you claim they do in this specific instance?  In this case, 
the email addresses are underlined in a link color so they look like links, are 
they not?  So shouldn't they act like links also?  If not, don't make them 
appear to be normal links.

Reopening because something smells of poorly conducted usability testing.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Blake, usability testing can only find problems -- you shouldn't blame it for 
coming up with bad solutions, because it's not the job of usability testing to 
find solutions (though it can be useful in comparing alternative solutions).

Also, usability testing tends to emphasize short-term and intra-user usability 
(which commercial software such as Netscape specializes in), rather than
long-term and inter-user usability (which non-commercial software such as Mozilla 
should specialize in, in theory). For example, the mere fact that it is
*possible* to compose a new message to someone, from clicking their address in 
the message pane, will tend to encourage some users to use that instead of 
clicking Reply. This will damage the threadedness of e-mail conversations, 
reducing long-term and inter-user usability of e-mail in general.

If users really `expected to be able to left click to get a list of choices', 
then there is an intuitive way to do that: make each address a pull-down menu 
which looks like a pull-down menu, rather than a quasi-context-menu which looks 
like a link and which noticably breaks platform conventions for menus on all 
platforms.

However, I suspect that `everyone expected to be able to left click to get a list 
of choices' is a mistaken extrapolation of `nobody [k]new you could right click' 
by the people carrying out the test, caused by asking leading questions of the 
test subjects. I would think that most users actually don't expect to get a menu 
of choices *at all* from an e-mail address in the message pane, but they tried a 
left click when provoked.

I would suggest the following.
* Clicking an address should open the Card Properties dialog for that address,
  with the `Ok' button changed to `Add' if the address is not already in any of
  the user's address books.
* There should be a `New Message ...' button in the Address Properties dialog.
  This, combined with the above, still allows the composition of a message to any
  address in a message, without breaking platform conventions, and greatly
  reducing the risk that users will use this button instead of the Reply
  button.
Your solution still requires two clicks to complete what I think is the 
expected action: a new compose window with the To textfield prefilled with the 
email address the user clicked on.  It still seems to me that if the user has 
learned anything from browsing the web and using various email clients, they'll 
think a blue (or whatever color), underlined email address screams "e-mail this 
address"
First off, I'll say I was too hasty to close this bug. It was a reaction from
having dealt with this problem in the past and being content with the current
solution. However, if someone can come up with a better solution than what
exists that we can all agree upon than I'm open to it.

Originally, we had it so that left click brought up the menu and right click did
nothing.

Myself and a bunch of others disagreed with this and made it so that left click
would mean send a message to that person and right click would be to bring up a
context menu.  This was actually my favorite implementation and the one that
made most sense to me. From reading the comments, I think Blake and I agree on
this.  It turned out that people didn't understand this.  Even though right
clicking on a link may be something that we do to bring up a list of choices, my
guess is that many users don't understand this. Also, clicking on an address in
the 4.x world meant add to the address book.  That never made sense to me
because if you click on an address in the browser it would bring up a compose
window. Regardless, some people were used to this functionality.

Anyway, when it became clear that people were missing the menu (and from a
Netscape point of view the menu matters because we also wanted to include
options for handling presence - and in case anyone wants to jump on something
relating to Netscape, one can easily imagine this kind of thing extending to the
whole mozilla community at some point) because it could only be brought up by
right clicking, we made it so that left clicking did the same thing.  Because of
this, more people became aware of the choices available to them.

I agree that there is probably a better way around this, but I don't know what
it is.  I would prefer not to do Matthew's idea for two reasons. The first is
that I believe that the link should bring up a compose window if it will only
bring up one thing. The second is that I think it's overkill to have a New Msg
button in the card properties.

Other suggestions are to not make the names look like links but instead like
buttons. I don't know. As I said, I am content with the way it is at the moment
because I don't think it is that big of a deal. But if you have suggestions as
to how to make this functionality better and more discoverable, keep adding to
this bug.
Hmm, ok. It seems as if we've started with a solution and gone looking for a 
problem here. The address looks like a link, therefore it must behave like other 
e-mail links in sending a message. But why does it look like a link in the first 
place? Making the address small, blue, and underlined makes it harder to read 
(not to mention the fact that it's inconsistent with my default link colors). 
Neither Eudora (5.0) nor Outlook Express (4.5) do anything special with addresses 
shown in message headers at all. And any time someone says `functionality', I 
hear alarm bells going off.

So. Should an address in a message header do anything? Yes. Just as clicking an 
http: link in a Web page displays more information on the subject of the link, so 
an address in an e-mail message header should display more information about the 
address. It should tell me who the person is, what organization they belong to, 
how many messages they have sent me in the past week/month/year, and so on. In 
other words, it should show me the Properties window for this address.

This behavior is not inconsistent with the behavior of mailto: links in a Web 
page; rather, it is the mailto: links which are inconsistent with *this* 
behavior. In a Web page we are extremely unlikely to know enough about the 
address to be able to show a useful Properties window, so we open a composition 
window instead. However, we can make the difference between the two types of link 
clear by (a) placing an address book card icon to the left of each address, as 
part of the link, and (b) not underlining the address (making it easier to read).

I cannot agree that composing a new message to an address in the message pane 
should even be an option, because (as I said before) it will lead users astray 
into using that when they should be using the Reply button, harming usability 
overall. As for a New Message button in the Properties window being overkill: I 
was going to suggest it anyway, before this bug appeared -- and I've just noticed 
that MS Entourage has such a button in its address book, too.
Many times, I want to start a new e-mail conversation, and start it by first 
finding an old message from them.  Why should I have to use reply and 
potentially confuse the recipient's mail client into thinking I'm continuing an 
old conversation?

Fwiw, I agree with making left-click (or double-click) bring up the address 
book information and changing the styling on the link.  I just don't want to be 
blocked from right-clicking and choosing "new message" (text from bug 32358 
rather than from the current context menu).

I'd also like to see the color under the address become a solid color in 
Windows classic.  That currently makes the addresses more hard to read than the 
underline does.
Product: Browser → Seamonkey
TB version is bug 245064 (which has a draft patch)
putterman's no longer on the project
Assignee: scottputterman → mail
Status: REOPENED → NEW
QA Contact: esther
Severity: normal → minor
User Story: (updated)
You need to log in before you can comment on or make changes to this bug.