Re: Stock items (button images / menu images etc)

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 13 December 2013 17:37,  <coul hccnet nl> wrote:
> Emmanuele Bassi wrote:
>
> > in general, you should also question the icons usage: overloading the UI
> with visual cues ends up distracting the >user, and in general the
> written word is more apt to describe actions than a bare icon, unless the
> icon is >unequivocally tied to a specific action (e.g. standard images).
>
> One should not forget that smaller freeware programs tend to be available
> in only one language, usually English. And for the majority of people
> English is not the main language. Therefore for all users not good in
> English GUI icons can be a big help.

that is a fair thing to say. what's best, though, is *not* to rely on
icons but on localised applications.

there are various ways to get an application localised, and having the
larger free software community help in the translation of the
user-visible strings.

let's also remember that icons come with context associated with them;
not everyone has the same context or shares the same environment.
there are some icons that make no sense unless you already know what
they mean, or unless somebody is actually guiding you through. all
visual elements of a UI belong to a certain dictionary and grammar,
but just like we don't all use the same language, we cannot assume
that everyone will understand the UI that we're designing. talking
people through a process, in their language, usually is a better help
than giving them an icon and assuming.

> Also when you have long menus, menu
> icons help to more quickly locate the item you want, even for the author
> of the software himself.

this is not actually true, though I'll be the first to admit that it
seems counter-intuitive. the more complex the task, for instance, the
more you *don't* want an icon — regardless if it's a common or
uncommon task. the more complex the icon, the less probable is that
people will recognise it. there are many studies done in HCI and user
interaction design that deal with icon recognition, and how much you
can delegate to an icon as a shortcut, as opposed to actually stating
the task through verbs and nouns. that is why I said "in general
overloading the UI". slapping icons in the UI without proper thought
is exactly like removing all icons from the UI. you need to carefully
consider the implications of doing something when designing any kind
of GUI.

for instance, the guideline for GNOME is to use icons in menus only
for "nouns" (i.e. elements like bookmarks, lists of applications,
lists of files, disk devices, etc.), and avoid them for "verbs" (i.e.
save, quit, open, etc.) because verbs are poorly represented by
objects — just think about it: "Save" is a floppy disk. the operation
of "saving" is represented by a storage medium where the file will be
saved, except that the storage medium used to represent the operation
is dead and gone, and people born 10 years ago won't ever know what it
even is. it's like saying that icon for "Play" in a music player
should be a 8-track tape. clearly, right *now* people know what a
"Save" icon looks like, but we're talking about knowledge passed down,
not learned, and we have this cognitive surplus of knowing what "Save"
means both in your native language (and any other language you may
know) *and* through an icon. cognitive surplus is bad, as it imposes
baggage that should be avoided when doing anything with a tool (like
the computer is).

ciao,
 Emmanuele.


-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/