Closed Bug 10999 Opened 25 years ago Closed 15 years ago

For choosing encoding, use submenu/dialog (not nested submenus)

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: don, Assigned: jag+mozilla)

References

(
URL
)

Details

(Keywords: intl) 

German,

Everybody on IRC tonight is bitching about the new "Character Set" submenu.
It's just too damn long.  I won't repeat the comments. :-)  Any chance we can
make this thing a dialog box?  Please?
Assignee: german → don
Yes it barely fits on 800*600 screens, let alone VGA sized ones.
I don't have any objections from a UE perspective, since I believe usability
will not be much affected since only a minority of users will switching this
very frequently, so yes go ahead, change the menu item to Character Set..., and
let this invoke a simple OK Cancel dialog with one list in there that displays
the, uhm, list of character sets that are selectable.
Whiteboard: need to find an owner for this ...
Target Milestone: M12
Move to M13.
Target Milestone: M13 → M15
Move to M15.
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Has this been fixed?
Whiteboard: need to find an owner for this ... → need to find an owner for this ... fixed?
Move to M16 for now ...
Target Milestone: M15 → M16
Note that the i18n folks are, as of less than two weeks ago
<http://mozilla.org/projects/intl/uidocs/editorcharmenu.html>, still operating 
under the assumption that this will be an elaborate system of submenus
<http://www.mozilla.org/projects/intl/uidocs/browsercharmenu.html>.

It seems fairly simple to me -- make a single submenu consisting of:
* an `Auto-Detect (xyz)' item, where xyz is the currently selected auto-detect
  module;
* a separator;
* the four most recently used character encodings, in order of recency;
* a separator;
* an `Other ...' item to bring up a dialog which lets you choose (a) the current
  encoding and (b) your preferred auto-detect module.

I think that would cater for all users except those who frequently used more than 
four encodings (a vanishingly small number of people), and would do so without 
resorting to horribly long menus or nested submenus.

Reassigning for Don
Assignee: don → ben
Target Milestone: M16 → M18
Move to M21 target milestone.
Target Milestone: M18 → M21
mpt, your suggestion looks good to me. 

I can do the dialog, and probably cobble something together that flushes 
the most recent suggestions to localstore. 

cc'ing tao.
Status: NEW → ASSIGNED
The dialog should be non-modal -- if I click on an encoding in the dialog, the 
page behind should change immediately so I can see that it's the right one.

Design coming shortly ...

Ok, ignore that bit about being non-modal. The dialog should be window-modal ...

