Version: (using KDE KDE 3.3.0) Installed from: Gentoo Packages OS: Linux HTML Settings is not a tool, and therefore it does not belong in the "tools" Menu. This is more of a settings that IMHO should go inside the dialog box "Settings -> Configure konqueror..." according to: http://usability.kde.org/hig/current/system-settings.php#system-settings-configuration Also, "Change browser identification" is not a tool, it should go inside "settings". This one is a bit tricky because it falls under "Document Options" http://usability.kde.org/hig/current/system-settings.php#system-settings-document but there is no clear place where this should go. It is however clear this is not a tool but a setting and IMHO should not go in "tools".
I like to enable cookies on a per web site basis. As I know I can do that quickly from the menu, I always expect it to be in the "settings" menu but it is somewhere in the "tools" menu and it is irritating. To me enabling or disabling cookies seems to be a matter of "settings" and not a "tool". For me a tool is something like the "find" tool or "translate this page". Regards, Sangohn Christian
On Wednesday 10 November 2004 14:49, xtian0009@gmx.net wrote: > ------- I like to enable cookies on a per web site basis. As I know I can > do that quickly from the menu, I always expect it to be in the "settings" > menu but it is somewhere in the "tools" menu and it is irritating. To me > enabling or disabling cookies seems to be a matter of "settings" and not a > "tool". For me a tool is something like the "find" tool or "translate this > page". The UA changer is an optional tool that plugs into KHTML, not a setting.
So all the plugins go in tools???? That sounds like making the UI accomodate the programmer rather than making the UI accomodate the user. A user has no idea that changing disabling/enabling the cookies is a plugin (and he should not have to know). He would expect that kind of stuff to be a setting, not a tool, don't you think? I would have to agree comment #1 that the enabling/disabling the cookies belongs in settings and not tools from a usability POV.
Cookies are configurable from the Settings menu only. There is a -tool-, that is -optional-, that is a -plugin- to khtml from kdeaddons, that allows you to do this quickly. That's why it's in the tools menu.
George's statements appear to come with reason. There maybe reasons for both point of views. Since it's been ~2 years in that state i will close this bug in case of no objections within 30.
Would it be possible to get some of the usability guys look at konqueror menu before closing it?
Note the bug is about "HTML Settings" and "Change Browser Identification", not about the cookie thing. So please dont close the bug because an unrelated (maybe invalid) bug was mentioned.
the devs are aware of the hig-related bugs. the guidelines are about to change, then the problem will be adressed.
Yea, Konqueror is one of the ugliest apps in KDE in terms of usability. What you guys are bringing up seems to be a case of interlapping fuzzy logic (i.e. one can categorize a setting as a tool and a tool as a setting). We could go two directions: 1. A heuristics approach, or which items are more likely to be considered in one category than another. 2. More preferably, eliminate fuzzy interlapping. This would take a broader spectrum of applications, as most KDE apps have both tools and settings categories, and the same issues could be easily duplicated. I'll try doing a web search for prior usability studies that would pertain to these issues.
Jacob: did you find something interesting on your searches?
Well, eliminating categorical overlapping tends to be the more popular answer to this question.
Sorry but no one here seems to listen to what George said. If a particular plugin violates the HIG for you, feel free to not enable it or remove it. It is an optional helper that is not needed. You can change all configuration from the settings menu. And in the same menu you can choose to disable these helper plugins that are mostly redundant.