66827 - "Character Coding..." menuitem should be context sensitive in function and appearance

Status: VERIFIED INVALID

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Håkan Waara]

"Folder Character Coding..." in the View menu doesn't make any sense. It does
exactly the same as "Folder Properties..." except that it opens said dialog with
another tab open.

This is just confusing, we should probably remove it altogether.

Objections?

Comment 1

[jglick]

I agree, I brought that up in bug 65018. But I think the international folks 
feel strongly the other way.

Comment 2

[Håkan Waara]

Why would they? It's still a view menu. And it is still available via
Edit->Folder Properties...

Comment 3

[jglick]

I agree that it is redundant.

cc'ing nhotta
nhotta wrote:
> I think having folder charset UI close to charset menu make it easier to be
> discovered by the users who care about charset.
> We can have folder charset items in folder property but we can also keep the
> current UI.

Comment 4

[Jesse Ruderman]

What does the "Character Coding" submenu do if "Folder Character Coding..." 
lets you change the character coding for the chosen folder?

Comment 5

[Matthew T (active 1999-2002)]

It just changes the encoding used to interpret the current message (as opposed to 
the default encoding for the entire folder).

Comment 6

[Jesse Ruderman]

Ok, so should that menu be called "Message character coding" instead of just 
"character coding"?  From the current name it's not clear that it applies to 
one message instead of, say, all messages.

Comment 7

[timeless]

if it's in the view menu, then although it doesn't really make sense because we 
mess up the metaphor it means it's for the current document, just like zoom.

Unfortunately we also have things like sidebar and toolbars, but even they are 
really for _their_ current document [the xul window] (although they support 
persisting). it might even make sense to persist an individual message's 
character set in the same way that we persist a folder character set or a 
window's sidebar state.

Comment 8

[nhottanscp]

cc to momoi

Comment 9

[Katsuhiko Momoi]

1. The basic meaning of the Character Coding menu item change
   is that it re-interprets the current doc/msg with the chosen
   encoding. I think the user will see this intuitively after using
   it a few times. I don't think you will improve on it by
   calling it Message Character Coding.

2. As for the Character Coding folder property menu under the View menu,
   is it really confusing or just redundant? 
   I don't think it is confusing. The user will see it just for
   what it is, i.e. a way to get to the same thing from another
   menu. For discoverability, this isn't such a bad idea. 
   On the other hand, it is redundant for sure. 
   Is redundancy of this kind bad in itself? 

   Our thought was that users who use the Character Coding 
   menu are the very people who can benefit from this new
   functionality associated with the folder properties dialog.

3. Aside from the question in 2, I think we should provide 
   a short explanatory note in all of our Character Coding 
   related dialogs, e.g. Folder Properties and Customize dialogs.
   Not having such explanation makes it harder for average 
   users to understand what they do.

Comment 10

[Håkan Waara]

You need to file a new bug for #3, that I know.

Comment 11

[jglick]

Unless the international folks have strong objections, I think we should remove 
the duplicate menu item, since they both bring up the same dialog. The name of 
the menu item should match the name of the window/dialog it opens, which the 
"Properties" (soon to be "Folder Properties") menu item does.

Comment 12

[Håkan Waara]

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

Comment 13

[jglick]

Nominate for nsbeta1.

The menu item, "View --> Folder Character Coding" should be removed now that bug 
32714 (Create a UI for Folder Charset)and 65018 (move the folder override ui 
into the folder properties dialog) have been fixed.  The menu item "Edit --> 
Properties (soon to be "Folder Properties")" brings up the exact same dialog. It 
is redundant to have two menu items that open the same dialog.

Comment 14

[Håkan Waara]

Attachment: fix v1

Comment 15

[Håkan Waara]

Please r= and sr= the attached fix.

Comment 16

[Katsuhiko Momoi]

Jennifer you have never addressed the issue of 
disoverability of this folder property dialog.
Are you in principle eliminating any duplicated
menu items?

How about "Apply Theme"? which can be accessed through
a menu and a Pref dialog? Are we eliminating that, too?

Comment 17

[Doron Rosenberg (IBM)]

r=doron for the patch

Comment 18

[Håkan Waara]

Stealing this bug from sspitzer..

Comment 19

[jglick]

Katsuhiko, if you feel access to this item should be duplicated in more than one 
menu, please lets discuss your rational.  Do you have reason to doubt users will 
be unable to find this functionality if is not in both menus?

My personal though is that our menus are already cluttered and different menu 
items which provide access to the same dialogs are not necessary.  The name of 
the menu item should match the name of the dialog it opens.  Edit --> Properties 
(soon to be "Folder Properties) opens the Properties dialog (soon to be Folder 
Properties).  View --> Folder Character Coding opens the Properties dialog also, 
not the Folder Character Coding dialog.  Folder Character Coding is PART of the 
folder properties dialog.

As for themes, the View menu provides a way to quickly switch themes, while the 
themes pref provides additional functionality that the menu item does not allow, 
such as previewing themes and removing themes.  Accessing the Folder Properties 
dialog from the View menu does not provide any additional functionality that 
accessing the Folder Properties dialog from the Edit menu does not already 
provide.

What are other's thoughts on this one?  If others disagree, please speak up.

Comment 20

[Katsuhiko Momoi]

> As for themes, the View menu provides a way to 
> quickly switch themes, while the themes pref 
> provides additional functionality that the menu 
> item does not allow, such as previewing themes and 
> removing themes.  Accessing the Folder Properties 
> dialog from the View menu does not provide any 
> additional functionality that accessing the Folder 
> Properties dialog from the Edit menu does not 
> already provide.

