GNOME Bugzilla – Bug 113044
Tab descriptions are too general
Last modified: 2004-12-22 21:47:04 UTC
Its important to think about what information you see when you are looking for a particular preference. The current tabs are so general that it is very difficult to figure out which tab you want to go in. This makes people "explore" (or often, give up). It would be better to use a larger number of tabs that are more clear/specific. The "User Interface" tab is particularly unclear, and should probably be rennamed "Tabs". Off the top of my head, I would suggest having the tabs: General | Fonts & Colors | Tabs | Advanced You might consider making "Advanced" "Caches", if that's all that's going to be in there... though "Caches" is a scary technical term so it might be ok to hide stuff there. Most people will look in Advanced for that sort of stuff if they want it anyway, just by training from other browsers.
Oh sorry, one more "Language"
The preference dialog is changed a bit in cvs. There is only one tabs pref (Open in tabs by default) and it has been moved in General. The language stuff has been moved in Advanced, because now we use system language by default ... and that should work for most people. So I guess a Tabs category doesnt make sense anymore (only one pref) ? I'll change Fonts & Colors. About Language, considering that it should just work for most people now, do you think it's worth a category ? In that case we could move the whole list of language (now accessible by More button) directly on the notebook. That could be nice actually.
seth, marco how about this: 1. Kill the "On New Page" prefs. bug 113045. 2. kill all the color prefs with the exception of the overide page colors pref ("Always use desktop theme colors" in the ui), and move this pref into general. bug 113052 3. New tab categories, general, fonts, languages, advance.
Hi Marco, well... not sure about Language. What people doesn't it work for? (forgive my ignorance here). Its currently taking a lot of space in the most basic tab, if its really something people wouldn't commonly be interested in.
We are setting the Language pref by default to: User language (LANG var) English This could not work very well, for example, for an italian that has as secondary language French. He would rather prefer: User lang (Italian) French English So sites that support French but not Italian will display in French and not in English. About the encoding: I'm said that setting the encoding manually is just a work around for some broken pages. It's possible to set it from the View menu. I guess the use of these prefs is just to make this change persistent. It looks like very very corner case, but I'm not very clued about encodings :/ Maybe Menthos knows better.
Regarding the encoding issue, the default encoding to use for a document, when no other is specified, is specified in the HTML standards: HTML 4.x => iso-8859-1, XHTML 1.x => UTF-8, etc. These are the encodings that the documents should be interpreted as unless otherwise specified by a charset line in the document. However, due to the nature of the web with formally broken documents everywhere, countless numbers of sites don't properly specify what encoding they use, even if they use another encoding than the standard one for the particular document type. This situation is in a way made even worse by different browsers handling such broken documents in different ways or the attempt to emulate the handling of broken documents by other browsers (see Mozilla quirks mode). As such, web developers usually never see the errors or broken assumptions that their broken documents may cause with other handling of their broken documents. In any case, the net effect of this situation to users when it goes wrong is everything from some characters being garbled to the entire content being totally unreadable, depending on the language and script being used. So this is clearly a trade-off between standards compliance and allowing an escape route for some users in the common case of illformed documents. I'm not sure whether this validates the need for a general encoding preference though -- if a correct encoding needs to be explicitly set by the user, because of a broken document, then this should be per-document or per-site IMHO, and set only from the View menu. Guntupalli, what's your opinion?
I fixed the Appeareance tab. We just need to make a call about Language now, his own page or let it in advanced.
fixed in cvs. Now we also a Language tab.