I've added some comments related to usability in your proposal below:
2006/5/24, Jani-Matti Hätinen <
[EMAIL PROTECTED]
>:
Although I haven't seen a mock-up of this idea yet, I think there are some issuess to be addressed:
- From a graphic design view, having an inconsistent icon (graphical element) size throughout a certain toolbar results is graphically not appealing (Gestalt principle 'alignment').
- Due to the changing nature of the icons in the toolbar, the position of a certain toolbar item would be less easier to predict. A possible result of this would be increased navigation time of the mouse cursor of point 'X' to that certain toolbar item.
- The cognitive effects (such as speed, memory etc.) of icons with inconsistent size in an array hasn't been scientifcally researched yet. That is, I haven't any scientific literature on this specific subject yet.
- Relative values such as 'often', 'seldom' etc. cannot be quantitized, that is, each user has a personal value that differs per user, per application, per use case. For instance, when I'm designing a birthday card in KWord, I'll be doing more design actions, in contrast when I'm writing an academic report, where I'll be using more text formatting tools. What is 'often'? Would the user interface adapt while running an application, or would it adapt over a longer timespan? The usefullness of adaption is hard to predict due to a great amount of variables as described above. Even if you would conduct user testing with a huge amount of users, I'm not sure whether this would result in useful data.
- Elaborating on the previous issue, the multi-purpose use a single application is also an issue. Take Konqueror for example, it's both a file browser as well as a web browser. The location bar in web browser mode would be used a lot, whereas the user would use the icon view to navigate in file browser mode.
Hints would be a nice addition.
I'm not sure whether having inconsistent font size in a context menu (which would also result in inconsistents vertical spacing) would enhance readibility...
Again, I'm not sure whether you can draw semantics of a bunch of numbers, without knowing the other variables (may be considered as meta information).
Personally, I hated the adaptive menus in MS Office. Example: At the time of Word 2000, printer ink was quite expensive (and it still is today), so I tried to print only when it was really necessary. If I printed to times a week, I would have considered that a lot. Of course, I would use Word more often than I would print. Word would have hidden the print menu item, although I didn't consided it not important. (Not sure whether this was a true experience, I disabled personalized menus a long long time ago, but you'll get the idea.)
Bottom line: because of the adaptation, the predictability of place and position of UI elements decreased a lot.
I'm not sure whether these approaches can be seen analogue to yours. First of all, the adaptive menus weren't much of a success, outlined here: http://blogs.msdn.com/jensenh/archive/2006/03/31/565877.aspx. Second, the Ribbon is contextual, and as for as I know it doesn't hide non-important items.
To summarize, your proposal raises many questions which cannot be answered without doing any research. What is to be expected, is that the user interface will look aesthetically less appealing, due to graphical design issues such as inconsistency, balance, alignment etc. Of course, this would not be the greatest drawback. If the nature of adaptation during the usage lifecycle proves to be unable to enhance the usability of the user interface, this idea should be discarded.
When a user-centered development methodology is applied when developing an application, the user interface will be 'adapted' (or 'adjusted'), created specifically for a group of users. Is further personalization required, and if so, can it be done automatically? And if we were to implement an auto-adaptative user interface, would the application be able to gather data about the user that can be used usefully? If I had to answer that question, I would have to honestly say that I don't think that it's doable.
Chi Shang
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.
Although I haven't seen a mock-up of this idea yet, I think there are some issuess to be addressed:
- From a graphic design view, having an inconsistent icon (graphical element) size throughout a certain toolbar results is graphically not appealing (Gestalt principle 'alignment').
- Due to the changing nature of the icons in the toolbar, the position of a certain toolbar item would be less easier to predict. A possible result of this would be increased navigation time of the mouse cursor of point 'X' to that certain toolbar item.
- The cognitive effects (such as speed, memory etc.) of icons with inconsistent size in an array hasn't been scientifcally researched yet. That is, I haven't any scientific literature on this specific subject yet.
- Relative values such as 'often', 'seldom' etc. cannot be quantitized, that is, each user has a personal value that differs per user, per application, per use case. For instance, when I'm designing a birthday card in KWord, I'll be doing more design actions, in contrast when I'm writing an academic report, where I'll be using more text formatting tools. What is 'often'? Would the user interface adapt while running an application, or would it adapt over a longer timespan? The usefullness of adaption is hard to predict due to a great amount of variables as described above. Even if you would conduct user testing with a huge amount of users, I'm not sure whether this would result in useful data.
- Elaborating on the previous issue, the multi-purpose use a single application is also an issue. Take Konqueror for example, it's both a file browser as well as a web browser. The location bar in web browser mode would be used a lot, whereas the user would use the icon view to navigate in file browser mode.
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.
Hints would be a nice addition.
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.
I'm not sure whether having inconsistent font size in a context menu (which would also result in inconsistents vertical spacing) would enhance readibility...
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.
Again, I'm not sure whether you can draw semantics of a bunch of numbers, without knowing the other variables (may be considered as meta information).
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,
Personally, I hated the adaptive menus in MS Office. Example: At the time of Word 2000, printer ink was quite expensive (and it still is today), so I tried to print only when it was really necessary. If I printed to times a week, I would have considered that a lot. Of course, I would use Word more often than I would print. Word would have hidden the print menu item, although I didn't consided it not important. (Not sure whether this was a true experience, I disabled personalized menus a long long time ago, but you'll get the idea.)
Bottom line: because of the adaptation, the predictability of place and position of UI elements decreased a lot.
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.
I'm not sure whether these approaches can be seen analogue to yours. First of all, the adaptive menus weren't much of a success, outlined here: http://blogs.msdn.com/jensenh/archive/2006/03/31/565877.aspx. Second, the Ribbon is contextual, and as for as I know it doesn't hide non-important items.
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.
To summarize, your proposal raises many questions which cannot be answered without doing any research. What is to be expected, is that the user interface will look aesthetically less appealing, due to graphical design issues such as inconsistency, balance, alignment etc. Of course, this would not be the greatest drawback. If the nature of adaptation during the usage lifecycle proves to be unable to enhance the usability of the user interface, this idea should be discarded.
When a user-centered development methodology is applied when developing an application, the user interface will be 'adapted' (or 'adjusted'), created specifically for a group of users. Is further personalization required, and if so, can it be done automatically? And if we were to implement an auto-adaptative user interface, would the application be able to gather data about the user that can be used usefully? If I had to answer that question, I would have to honestly say that I don't think that it's doable.
Chi Shang
--
Jani-Matti Hätinen
_______________________________________________
Appeal mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/appeal
_______________________________________________ Appeal mailing list [email protected] https://mail.kde.org/mailman/listinfo/appeal
