|Summary:||Revolutionary priority number propertyfor toolbars and menu entries|
|Product:||[Frameworks and Libraries] kdelibs||Reporter:||Eduardo Robles Elvira <edulix>|
|Component:||qt||Assignee:||kdelibs bugs <kdelibs-bugs>|
|Platform:||RedHat Enterprise Linux|
|Latest Commit:||Version Fixed In:|
Description Eduardo Robles Elvira 2004-05-15 18:33:41 UTC
Version: any (using 3.3.1) (using KDE KDE 3.2.0) Installed from: RedHat RPMs Currently, when you resize a window, if the toolbar entries (icons, widgets, whatever) doesn't fit in the window, then the entries that doen't fit are hidden and you can see them clicking in a ">>" button showed instead of them in the right side of the toolbar. However, that only happens when there's only a toolbar in the row. If there are two or more, the toolbar at the right in is moved a row down. My proposition is to do what MS Office and others have already been doing for years: to have toolbar and menu entries with a priority number that dictates if they could be hidden or instead behave as they currently do, if they should be hidden by default, and in which order. Toolbars and menus themselves may have the same kind of priority numbers. The priority numbers shouldn't be hardcoded or constants, but instead should be flexible and variable. A framework should be built around the priority numbers: for example, programs should determine to show by default the lastest/more used items (chnaging the priority numbers while executing a program) and of course remmember them between executions of a program. Advantages: 1. We give users and developers more flexibility. 2. It's a very powerful way to maintain the app clean because showing only the needed elemnts and hidden the not needed ones. Everything customised for the user. 3. No more crowded, cluttered menus and toolbars. No more space wasted because of countless levels of toolbars (or menus). Gnome people would be concerned :). I'd suggest them to do the same as us and even add this in their HIG. We should also add this to our HIG or equivalent. Disadvantages: 1. It comes from MS (is this a real one or something ?) 2. The feature's still waiting for being written. I'd like to know you opinion and thoughts. Thanks for your time, Edulix. PD: I apoligize my bad english.
Comment 1 Eduardo Robles Elvira 2004-09-17 00:34:54 UTC
Hello ! Is this too much revolutionary? Has anyone even readed this ? If so, what do you think about this? BTW, it would be great if this "priorities" of toolbars and menu entries could be changed on the fly by context. Yuo could sustract or add some points to some toolbars/menus/entries when needed to make the user experience better.
Comment 2 Christoph Wiesen 2005-01-23 13:33:25 UTC
Just because Eduardo asked for opinions I'll post what I said in a dot comment: Let's be serious things like this have been tried before on other platforms - like you said - and it just doesn't work well. The problem is not just that too many items are visible but that too many items are _there_. Your proposal would just hide them temporarily - and worse it would hide other items on everyone's desktop. So in the end you'd have a VERY customized desktop on all of your workers desktops even though they don't really know about it. Sit one at another workstation and he'll be lost. Or give them a new (fresh) set up and see hw they will fare. The main problem with that is that icons and context elements or whatever will have different locations - this is bad. There is a reason why unusded context menu items are only greyed out, but still there - it adds a huge amount of time if you have to look for the option you want all the time because it shifts location depending on what you're doing. The other issue I have is that this might just be used as an "excuse" to add yet more options and items in places where they aren't really needed. Like so many people (actual developers, not just stupid users like me) have said before what is needed is more thought as to what option goes where and if it is really needed there. A feature such as described here would be counter productive. --------------- Let me add that we are using various version of MSOffice at our site and the hide feature confuses MANY users - sorry, but this really shouldn't go into KDE.
Comment 3 Eduardo Robles Elvira 2005-02-14 13:58:05 UTC
Christoph Wiesen: I understand and partially share your point of view - Better thought options,menus,toolbars.. is a good solution to the clutter problem. And hiding things can turn confusing and/or frustrating to users. That could be a very good reason to disable this feature by default. You can already rearrange your toolbar items at will. Right, it's not being a machine's initiative, and we're talking only about the toolbar items, but it can also be a support nightmare. So why is it there that feature? Because it can be handy. So can be the feature I propose. And if only users who know what they're doing would activate the feature, and will know how to disable it. You just need to assure that it's implemented in a usable and well thought way. It should be easy to disable it (when activated). And you could always press the show all options item!. Talking about usability, I think that a persistent search bar (i.e. a kicker plugin or an entry box in the right side of the app menu) should be good way to locate, for example, some random option,button,feature,toolbar,menu.. in the app you're in. It could search in the help manual, tips, etc for example. More over, I still see the proposition as a really good way to get usage information from users (if they want to) to developers, which can ease the improvement of kde usability. I belive that it can be unvaluable information! In the end, the interpretation criteria and usage of that info is of course up to app developers. Many users tend to use a small percentage of what they're offered. And part of that percentage (and of the unused items) is a shared amongst most users. BTW, this information could perhaps also be used in a more advanced and general way, for example attaching an AI kit that would be connected to the information pipe and act consecuently and in a much richer way. Perhaps for KDE 5.0 ? ;-).