You're correct about not adding any new functionality via
View | Folder Character Coding menu item. However,
as I aurgued above, this is the first place users will
come for Character Coding related items, not to 
Edit | Folder Properties. In that sense, the current 
placement adds to the discoverability of this folder prop item.

In a sense, the real solution is to have an itegrated 
international UI dialog which gathers together all
internaitonal dilaogs/prefs scattered over several
different dialogs. Hopefully, we can do that in a future
milestone. 

As to "Apply Theme", "Apply Theme | Theme Preferences"
is actually redundant by the standadrds we are 
using here. I know why it's there, however, -- dicoverability.

Comment 21

[jglick]

>In a sense, the real solution is to have an itegrated 
>international UI dialog which gathers together all
>internaitonal dilaogs/prefs scattered over several
>different dialogs. Hopefully, we can do that in a future milestone. 

This sounds like a potentially really nice solution.

Comment 22

[Håkan Waara]

>In a sense, the real solution is to have an itegrated 
>international UI dialog which gathers together all
>internaitonal dilaogs/prefs scattered over several
>different dialogs. Hopefully, we can do that in a future milestone. 

Sounds good. But since this isn't done yet, can we remove the menuitem since
it's redundant and duplicated?  This new International UI dialog is a different
problem/solution. And I doubt it will get implemented any time soon...

Comment 23

[nhottanscp]

This is a folder level setting so it should stay in the folder property dialog.
It cannot be put together with other global international pref items.

Comment 24

[Katsuhiko Momoi]

As I have been saying, redundancy is not the only
criterion we should use in deciding the fate of a menu
item.
Let's consider, for example, why "Apply Theme | Theme Preference"
menu item exists in the Browser menu. Major reasons in my mind
are:

1. Theme is a new concept not found in earlier versions of browsers.
2. By having theme related item under View | Apply Theme, users
   will more easily discover this pref item. 
3. It also gives the user the info on what theme is currently in use
   quickly by going to this menu rather than opening Edit | Prefs
   dialog first and then choosing Appearance, and then Theme.

These are actually good reasons for providing what appears to be
a redundant item. From the usability point of view, it is
kinder to users.

The same consideration can be applied to View | Fodler Character 
Coding menu.

1. Folder character coding setting is a relatively unknown
   feature. It is hard to discover for most users because
   they don't normally associate charset to folders.
2. Yet, by placing this menu in the same area as "View |
   Character Coding" menu, the users who need this info 
   most are introduced to this item in a much more
   intuitive way.
3. The users who go to the Character Coding menu area are 
   interested in learning what Character coding the current
   folder has. That is immediately provided when you
   choose this item. In order to edit the choice for
   Character Coding setting for each folder, you must first
   know what the current value is. View | Folder Character
   Coding menu offers this quickly rather than making you 
   go through, Edit | Folder Properties | Character Coding.

   I am saying that the folder properties dialog actually has
   2 purposes, first to provide the current setting info, and
   second, to give the user an option to change that value.
   

These are the reasons why I object to the proposed fix. 
Just because you have a code for fix does not mean we have to
take it. It is more important to understand why from a usability
point of view this item helps the users.

No one has offered any convincing reason why *all* redundancies must
be eliminated. Surely such a position is untenable anyway. Some
built-in redundancy is good for usabiliy and I offer above the 
reasons why.

We should mark this bug as Wontfix.

Comment 25

[jglick]

What about at least moving "Folder Character Coding" into the "View --> 
Character Coding" flyout menu so we don't have 
View --> Folder Character Coding
         Character Coding

Comment 26

[timeless]

Couldn't we be clever and change the character coding menu to affect folders 
when folders are selected and messages when messages are selected?
</soapbox></invalidxml>

Comment 27

[german]

I think this current approach is not usable as you are putting the burden on the
user to figure out which item applies to what. To the uninitiated (and who isn't
if they are using Netscape 6), an intimidating 3 items in the mail menu all kind
of do related things. There is Edit|Properties, View|Folder Character Coding...
(which BTW is nearly incomprehensible english) and View|Character Coding.... The
latter should be renamed to make clear it applies to a message only if thats
whats intentded.

At the very least we should implement timeless' idea of being context sensitive
and only have one of the two items 'View|Folder Character Coding...' and
'View|Message Character Coding...' should be visible at any one time, based on
whether a folder or message(s) are selected.

Comment 28

[Katsuhiko Momoi]

> At the very least we should implement timeless' idea of 
> being context sensitive and only have one of the two items 
> 'View|Folder Character Coding...' and 'View|Message Character 
> Coding...' should be visible at any one time, based on
> whether a folder or message(s) are selected.

I like this idea of being context-sensitive also. 
Can we morph this bug into doing at least the context-sensitive
menu for Folder and per msg View Character Coding menu?
This way, the user will always have feedback on what encoding
a msg or the folder is using.

Comment 29

[Håkan Waara]

different bug - different owner. (Reassigning.)

Comment 30

[scottputterman]

marking nsbeta1-.  But...

I like the idea of removing the menuitem like hwaara's original patch does
because I also think it's redundant.  

Does Folder Character Coding need to be a toplevel menu?  Could it be buried in
the character coding submenu?  Regardless, it seems like Folder Properties
should be sufficient for this.

Comment 31

[jglick]

Is this bug still valid?

Comment 32

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

I've got a bug to remove this menu item.  assuming that other bug is still
valid, this bug will become invalid when the menu item goes away.

Comment 33

[jglick]

Marking bug invalid. Menu item no longer exists.

Comment 34

[[e-mail] (gone - use [e-mail] instead)]

I'm pretty sure this was the bug I fixed.

Verified.