Closed
Bug 66827
Opened 24 years ago
Closed 23 years ago
"Character Coding..." menuitem should be context sensitive in function and appearance
Categories
(SeaMonkey :: MailNews: Message Display, defect)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
VERIFIED
INVALID
Future
People
(Reporter: hwaara, Assigned: sspitzer)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
"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?
I agree, I brought that up in bug 65018. But I think the international folks
feel strongly the other way.
Reporter | ||
Comment 2•24 years ago
|
||
Why would they? It's still a view menu. And it is still available via
Edit->Folder Properties...
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•24 years ago
|
||
What does the "Character Coding" submenu do if "Folder Character Coding..."
lets you change the character coding for the chosen folder?
Comment 5•24 years ago
|
||
It just changes the encoding used to interpret the current message (as opposed to
the default encoding for the entire folder).
Comment 6•24 years ago
|
||
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.
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•24 years ago
|
||
cc to momoi
Comment 9•24 years ago
|
||
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.
Reporter | ||
Comment 10•24 years ago
|
||
You need to file a new bug for #3, that I know.
Comment 11•24 years ago
|
||
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.
Reporter | ||
Comment 12•24 years ago
|
||
*** Bug 71972 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
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.
Keywords: nsbeta1
Reporter | ||
Updated•24 years ago
|
Keywords: mozilla0.9
Summary: "Folder Character Coding..." shouldn't exist → "Folder Character Coding..." is redundant and shouldn't exist
Reporter | ||
Comment 14•24 years ago
|
||
Reporter | ||
Comment 15•24 years ago
|
||
Please r= and sr= the attached fix.
Comment 16•24 years ago
|
||
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•24 years ago
|
||
r=doron for the patch
Comment 19•24 years ago
|
||
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•24 years ago
|
||
> 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•24 years ago
|
||
>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.
Reporter | ||
Comment 22•24 years ago
|
||
>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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
> 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.
Summary: "Folder Character Coding..." is redundant and shouldn't exist → "Character Coding..." menuitem should be context sensitive in function and appearance
Reporter | ||
Comment 29•24 years ago
|
||
different bug - different owner. (Reassigning.)
Assignee: hwaara → sspitzer
Comment 30•24 years ago
|
||
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•24 years ago
|
||
Is this bug still valid?
Assignee | ||
Comment 32•24 years ago
|
||
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•23 years ago
|
||
Marking bug invalid. Menu item no longer exists.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
I'm pretty sure this was the bug I fixed.
Verified.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•