Hello, I propose below an idea on how the current Menu + Toolbar -based GUI paradigm might be improved upon (thus it won't represent any sort of radical rethinking of the GUI). Right now I'll try to represent my ideas in text form, but later on I'll try to create some mock-ups to illustrate my points. First I'll cut to the chase and try to explain the idea as clearly as possible. Then at the end I'll detail some of the earlier GUI developments which inspired this idea.
Basically this boils down to having toolbar and menu items, which change their size depending on how often you use them (or alternatively can be locked to certain fairly free-flowing sizes). So, if you, for example mainly use the back and reload buttons in konqueror's web browser mode, the icons representing the actions would, at first, enlarge to make is easier to spot and hit them, and eventually the larger icons would be accompanied by a text label, which would further differentiate them from the other visible GUI elements. Similarly, if you were to often use the New Tab action from the Location menu, it would get bigger and bigger over time (first accompanied by a bigger icon and more vertical spacing, but later also with bold text and a bigger font). Also, if for some reason your usage habits were to change so that you wouldn't use a certain action as often (for example you were to start using the Ctrl-Shift-N shortcut for new tabs), the corresponding GUI element would shrink back according to your usage habits. Naturally the growing and shrinking of the GUI elements would be scaled according to the user's font and icon size settings. So if you were to choose small icons, the icons would never too big, or too small, if you were to choose big icons. The adaptive GUI element sizes could be further accompanied with hints, which would make it easy for a user to add an often used menu item into the toolbar, or remove a rarely used toolbar item, to be only accessible from the menu. Note that the movement options should also be accessible from the same place even when no hint would be visible (possibly through a context menu which the hints could refer to) The main point here would be that moving GUI elements would never happen without the user's request. The automatic GUI adaptation would only affect the proportions of the different GUI elements according to their use. This approach could (and if possible, should) be applied to all GUI elements. For example launchers in the panel would change size depending on their usage, as well as programs in the KDE menu. The same could even apply to context menus as well as files and folders in konqueror's icon view. Now I'm not sure how difficult this would be to implement, but I'm guessing pretty difficult. At minimum it will require SVG icon support to allow smooth icon scaling, considerable changes to the current menu and toolbar handling code, some sort of background process which would track and analyze the user's usage habits and config file support to store the user's settings. Whether this is at all doable in QT4 I can't really say. Anyway here's the background & rationale section for this idea: The main sources of inspiration for this idea (apart from every single GUI software I've ever seen) are the adaptive menus in MS Office 2000 and later, as well as somewhat by the ribbon-style GUI of MS Office 12. The final spark however came from the new startup dialog in koffice-1.5. Just like the two MS Office GUI ideas, this idea tries to solve the problem of finding the wanted options/features in increasingly complex pieces of software. The Microsoft approach to this problem (first with adaptive menus and now the ribbon-style GUI) is to hide unused features in order to make the oft-used ones more visible. However, this approach has the basic problem of 'If I can't see it, it's not there'. As we all noticed with adaptive menus (and will probably notice with the ribbon-thing) trying to remember where an invisible option is is a lot harder than trying to find a visible one amongst even a lot of others (especially if even the visible GUI elements are always moving as was the case with adaptive menus). Nevertheless IMHO both the Microsoft solutions as well as the koffice dialog illustrate three important points: First: moving GUI elements without user consent is just plain malice. Second: infinite, repetitive menus (which offer no other distinction between the different options apart from the actual text) aren't usable for anyone (because if you were ever able to get the adaptive menus right, it was a hell of a lot better than the traditional ones, until it changed again, that is). Third: Correlating the frequency of use for an action with the size of the corresponding GUI element is a good thing. (This is demonstrated really well in the koffice-1.5 startup dialog in which the most often used buttons (Open existing document... and Open this document) are by far the smallest GUI elements in the whole dialog) So, merely changing GUI element sizes is IMHO a fairly good compromise between optimising a GUI for the user (which most people actually want) and not playing games with his/her sense of direction. -- Jani-Matti Hätinen _______________________________________________ Appeal mailing list [email protected] https://mail.kde.org/mailman/listinfo/appeal
