Closed Bug 10999 Opened 26 years ago Closed 16 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: 20 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: 20 years ago → 16 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.