* There are far, far more documents on the Web which refer to `character
  encoding' than which refer to `character coding'. W3C documentation also talks
  about `character encodings', not `character codings'. I suggest the menu item
  be renamed, from the current `Character Coding', to either `Text Encoding' (as
  used in Aphrodite) or `Character Encoding'. `Text Encoding' sacrifices a little
  bit of precision for greater obviousness -- but maybe if you're the sort of
  user who needs to use this feature, you know what a `character encoding' is
  anyway, so extra obviousness is not required.

* The auto-detect modules should be divided into those which auto-detect
  encodings used for one language (e.g. Japanese), and those which auto-detect
  encodings used for multiple languages (e.g. `East Asian'). Those which detect
  encodings for multiple languages should get `Detection module' treatment; but
  those which detect encodings for one language should go in the encoding list
  itself, because that's where you're more likely to look for something which
  handles (for example) Japanese.

* IE 5 also has menu items for specifying whether the document is a left-to-right
  one or a right-to-left one. Does Mozilla support this? If so, it should be in
  the submenu too.

Thus ...
                   _________________________________
Te_xt Encoding  > |/ _Auto-detect (East Asian)      |
                  |---------------------------------|
                  |* _Western (ISO-8859-1)          |
                  |  Central _European (ISO-8859-2) |
                  |  _Japanese (Auto-detect)        |
                  |  _Chinese (Simplified)          |
                  |---------------------------------|
                  |  _Other ...                     |
                  |---------------------------------|
                  |* _Left to Right                 |
                  |  _Right to Left                 |
                  `"""""""""""""""""""""""""""""""""'

+---------------------------------------------------+
|[] Text Encoding ::::::::::::::::::::::::::::::::::|
+---------------------------------------------------+
|                                                   |
| [/] _Auto-detect the encoding where possible      |
|     _Detection module: [East Asian            :^] |
|                                                   |
| Otherwise, use this encoding:                     |
| +---------------------------------------------+-+ |
| |(*) Western (ISO-8859-1)                     |A| |
| |( ) Armenian (ARMSCII-8)                     |:| |
| |( ) Baltic (ISO-8859-4)                      |:| |
| |( ) Cyrillic (Auto-detect)                   |:| |
| |( ) Cyrillic (ISO-8859-5)                    |:| |
| |( ) Cyrillic (KOI8-R)                        |:| |
| |( ) Cyrillic (Windows-1251)                  |:| |
| |( ) Cyrillic (ISO-IR-111)                    |V| |
| +---------------------------------------------+-+ |
| Direction: ( ) _left to right ( ) _right to left  |
|  _                                                |
| (i) These settings will be used until you visit a |
|     document with a specified encoding which is   |
|     different from that of the current document.  |
+---------------------------------------------------+

Notes:

* If the `Detection module:' popup menu is changed, the `Auto-detect the encoding
  where possible' checkbox is automatically checked.

* Western (ISO-8859-1) is listed first (yeah, I know, I know, linguistic
  neo-imperialism), then the rest of the encodings are listed in alphabetical
  order by writing system. Within each writing system, any auto-detection module
  for that writing system is listed first, followed by the encodings for that
  writing system in alphabetical order.

* It might even be worth having two columns in the list, one for `Writing system'
  and one for `Encoding name' -- so if the user knew that the page was supposed
  to be ISO-IR-111 but didn't know what writing system that was supposed to be,
  they could click on the `Encoding name' header to sort the list and find the
  encoding easily.

* Look Ma, no Ok/Cancel buttons! This dialog is window-modal, and any change made
  is reflected immediately in the document (so I can tell if I've chosen the
  right encoding). When I've selected the desired encoding, I close the dialog.
  That's why the tree has radio buttons, rather than just being an ordinary tree:
  so I can scroll through the list with the keyboard, without giving the document
  reflow convulsions. (When using the keyboard, I select one of the encodings
  using the Space bar, just like I would for any other radio button.)

* Settings made either in the menu or in the dialog should be specific to that
  window -- so I can be browsing in Cyrillic in one window and in Japanese in
  another, without having to constantly change my encoding each time I follow a
  link in the other window. Any new blank window should inherit the settings of
  the most-recently-changed window (except where bug 22788 has effect).

* I don't know what happens if the document actually specifies the correct
  encoding All By Itself. How does that interact with these settings? Tao, please
  enlighten me.
URL: http://www.w3.org/TR/REC-html40/chars...
Whiteboard: need to find an owner for this ... fixed?
My suggestion:
- have a configuration dialog where the user can configure the char-codings shown
  in the menu.
- the default menu would have a small selection of these and a Customize...
  choice that would display a dialog.
- if all character codings are removed, the "Character Coding" menu would
  disappear altogether. (An ideal situation, because the charset should be set
  correctly by the page)

This would work for navigator and editor (use UTF8 by default).

For mail/news, it would probably need a per-folder/newsgroup preference charset.
> have a configuration dialog where the user can configure the char-codings shown
> in the menu.

That seems to me to make about as much sense as having a dialog where the user 
can specify which files are shown in the `Recent Files' menu.

The purpose of the menu should be to provide quick access to the set of 
{encodings which the user is most likely to want to use in the near future}. The 
set of {encodings which the user used in the recent past} is likely to be such a 
good approximation to that, that having an extra dialog would be overkill.

I agree with mpt; it should work similar to the 'Recent Files' list.
Timeless, this should make your day.

Move this to "Future" milestone.  And let's see if we can really fix this for 6.x.
Target Milestone: M21 → Future
I want to implement this for 1.0/6.5.
I think I may have been confused by the comments in bug 33337 (and by the topmost 
item in IE's Encoding menu) into thinking that some sort of global auto-detection 
module was possible -- but after some experience using IE's Encoding menu, I 
think its `Auto-detect' item just means use the encoding that was indicated by 
the HTTP headers or the META elements in the Web page.

If so, the submenu would be unchanged, but the top of the dialog would be as 
follows:
+-------------------------------------------------+
|[] Text Encoding ::::::::::::::::::::::::::::::::|
+-------------------------------------------------+
|                                                 |
| (*) _Auto-detect (use the encoding specified by |
|     the document)                               |
|                                                 |
| ( ) Use a different _encoding                   |
|     +---+-----------------+-----------------+-+ |
|     |   |Writing system   |Name             | | |
|     +---+-----------------+-----------------+-+ |
|     |(*):Western          :ISO-8859-1       |A| |
|     |( ):Armenian         :ARMSCII-8        |:| |

With a two-column tree, you could sort by whichever column you were using to find 
the encoding (with the proviso that ISO-8859-1 would always be first).

Tao (or Frank), I need the answers to these three questions:
1.  Is my (current) understanding of auto-detect options correct -- that there is
    no such thing as a global encoding auto-detection module, but various
    auto-detection modules just differentiate between various encodings of the
    same writing system?
2.  Is `Writing system' the correct terminology for the group of related
    encodings? (IIRC, IE uses `Language family', and people don't like that
    because it's wrong, but I can't remember which terminology is right.)
3.  Is the blurb I wrote at the bottom of my design -- `These settings will be
    used until you visit a document with an encoding which is different from that
    of the current document' -- correct, and if not why not?

Thanks ...
Summary: The new "Character Set" submenu is too damn long → For choosing encoding, use submenu/dialog (not nested submenus)
Ok, let's try Momoi. Could you please answer the questions in my 2000-10-15 
comment, and note anything else which looks wrong with the spec, so I can revise 
it if necessary? Thanks.

Matthew, I will review your proposal. As you probably
know, I wrote the character coding menu proposal which is
in the current code base.
Whe I published the spec, I did ask widely for comments.
I did receive several comments and incorporated into the
current spec.

The menu you saw in M13 and other milestones was
necessitated by the fact that the menu was not scrollable
at that time. Mechanics of the menu and how they match
up with the backend have been spelled out. I don't think it
will be easy to re-design this without the help of
cata who did the backend work for us. The work was non-trivial
and involved many other issues.

What we have as of now is close to what we wanted in the final
spec. 
Ben, please do not make any changes to this area UI area
without thorough discussion with us working in in the i18n area.
We have currently what I consider to be fairly good and working
charset menu. I will be happy to engage in any discussions
you would like. But we spent a lot of time designing this
for the convenience of international users based on our
experience with Navigator 1, 2, 3, and Communicator 4.x.
The current menu is quite short and distinguishes
"encoding" items from "auto-detect" modules because
they are qualitatively 2 diffferent things. The IE 4/5 menu
is confused in this respect and not something to be emulated.

As to the Character Coding menu vs other namijg of this item,
we had a long stretch of discussion on the net and agreed to
this naming among the i18n newsgroup. From our long
exposure to this naming issue, we know that no name is
perfect for this item, there are pros and cons for this or
that name. The term "encoding" is not without controversy.
If you are interested, please look at the thread on this
topic in the i18n newsgroup.
I would not change it without another consensus.

I will try to answer the questions raised by Matthew below:

> 1.  Is my (current) understanding of auto-detect options
>      correct -- that there is no such thing as a global
>      encoding auto-detection module, but various auto-detection
>      modules just differentiate between various encodings of the
>      same writing system?

It is possible to have global encoding detection module.
In fact we have one in Netscape 6 (but not in Mozilla because
the technology is proprietary). But there is nothing in
principle which prevents good engineers from coming up
with a universal auto-detection module to be put into
Mozilla. It's just a lot of work and you need to
understand both encoding and language characteristics
issues (some amount of phological and morphological
constraints need to be built into the detector for
best resuots) well to devise a good one.

What these auto-detect modules can detect is a matter of
what the target range is. An auto-detection module is
designed to determine what encoding is used for the set
of data you are receiving into the layout. A universal
auto-detector tries to detect most major European and
Asian encodings. East Asian tries to detect among many
encodings used for Chinese, Korean, and Japanese.
Japanese auto-detect module tries to detect among
3 prevalent encodings used for Japanese on the
Internet today. Korean auto-detection is much more
limited and tries to detect EUC-KR or ISO-2022-JP.

As Frank designed it, some of them also routinely detect
some Unicode encodings like UTF-8, UTF-16, UCS-2.

So auto-detection modules can narrow down the possible
range of encodings they are trying to detect and the narrower
the range, the more successful the efforts will be.

Auto-detection has nothing to do with HTTP or Meta charset.
It is used as a way to detect the (en)coding of data that
are not marked by HTTP or Meta charset.

Each encoding item like Japanese (Shift_JIS) presents
the user a way to mark the encoding of the document
in case HTTP, Meta-charset or Auto-detection does not
provide satisfactory results.

> 2.  Is `Writing system' the correct terminology for the
>     group of relate encodings? (IIRC, IE uses `Language
>     family', and people don't like that because it's wrong,
>     but I can't remember which terminology is right.)

No, the writing system is not the correct term. The only
way to relate some encodings is to say that these encodings
encode certain set of characters or charset tables used
in language X or languages A, B, C, etc.

> 3.  Is the blurb I wrote at the bottom of my design --
>     `These settings will be used until you visit a document
>     with an encoding which is different from that of the
>     current document' -- correct, and if not why not?

I think you should look at our backend logic as described in this
spec document. Almost all the questions you raise here
have been described or explained in:

http://www.mozilla.org/projects/intl/uidocs/browsercharmenu.html

The UI for Character Coding menu of the very current build is
finally very close to what has been proposed in this document.
(BTW, I need to make a few modifications to this document to
  clarify what we did in M18 and later builds.)

Matthew, we have arrived at the current stage overcoming
a number of techonlogical limitations. We spent many hours on
front end, backend specs, a large number of hours testing the
menu. Looking at how the charset menu works a siginificant
part of international testing work.
The menu has received many hours of scrutiny by people
who have i18n specialty. At this point, I am not inclined to
agree to major changes unless you have cogent reasons and
show us evidence that you understand i18n considerations
that went into the current design.

I have 2 main principles for the final spec of the
menu:

1. The menu should be short at the top tier because average
    users should not be presented with coding menu details
   In Netscape PR3 and 6.0, the menu area is finally short
   consisting of

   a. Sub menu for auto-detect moduels. For specific languages,
      localizers will set the default module.
   b. The sub menu list of all the individual (en)coding items
      available in Mozilla.
   c. The Customize menu for the static items which follow
      below the separator.
   d. The separator
   e. Static menu items (set by the Customize menu) ---
      customized by localizers for the locale also.
   f. Most recent 5 item Character coding item cache --
      follows the static menu without any separator.

We take care of most users' needs without them ever having to
engage the menu itself. Our testing so far indcates that this
is working as intended in many languages.

2. At the same time, we should offer flexibility in the
   2nd tier of menus to advanced users who would like to:

    a. Customise the static menu -- i.e. the items
       that are constantly available.
    b. See many encoding items covering many languages
       and character coding items.
===============================

The Browser Character coding menu specs have been out there
and have been discussed widely. That should be the starting
point. Anyone who is porposing major changes should
understand the specs there first.
I will be happy to engage in any discussions you desire.


One additional fact.
After some discussion,we decided to leave the "More ..."
sub menus with changes in names to match geo-linguistic
classifications fairly well-accepted in linguistic typology.
Thus you see West European, East European, East Asian,
SE & SW Asian, and Middle Eastern categories under
More... sub menu now.
We could have lumped all the coding items under More ....
The menu now can scroll. However, sub classifications
make it easier for international users to find their
character coding items. IE 4/5 on the other hand has an
alphabetical listing of encodings they support with
separators. We actually support many more encodings
than IE and after some consideration, we decided to
keep geo-linguistic sub-classifications to make it easier
for international users looking for their charsets.

Don's original complaint was that the sub menus are too long.
Well, they are no longer long. The top tier has been
simplified and complexity has been pushed back into
the 2nd tier, which most usres will not have to use.

It seems that we have corrected the problem as described by
don. 
cata did the current menu and this is an area owned by i18n.
I don't think this should be assigned to ben.
Re-assigning to cata for evaluation.
Assignee: ben → cata
Status: ASSIGNED → NEW
QA Contact: claudius → momoi
> The menu has received many hours of scrutiny by people who have i18n specialty.

Momoi, I think that's precisely the problem. The current UI may make perfect 
sense to those who are specialists in i18n, or who are familiar with `linguistic 
typology'. But it would make very little sense to the Japanese, Chinese, Korean, 
Russian, and Israeli customers who come into the Internet cafe where I work, who 
are not specialists in i18n, and for whom changing the encoding for Web pages is 
a frequent task. With the current UI, they would have to ask me for help much 
more often -- and I'd rather spend that time doing other things. :-)

I have read the spec. A number of UI mistakes are obvious in it, but the most 
glaring problem is that every single one of the people involved in the discussion 
appears to have been an i18n specialist, and no usability specialists were 
included. And despite repeated requests from Ben and myself for input from i18n 
people in this bug, none was received until now.

I have done as you requested, and started a thread in n.p.m.i18n -- `Making the 
encoding selection UI easier to use', listing the problems in the current UI and 
suggesting a solution.

Matthew, sinceyou started a newsgroup discussion thread,
we can discuss details there. But I would like to respond to
some points you raised above.

>> The menu has received many hours of scrutiny by people who have i18n 
specialty.

>Momoi, I think that's precisely the problem. The current UI may make perfect 
>sense to those who are specialists in i18n, or who are familiar with 
>`linguistic 
>typology'. But it would make very little sense to the Japanese, Chinese, 
>Korean, Russian, and Israeli customers who come into the Internet 
> cafe where I work,

One of the 2 major ideas we had was that we should target
a large majority of users who use Mozilla on their own
machine. The idea is to have all the critial defaults 
properly set. Browser display default charset, 
Mail display default charset, Mail send default charset,
plus the default set of Auto-detection and the list
of charset names always available regardless of the
cached status. 
These deafult setting have become all available by the 
end of M18. When the defaults are set, my estimate is
that the overwhelming majority of users will not
have to use anything other than the 1st tier of menu.
So far this expectation has been met, I believe. 

The sub-menus are ,eant for advanced users only. 
I realize that menu UI purists may not like it,
and may like to have a dialog instead. But for submenus
a vast majority of users will not use, what would be a
point of expending further energy to modify it? And does
it really serve the target users at all? I happen to be
one of tese power users, and for me using a dialog is
terrible. It is an extra step I don't want to take. 

Let's debate other specifics in the newsgroup.
This bug started out as a complaint to a long
non-scrollable menu. That was a problem attributable 
to another bug. Since this bug was filed, the character
coding menu has been improved to answer that initial 
problem. 
There is one more thing I would like to point out.
The spec for this menu was out there long before this bug
was filed. Yet as far as I can see, until very recently
this bug was copied to only one person in mentioned in
that spec document. 
It is good that you want to now open the discussion. I suspect
that in order to have true improvemnt, we need to balance
both UI needs and a variety of use factors for charcter coding
menus in different components. 

 
I forgot to add that the Internet cafe is not
a typical user environment. It is an environment
in which many different users the same machine
and therefore their needs are of special type. 
The considerations drawn from that experience
are nor necessarily valid for the main target users
of the UI under consideration. 
I have responded to Matthews posting in the newsgroups (UI, i18n, l10n). 
I have stated there reasons why his proposal should be rejected even though
we should open a few new bugs to address some of his concerns within the
current implementation. 
Frankly speaking, the charset menu is not trivial and involves many hours of testing.
There is more than just meets the eye in the UI. Matthew's proposal is based on
essentially incorrect understanding of how these menu items work. We can keep
on discussing this, but I think it might be a waste of time. I have to honestly tell
you that while I respect many things Matthew has done in other UI areas, i18n is one
area he needs a lot more seasoning, real user experince and reserach than he has
shown so far. We have many more things to do to improve international users 
experience in areas other than the menu for the next release. Having a stable
 menu UI is the corner stone of our testing work. 
For these reason, I suggest that we now close this bug and deal with individual 
issues as incremental improvements within the current implementation framework.

> Frankly speaking, the charset menu is not trivial and involves many hours of
> testing. There is more than just meets the eye in the UI.

Exactly. That's the problem.

>...
> I have to honestly tell you that while I respect many things Matthew has done
> in other UI areas, i18n is one area he needs a lot more seasoning, real user
> experince and reserach than he has shown so far.

I have to honestly tell you that while I respect many things Katsuhiko has done 
in other i18n areas, user interface design is one area he needs a lot more 
seasoning, etc etc etc.

>                                                  We have many more things to do
> to improve international users experience in areas other than the menu

That's good, but I fail to see how it is relevant. Ben Goodger had already 
volunteered to do this. If your own i18n people are too busy to make such a 
badly-needed change to the UI, then reassigning the bug to one of them was highly 
misguided.

>                                                                        for the
> next release. Having a stable menu UI is the corner stone of our testing work.

It is *months* before the first release of Seamonkey is due. If you require a UI 
freeze on anything this early in the beta cycle, whether for testing or for 
anything else, you should discuss it with drivers@mozilla.org and such a freeze 
should be announced in n.p.m.seamonkey.

> For these reason, I suggest that we now close this bug and deal with individual
> issues as incremental improvements within the current implementation framework.

If you want a discussion in the newsgroup, then have a discussion in the 
newsgroup, rather than filling this bug with dozens of comments. Please don't 
just pretend you want a discussion, and then try to close the bug less than 24 
hours after the discussion began. Thanks.

I think more i18n people shuld look at this issue
from a resource point of view. Let's wait till teh discussions
run their course. In the meantime, I want to ask the 
ftang and msanz to also join in the process as anything done
in this area will impact them also.
For now I send this bug to ftang. He may talk with Ben to see
what they can do.
Assignee: cata → ftang
I object. And since I have no standing I'll put my comments here.  Decisions 
should always be stated in a bug. They should always be copied to the people 
who monitor the bugs. That's why bugs exist. I am sorry if the i18n people did 
not know about this bug, that's partly mpt's fault, that's partly their own.

Personally I like the current implementation, but if you ever choose to make a 
change to this menu I expect to be able to find out about it by being notified 
in this bug.

Any conclusions drawn in the newsgroups should be entered here for those of us 
who don't have the time to read the newsgroups.

wrt current proposals:
mpt <2000-04-13 03:47>
In your internet cafe, assuming you have 10 different nationalities that 
frequent (and I'll name them): Spanish, French, Italian, German, Russian, 
Israeli (Hebrew), Portuguese, Saudi Arabian (Arabic), Japanese, Chinese. Your 
frequent menu will frequently fail [I'd estimate >1/2]

mpt <2000-07-06 07:21>
The dialog "[] Text Encoding" is very ill conceived.
Whatever arrangement is selected needs to be treelike [either cascading menus 
or a normal tree widget]

-Cyrillic
 *Auto Detect
 .ISO-8859-5
 ...

Mortals have no clue [or should have no idea] what a codepage is. Hiding stuff 
in a dialog is no excuse for making it impossible to use.

Not all window managers give dialogs a close button. You must have either an ok 
or a close button.

wrt using radio buttons to make a change live, that's stupid.
A. We should be able to use radio buttons in trees.
B. Trees make sense and there might be nothing wrong with selecting each of a 
selection of cycrilic code pages. with a keyboard in your scheme I press C 
<space> <down> <space> <down> <space> ... that's silly.

Instead in live (and this is a design decission that should be considered, not 
discarded instantly) the browser makes a quick check: Does the page fit the 
charset. If not, it gives a non dialog warning (maybe it grays or italicizes 
the codepage) if the user still wants it, they click ok or apply+close.
Assuming the page fits the codepage the browser then flows it.  If i'm hunting 
through various cyrillic charsets it is quite likely that i'll have to try a 
few, and there's no reason for the browser not to do the page generation.

A lot of your design decisions are based on an old conception that reflows are 
very expensive. While this may have been true at some point, and is probably 
true to a lesser extent now, UI should NOT be dictated by such things.  Try it 
[in a legitimate] test environment, if the users can't stand it then do 
something else.

Any new windows might want to inherit the codepage. Someone should make this 
decision. When they do I would like to be cc on that bug.

WRT writing style, um. I have no idea.  Maybe we should go for a wizard 
<everyone loves to hate wizards>.  How might someone search for a character 
set? By: Country, Language, UNICODE codepage, Windows codepage, Mac codepage, 
region. Maybe they'll want to do it by phone number ;?

Asuming writing style is things like Latin, Cyrillic, Aribic, Indian, Hebrew, 
Kanji, .. then I guess you might do that too.

I think what you might want is one dialog for changing lots of things, not just 
direction and encoding language. We also occasionally support IMEs, so if you 
intend to make a dialog it should also allow the user to select their IME.

mkaply: if ibm has any people concerned about this menu or any issues raised 
here, this is the bug.
> Any conclusions drawn in the newsgroups should be entered here for those of us
> who don't have the time to read the newsgroups.

Nobody is suggesting otherwise.

> Your frequent menu will frequently fail [I'd estimate >1/2]

It won't `fail'. No matter how the first-level submenu is implemented, customers 
will often have to go beyond that submenu anyway, in order to select the 
appropriate auto-detection module or (if no auto-detection module for their 
language is available) the appropriate individual encoding. My proposal is that a 
dialog is the best way of doing this.

> Whatever arrangement is selected needs to be treelike [either cascading menus
> or a normal tree widget]

I considered that, but rejected it on the grounds that it would hide too much for 
too little benefit, and at the expense of requiring more mouse clicks.

> Not all window managers give dialogs a close button. You must have either an ok
> or a close button.

That was a mistake which I corrected in my posting to the newsgroup.

> wrt using radio buttons to make a change live, that's stupid.
> A. We should be able to use radio buttons in trees.

There is no obvious connection between your assertion and your argument.

> Instead in live (and this is a design decission that should be considered, not
> discarded instantly) the browser makes a quick check: Does the page fit the
> charset.

There is no way Mozilla can tell whether a page `fits' a character set or not.

> A lot of your design decisions are based on an old conception that reflows are
> very expensive.

They are, especially when using complex character sets such as those for Chinese 
kanji or Korean -- and especially when using the slower computers you would find 
in many of the countries where this UI needs to be used frequently.

> I think what you might want is one dialog for changing lots of things, not just
> direction and encoding language. We also occasionally support IMEs, so if you
> intend to make a dialog it should also allow the user to select their IME.

No. The UI for switching IMEs is already provided by the OS (in the system tray 
on Windows, and the Keyboard menu on Mac OS). Mozilla does not need to duplicate 
it.
Keywords: intl
CC'ing ylong. 
Mark as Future and P4 for now.
Status: NEW → ASSIGNED
Priority: P3 → P4
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: momoi → zach
mpt <2000-04-13 03:47>
mpt> In your internet cafe, assuming you have 10 different nationalities that 
mpt> frequent (and I'll name them): Spanish, French, Italian, German, Russian, 
mpt> Israeli (Hebrew), Portuguese, Saudi Arabian (Arabic), Japanese, Chinese.
mpt> Your frequent menu will frequently fail [I'd estimate >1/2]

The 50% failure is an over-estimate.  Most Spanish, French, Italian, German,
and Portuguese pages are usually encoded in the same charset, so in the
example you're more likely to have 6 charsets for these 10 languages.
(But in the worst case, because there are multiple charsets per language,
you could have more than 10 charset...)

If the browse pages are labeled, the "frequent menu" will automatically be
updated.  I assert that a large majority of non-Latin pages are labeled with
the correct charset.  So it is likely, that the menu will be updated before
a user hits a unlabeled or mislabeled page.

Further, the internet cafe can configure the menu with as many "static"
charsets in the top-level menu as it likes (by using the Customize... dialog).
Only the dynamically cached charsets are limited to 5.  By default, there
is usually only 1 or 2 "static" charsets (iso-8859-1 and maybe one more).

Are there really any internet cafes that have all the fonts and input systems
on one computer to support this scenario?  :-)
w2k w/ all charsets installed just works (as long as you pick any of the open 
type fonts).  If I ran internet cafe where I expected international customers, 
I would do this.  MacOS9 and better should also support something like this.  I 
wouldn't have boxes running other os's, so yes I think that portion of the 
scenario is reasonable.
Bobj is correct. After observing the customers some more (and we have tourists 
and students from a very wide variety of nationalities), I see that there is 
seldom ever a need for any of them to manually choose an encoding/module other 
than:
*   Western (ISO-8859-1) [`um, could you help me please, my Hotmail is showing
    umlauts as funny Chinese symbols ..']
*   Japanese (Auto-Detect)
*   Chinese (Auto-Detect)
*   Thai
*   Korean.
So once the recently-used encodings submenu had evolved to include these items, 
it would remain pretty static, and there would be very little need ever to go 
into the dialog. That's why (as I said in my 2000-07-24 comment) I think having 
a separate dialog for selection of permanent items for this submenu is extreme 
overkill.

Ben Goodger is currently trying to understand this UI, and my drawings in this 
bug are a bit out of date. So here's a summary of what I propose.

(1) There be a `Text Encoding' submenu, which consists of:
    -    an `Automatic' toggle, which determines whether or not the encoding
         specified by the page (if present) is heeded.
    -    A separator.
    -    The six most-recently-used encodings or auto-detection modules.
    -    A separator.
    -    An `Other ...' item, which brings up a dialog for choosing from the
         list of all installed encodings and auto-detection modules.

(2) The various auto-detection modules be listed intermingled with the
    individual encodings, sorted alphabetically by main language -- since (from
    a *user's* point of view) the difference between an auto-detection module
    and an individual encoding is precisely zero. Where an auto-detection
    module is in operation, the actual determined encoding of the page should
    not be indicated anywhere in the UI (except perhaps Page Info), as this
    information is more confusing than useful (to anyone except i18n QA
    people).

(3) The `Customize Character Coding' dialog (and the menu items it generates)
    should be removed, as this function is considerably more confusing than
    useful.

(4) The default encoding (applied when the document does not specify its own,
    or when `Automatic' is turned off) should persist across sessions, instead
    of being a pref with separate UI. (It would still have a localized
    default.)
> (2) The various auto-detection modules be listed intermingled with the
>   individual encodings, sorted alphabetically by main language -- since (from
>   a *user's* point of view) the difference between an auto-detection module
>   and an individual encoding is precisely zero. Where an auto-detection
>   module is in operation, the actual determined encoding of the page should
>   not be indicated anywhere in the UI (except perhaps Page Info), as this
>   information is more confusing than useful (to anyone except i18n QA
>   people).

I agree that autodetect and encoding selection are equivalent actions to
most users and putting them together for selection would improve usability.
But I also feel feedback is important.

In Netscape 4.x and earlier, the equivalent menu was only a selector and did
not provide feedback.

We considered providing feedback a desired feature.  (BTW, IE provides this
feedback in the same way.) The 4.x behavior is more confusing.  When I open
the menu, the check/dot has nothing to do with the current document's
charset.  E.g., I could be looking at a Japanese page, and when I open
the menu, it might show Western selected.

Currently Page Info does not provide charset info.  (I just filed bug 76516,
but I doubt this will be a high priority...)

> (3) The `Customize Character Coding' dialog (and the menu items it generates)
>   should be removed, as this function is considerably more confusing than
>   useful.

It certainly is an advanced feature.  But we felt there were some types of
users that would need this:
 - Users who do not yet have an appropriately localized version of Mozilla.
    Often localized versions lag the English release, sometimes
    signifcantly, sometimes forever :-(  But a user could modify the "static"
    charset list in an English (or other localized version) of Mozilla.
 - Internet kiosk/cafe (see my earlier comment), where the administrator
     might want to set up a larger "static" list of charsets.

But I'd be open to moving this to a pref dialog.

That was the orignal spec (after some debate).  But because of infrastructure
bugs in prefs, we were forced to add this to the menu to get the
functionality implemented for the 6.0 Beta.  Then many of us decided we
liked it better and reversed our positions from the earlier debate.

> (4) The default encoding (applied when the document does not specify its own,
>   or when `Automatic' is turned off) should persist across sessions, instead
>   of being a pref with separate UI. (It would still have a localized
>   default.)
It does persist.  The defaults should be localized for each localized
version of Mozilla.

Or do you mean you want the pref to be updated to the last menu selection?
I think the menu selection is more often be a corrective action.  I will
use it when a page is mislabeled or is in some language/encoding that I
normally don't view.  I don't want that override or special language/encoding
to become my default.

Discoverability of the pref dialog may be a problem.  Currently, you have
to go to Edit|Preferences...|Navigator|Languages to change it.  It would
be nice if this could also be changed in the "Customize Character Coding"
dialog which you propose to remove...
I am not opposed to giving feedback on the currently-chosen *method* of
interpreting bytes (whether that method be an auto-detection module, or an
individual encoding). My 2000-07-06 drawing clearly shows a bullet mark next   
to the currently chosen method, and I didn't contradict that any time afterward.
I didn't mention 4.x.

You might be open to moving the `Customize Character Coding' dialog to a pref
panel, but I would strongly disagree with that idea. Normally I advocate bits of
UI moving in the opposite direction, given how awful Mozilla's prefs UI is. But
in this case, I believe the menu customization feature is completely
unnecessary. We certainly wouldn't use it in our Internet cafe, since a few days
after installation, the submenu on each machine would have evolved to contain
the encodings/modules our customers needed most anyway. Duplicating that with a
manual list just wouldn't be worth the effort.

> Or do you mean you want the pref to be updated to the last menu selection?

Yes.

> I think the menu selection is more often be a corrective action.

Turning on the light when it's dark is also a corrective action. But you still
have to turn it off again when you've finished.
*** Bug 93237 has been marked as a duplicate of this bug. ***
>most recently used encodings
>Other...' item which opens a dialog listing the other encodings and auto-
>detection modules.

There has been some discussion about a short (mailnews style, flat) menu 
already. The 'Other...' item mpt brought up could serve as the currently 
available 'Customize...' item. One could add/drop encodings to/from the flat 
menu and make it as long (or short) as desired. The default encodings list 
could be a little longer, ~10 or so items, and the default encodings could vary 
by the build or (in Mozilla's case perhaps) by OS locale. This was Japanese 
users would be likely to find all Japanese encodings right on the top next to 
Latin-1 and selected few other items and Turkish users will hopefully see 
Turkish right on top.

FWIW, I just tried Galeon (0.12.4), and it has

  View
    Encoding >
      Arabic >
        all Arabic encodings
      Baltic >
        all Bastic encodings
      etc.

which is pretty much what I suggested (over in bug #93237).  (I'm still
not thrilled about doubly-nested menus.)  Anybody want to find some random
users and run some usability tests?
Component: User Interface Design → XP Apps: GUI Features
Product: Core → Mozilla Application Suite
what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Mass Bug Re-Open of bugs Frank Tang Closed with no good reason. Spam is his
fault not my own
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be
re-open. Spam is his fault not my own
Assignee: ftang → nobody
Status: REOPENED → NEW
Component: XP Apps: GUI Features → UI Design
Assignee: nobody → jag
Priority: P4 → --
QA Contact: zach
Target Milestone: Future → ---
Status: NEW → RESOLVED
Closed: 19 years ago → 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.