[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: What is obvious?; Context sensitive sidebars.
From:       Sven Burmeister <sven.burmeister () gmx ! net>
Date:       2005-03-15 11:55:43
Message-ID: 200503151255.43158.sven.burmeister () gmx ! net
[Download RAW message or body]

Hi!

Am Dienstag, 15. März 2005 11:57 schrieb D. Moya:
> The current GUI toolkits have support for this to some degree -
> toolbars and menus for beginners, shortcuts for advanced users - but
> it still leaves much work to the programmer.

What about introducing the possibility to have a toolbar with some icons 
having text next to it, but not all of them. This way, a group of 
functionalities, i.e. icons, has one flag to wave at the user and guides 
him/her to the place where one can find realted functionality. If yopy is 
there, somewhere next to it must be move, delete... Maybe one should allow 
icons to expand the text next to them when they are hovered, this will move 
all icons to the right of the current one to the right, yet allow discovering 
the functionality "by mistake". Tooltips have the problem of not being 
instant, so the user has to aim at them and wait. If one does not like the 
expanding to the right, one can add instant tooltips that have a little 
button "Tell me more...", which leads to more help but not the manual because 
people do not like to read long texts. So if one had a hierarchy, 
instant-tooltip, what's this, manual, all linked by a click, the user could 
decide how far s/he wants to go. At them moment one has to hover (wait), one 
gets a bit of information (tooltip), for the next bit one has to click that ? 
at the top right and go back to the functionality to click on it (what's 
this?), to get the next bit, one has to open the manual and search through 
all the functionality of the application, even if one is only interested in a 
certain one.

> > I doubt that there is one GUI to fit them all, and the GUI that comes
> > closest to fitting all users needs is a full-time job and very difficult
> > to create,
>
> Yes, indeed. Good design is one of the most difficult jobs in the
> industry, thatīs why we see so few of them. But should we aspire for
> less than the best?

As I said, I would love it, yet one should know ones limits, so if there is 
enough man-power to achieve the best, one should aim for it. If not one 
should set realistic targets.

> Speaking of the one GUI that fits all humans, have you read about The
> Humane Environment? See
> http://en.wikipedia.org/wiki/The_Humane_Environment

I will, thanks.

> The problem with switching profiles is that it tears off the
> familiarity with the known interface. Changing interfaces without a
> good model for understanding the change is a pain: it forces you to
> relearn the interface. And users *would* want to change the expertise
> level once they become accustomed to the app, but they won't if that
> means starting from scratch.

What I meant was to have steps like: Cluster 1: Basic functionality written 
out and hinted to, e.g. icons + text, more advanced functionality is "hidden" 
in order to have space for the text next to some icons as well as expanding 
(advanced functionality can be accessed and easily added by a button: More 
functionality), Cluster two: more advanced functionality is not "hidden" but 
hinted to and represented by icon + text (maybe including the shortcut), 
basic functionality is still at the same place, yet without the extra help, 
i.e. just icons, no text. This way, functionality stays at the same place, so 
no beginning from scratch when switching Cluster, just less help and more 
buttons to chose from. Obviously this fits best a toolbar GUI and not a 
settings GUI.
What might also help is, to replace that "Configure toolbars..." GUI by a GUI 
that lists all available functionality in a grouped list, i.e. group-icons to 
the left, functionality to the right. The functionality is represented by its 
icon, its title, a description (What's this? text), a link to more detailed 
information and a clickable button showing its state, i.e. shown/not shown in 
toolbar.
This way the user has a clear overview of available functionality, can link 
the icon shown to it, gets some description/help and access to more help, can 
easily add/remove it to the toolbar and knows which other functionalities are 
available/belong for/to a certain group.

> I agree that an "advanced" panel which is usually hidden may be a good
> compromise in some cases (not all), but this should be done on a
> per-function basis, not for the whole application.

True, yet per function might be a little too detailed, so somewhere in between 
might be functionality groups such as file, view, edit, settings or extra. 
Yet again, with the functionality catalogue described above, it would be 
possible to do it on a per functionality basis too. The user can chose 
levels, i.e. settings for a group of icons including which ones get text 
displayed next to them, which ones just icons, and which ones are considered 
advanced i.e. not shown. Then one can change the status per functionality in 
the catalogue from e.g. not shown to icon+text to icon.

> As far as I know, there are already people doing part of that work.
> Arenīt the KDE usabiilty labs making field studies on users?

If so, this would be great, especially as it is very hard to get somebody's 
opinion when they are just using the computer, as they are not interested in 
helping, i.e. are not fans that through their ideas at the developers.

Sven
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]