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

List:       kde-usability
Subject:    Re: KDE 4.2 Toolbars
From:       Peter <gostelow () global ! co ! za>
Date:       2008-11-16 13:24:19
Message-ID: 200811161524.56111.gostelow () global ! co ! za
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 12 November 2008 17:31, Nuno Pinheiro wrote:
> Well some time ago I sudgested to Celeste  that we should use in the
> thoolbars text along side icons instead of text under icons.  Couse: 
> 1 Looks Pretier.
> 2 Saves precious vertical space.
> 3 Remains a prety big hit area.
> 4 Its more readable (no need to read rows horozontaly) just one line
> 5 Its visualy more consitent with the text menu area.

The WIMP used by KDE defines icons, not text, as a primary human/machine 
interface. Text aids the icon stream, it is not an another interface. Icons 
work better than text because they're language independent and therefore 
universal. If the human does not understand the icons, no amount of text 
alignment in the toolbar will change that because the problem is with the 
interface, not the toolbar.

Text creates incompatibilities within the toolbar itself because it expands 
the vertical toolbar's width, but the horizontal toolbar's length. Because 
text also has orientation it creates inconsistent toolbar behaviour.

In a related thread, the debate centres around the amount of information an 
icon should deliver, particularly for image file formats. Since icons form 
part of the human/machine interface, the icon information stream should be 
well-defined with regard to information content, complexity, and recognition. 
This is relevant where toolbars are concerned because users are not 
recognizing the icon's informational content and therefore requesting text.

Currently, icons are considered holistic images. This means that when Dolphin 
developers want to represent all the combinations of a locked, read, write, 
execute, local, remote, file system, mime type, and/or encrypted file, 
they're required to select from a vast amount of predefined icons, which may 
or may not display the desired information.

If icons are to be part of the human/machine interface, each icon should 
generate itself based on data provided by the application, not the artist's 
impressions. Therefore an icon (C++) class should have a set of icon elements 
and a data interface which it uses to generate a run-time icon. When the data 
changes, the icon is regenerated to reflect the change. This allows app 
developers to identify new iconic data elements and incorporate them into the 
icon class without requiring Oxygen artists to generate a new combination of 
icons that include the new data. The artists will be required to evaluate new 
data elements in terms of theme, composition, and recognition.

The set of icon elements represent the total iconic information required by 
the WIMP interface and defined by the interface designers. The Oxygen artists 
may generated themed elements (icon font) and design icon layouts 
(composition) which app developers incorporate into their icon (C++) classes 
to generate the app's icons. Users may still switch themes which will change 
the icon font and _may_ change the icon composition (style?) as well. For 
finer control, users may enable or disable a particular data element which 
will alter the amount of information the icon provides. This will affect the 
icon's composition and Oxygen artists should tackle this issue.

Effectively, this means workable icons won't exist outside applications, but 
Oxygen developers may generate an icon gallery to validate and solicit 
feedback. The Oxygen move, therefore, should be from monolithic icons to 
iconic elements, composition, and data recognition. However, this cannot be 
done until WIMP developers define the required icon information.

Text wastes far more screen space than icons do and is not part of WIMP, so 
the toolbar default should be icon only with tooltip support. None of the 5 
points listed above address the icon's interface's failure to provide the 
expected information. First we must make the icons provide the information 
and then we can evaluate their useability. If the amount of information is 
more than icons can show (pixel wise), then, and only then, should we 
consider another way to provide the additional information. In this case, the 
new interface will be distinct from the icon one.

Finally, no interface or metaphor can be all things to all people. The icon 
interface is more complex than developers and artists are willing to admit 
and the trade-offs are a weakening in design and a bloated implementation. 
This regression results in a dysfunctional interface and spawns a plethora of 
workarounds, the real problems are never solved, and no-one learns how an 
icon interface should work.

In a word, KISS.

Peter.

>
> Well she agread that it might be a good a idea and tested it in the Kubuntu
> Intrepid Alpha 5 testing stage. (no major complaints so far)
> The main concernes were that we would be using more horizontal space and in
> small screns we would loose some actions... (we dont actualy lose all that
> space its mainly about 26 pixels x number of actions).
> Btw in small screens the best isdea IMO would be to push for difrent
> defoults as saving space is realy important there, and no text at all would
> probably be a good idea.
>
> The other problem aparently is that some apps dont folow defoults setings.
>
> So im proposing a difrent defoult for kde 4.2 were its text along icons
> instead of text under icons...

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]