78338 - "Character Coding" in context menu in "Message" pane

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Prisacari Sergey]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.8.1+) Gecko/20010430

Currently the only way to change encoding of mail is to go view->character
coding. When reading mail more useful is to use context menu for it.

Comment 1

[Alexey Chernyak]

Marking NEW

Comment 2

[esther]

assigning QA to nbaca, she probably has this in one of her Context bugs already.

Comment 3

[Ninoschka Baca]

According to the Three Pane Mail Menus spec, Context Menu: Message Body section
it does not list "Character Coding" as a context menu item
(http://mozilla.org/mailnews/specs/threepane/MailMenus.html#Context). I also do
not see this in 4.7. 

jglick: I know it was decided that only the most common functions would be
available in the context menu. I don't know how often Character Coding is used.

Comment 4

[jglick]

I would like to see context menus kept to a small subset of the most frequently 
used menu items. Obviously all menu items can't/shouldn't be duplicated in the 
context menus.  

I'm open to feedback regarding how frequently this item is used.

Comment 5

[Matthew T (active 1999-2002)]

A context menu can appear (modulo a bug in XP Toolkit) in any one of four 
possible places relative to the original position of the cursor, depending on 
the size of the context menu and how close the cursor is to each edge of the 
screen:
*   to the southeast (the default)
*   to the southwest (if there's not enough room to the right of the cursor)
*   to the northeast (if there's not enough room below the cursor)
*   to the northwest (if there's not enough room below *or* to the right of
    the cursor).

For the same reason, if your context menu has a submenu, the submenu can appear 
in any of 4 * 4 = 16 possible places relative to the original position of the 
cursor. And if that submenu itself has a submenu -- as the main-menu encoding 
menu structure currently does -- then the third-level context menu can appear 
in any of 4 * 4 * 4 = 64 possible places relative to the original position of 
the cursor.

This extreme variability in position makes the quick muscle memory, which 
context menus are predicated on in the first place, basically useless. It's 
much quicker just to go to the relevant main menu item instead, rather than 
using the context menu.

For this reason, context menus should never contain submenus. So *if* encoding 
selection is included in the message pane UI, I think it needs to be a simple
`Encoding ...' item which brings up the dialog described in bug 10999.

Comment 6

[Prisacari Sergey]

Usually I need to work with last used codings, which appear in first submenu.
For me it's the most frequently used feature after "save as...".

Comment 7

[Jacek Piskozub]

Generally this setting is very useful in countries that have more than one
national character coding (Russia, China, some Central European countries, etc.)
At least some localized versions of Mozilla should have this enhancement.

Comment 8

[marlon bishop]

>------- Additional Comment #5 From Matthew Thomas (mpt) 2001-05-03 10:33 ---
>
>A context menu can appear (modulo a bug in XP Toolkit) in any one of four
>possible places relative to the original position of the cursor, depending on
>the size of the context menu and how close the cursor is to each edge of the
>screen:
>* to the southeast (the default)
>* to the southwest (if there's not enough room to the right of the cursor)
>* to the northeast (if there's not enough room below the cursor)
>* to the northwest (if there's not enough room below *or* to the right of
>the cursor).
>
>For the same reason, if your context menu has a submenu, the submenu can appear
>in any of 4 * 4 = 16 possible places relative to the original position of the
>cursor. And if that submenu itself has a submenu -- as the main-menu encoding
>menu structure currently does -- then the third-level context menu can appear
>in any of 4 * 4 * 4 = 64 possible places relative to the original position of
>the cursor.
>
>This extreme variability in position makes the quick muscle memory, which
>context menus are predicated on in the first place, basically useless. It's
>much quicker just to go to the relevant main menu item instead, rather than
>using the context menu.
>
>For this reason, context menus should never contain submenus. So *if* encoding
>selection is included in the message pane UI, I think it needs to be a simple
>`Encoding ...' item which brings up the dialog described in bug 10999.>


as much as this premise might be valid, the conclusion you have drawn is
impractical and too absolute. In a world where all context clicking took place
in the 1/8th screen, lower right quadrant, we might have a problem. But i think
for most situations, submenus kept to a minimum are fine. A more realistic
conclusion might be to say something like - never place tier 1 or tier 2,
muscle-memory dependent tasks in a submenu. But to make the statement that no
product should ever use submenus would be quite obtuse.

there are many variables to consider of course - screen realestate, system font
size, and others... the lower-right 1/8th quadrant, and to a lesser degree, the
right 1/8th section of the screen, to which your idea mostly applies, is
considered the least valuable in terms of information or web page design.
Therefore I don't think we should dictate such absolute rules when the
conditions under which they apply are uncommon. the purpose of submenus is to
bury infrequent items, this supposes that muscle memory *would not even be
built*, in order to be relied upon.

i have posted the 2nd draft to the Context Menu Revision 2 document located:

http://mozilla.org/projects/ui/communicator/framework/contextmenus/cmrev2-2.html

Comment 9

[Arkady Sherman]

Character Coding context menu item not only for mail messages is needed. It is
also usefull for webpages, especialy it is necessary for pages containing no
menu and tollbars, there is no way now to change coding for that pages.

Comment 10

[Olga]

I changed QA contact from nbaca to olgam.

Comment 11

[Mike Cowperthwaite]

xref bug 70830

Comment 12

[Tony Mechelynck [:tonymec]]

No significant action in 6½ years. The bug this depends on was FIXED in 2002. WONTFIX?