Icon standardiation
Robert Mah
his annoyance at tool icons used in some commercial apps.
I thought a bit about this. It is generally accepted that icons
(pictures) are usually easier for people to interpret than a sequence of
symbols (words) when the concepts they are trying to express aren't too
complex. So why did he (and I) have problems with them? Why can I
accept tool icons in paint programs but not in apps like 1-2-3 and Word?
It seems to me that the reason for the problem regarding icons is simply
the lack of any sort of standardization in their useage among different
software applicatoins. These icons are, in a sense, another language that
is being used to express ideas to the user. However, each vendor is using
their own language and users are, understanably, confused. The Babel
phenominon rears it's ugly head again.
When there _is_ some sort of standardization, the meaning of the icons is
unamiguous and easily recognizable. For example, on the Macintosh, most
graphics programs represent the color fill function with a little paint
bucket tilting slightly towards the right with paint spilling out of it.
This is, of course, a somewhat arbitrary (though historically based) choice,
however because of it's generally accepted nature, anyone who has used one
paint program can use this feature in another with no misunderstanding.
If you have to sit there and ponder over the meaning of an icon, it's not
doing its job.
There is already some legal debate regarding the ownership of icons for
certain functions (e.g. Apple & the trash can). I feel that any sort of
effort to provide a common iconic vocabulary would help to minimize such
silliness by showing prior art and such.
So, getting to the point, I'd like to see some sort of effort to standardize
the meanings of the icons used in computer software. It would be nice to
create a sort of iconic dictionary and possibly an associated "grammer".
Care should be taken to keep the "standard" from being too constrictive;
ensuring free creative expression. This can only help both software users
and creators by providing a bit more stability in a turbulent environment.
Any comments or opinions?
Cheers,
Rob
--
---------------------------------------------------------------------
Robert S. Mah | Voice: (212) 947-6507 | "Every day an adventure,
One Step Beyond | EMail: rm...@panix.com | every moment a challenge."
Terran Boylan
available anywhere via anonymous FTP?
--
---
Terran J. Boylan, Sr. Artist/Programmer | "It's better to have loved
Engineering Animation, Inc., Ames, IA | and lost than just to have
(515) 296-9908 / (515) 296-7892 (> 5PM) | lost." -- Dorky Dog
Robert Mah
> Are there any Public Domain icons (Grey scale or B&W) available anywhere
> via anonymous FTP?
Very few icons are individually copyrighted (so far). And macintosh users
trade icons quite a bit so you might find some on sumex or umich. You'll
definately find a whole bunch on Compuserve or AmericaOnline.
But it's not the creation or distribution of icon's I'm concerned about.
It's the "Tower of Babel" phonominon that seems to be occuring with them.
That is, different icons are used to signify different things in different
programs. Or worse, the same icon means different things in different
programs. This only leads to confusion and reduces their effectiveness.
Hmm, I wonder if a simple, informal, ad-hoc dictionary would suffice.
It may be that formal standards are a bit too much for something like this.
Andreas Dieberger
>But it's not the creation or distribution of icon's I'm concerned about.
>It's the "Tower of Babel" phonominon that seems to be occuring with them.
>That is, different icons are used to signify different things in
different
>programs. Or worse, the same icon means different things in different
>programs. This only leads to confusion and reduces their effectiveness.
In fact it!s even worse since icons often mean different things in the
*same* program.
An extreme example is the "go back"-arrow frequently used in
hypercard-stacks. It!s a bent arrow to the left (a bit like the symbol
for the good old "return"-key). Most programmers use this icon for the
"go back" action.
Alas hypercard doesn!t treat this "go back" consistently so you will not
always go back to the last card visited but sometimes somewhere else
(probably a never fixed bug in hypercard). Because of this some hypercard
programmers write special go back scripts that go back to the "next
higher concept". So if you are reading something like a book in hypercard
this arrow will not jump back to the previous page but to the beginning
of the previous chapter or the like.
Andreas
--------------------------------------------------------------
Andreas Dieberger
Institute for Design and Assessment of Technology
Technical Univ. of Vienna
A-1040 Vienna - Moellwaldplatz 5/187
Tel. (+43-1) 504-11-86/12, Fax. (+43-1) 504-11-88
email: and...@iguwnext.tuwien.ac.at
--------------------------------------------------------------
Robert Mah
> In fact it!s even worse since icons often mean different things in
> the *same* program.
> [ hypercard and scripters as an example deleted ]
Very true. I think one of the reason many hypercard scripters make those
sort of mistakes may be their lack of experience in thinking about these
matters. A guide would help them out tremendously.
For the rest of us, having some kind of Icon Dictionary to refer to would
allow us to concentrate on problem at hand instead of trying to draw some
little bloodhound to mean "search".
On the user's side, the different apps would use the same icons for the
same functions/objects and thus, they would make more sense. No more, "just
what _is_ that a picture of anyway?".
Later,
thom kevin gillespie
Children's Machine." In it he elaborates on the short article he had in
Wired about the "Knowledge Machine" for kids. This is way past icons and
pictograms which from the dicussion here is closely related to what he
calls 'letteracy'
I don't want a dictionary of icons, I want something which makes sense.
If we need the dictionary of icons to design the 'thing' the users will
need the dictionary of icons to use the 'thing.'
--Thom
Acquiescence
>Andreas Dieberger <and...@iguwnext.tuwien.ac.at> writes:
>
>> In fact it!s even worse since icons often mean different things in
>> the *same* program.
>
>Very true. I think one of the reason many hypercard scripters make those
>sort of mistakes may be their lack of experience in thinking about these
>matters. A guide would help them out tremendously.
>
>For the rest of us, having some kind of Icon Dictionary to refer to would
>allow us to concentrate on problem at hand instead of trying to draw some
>little bloodhound to mean "search".
Perhaps having the word "search" on a clicable button would
get around this whole problem in one fell swoop.
>On the user's side, the different apps would use the same icons for the
>same functions/objects and thus, they would make more sense. No more, "just
>what _is_ that a picture of anyway?".
Ah. I see that the notion of the pictograph is alive and
well in the minds of human-factorists.
<sigh>
Perhaps there should be some sort of mandatory study into the
nature of "pictographic" systems--focusing on Chinese, for
instance, for everyone designing user interfaces..
--
"It is well to have right on our side, but it is madness to forget that unless
we have might as well it will avail us nothing. We must believe that God
loves men of good will, but there is no evidence to show that He will save
fools from the results of their folly." --W. Somerset Maugham (1946)
Stefano Pagiola
> I was browsing USENET and came upon a post where someone was
> expressing his annoyance at tool icons used in some commercial
> apps.
>
> is simply the lack of any sort of standardization in their useage
> among different software applicatoins. These icons are, in a
> sense, another language that is being used to express ideas to
> the user. However, each vendor is using their own language and
> users are, understanably, confused. The Babel phenominon rears
> it's ugly head again.
>
> When there _is_ some sort of standardization, the meaning of the
> icons is unamiguous and easily recognizable. For example, on
> the Macintosh, most graphics programs represent the color fill
> function with a little paint bucket tilting slightly towards the
> right with paint spilling out of it. This is, of course, a
> somewhat arbitrary (though historically based) choice, however
> because of it's generally accepted nature, anyone who has used
> one paint program can use this feature in another with no
> misunderstanding. If you have to sit there and ponder over the
> meaning of an icon, it's not doing its job.
I think effective use of icons requires one or both of two things:
1. Consistency of use.
2. Clarity of representation.
The first should be obvious; the same icon should mean the same thing
in all contexts (or very similar things that are obvious from the
context, just like `print' might mean slightly different things in
different apps and yet be predictable within a given app) and two
different icons should not be used to mean the same thing.
The second simply means that the icon should provide a fairly obvious
representation of what using it produces. To some extent,
consistency of use can over-ride this need, as in the paint example
noted by Robert. In this context, Apple did the world a disservice
by suing to prevent use of iconic representations it had developed
(eg the trashcan), since it hindered the development of a common
language.
Even with these requirements being met, however, it is not clear to
me that icons are a viable long-term avenue for development. We don
not want to end up reinventing the Chinese language and all be forced
to learn several tens of thousands of symbols.
I often design icons for use under NeXTSTEP. The majority of these
icons are folder icons (used to replace the generic folder icon). To
make it clear that an icon represents a folder rather than an
application or a document, I usually combine a small-scale folder
icon together with a representation of the folder's contents. For
example, a folder that contains fonts might combine the standard font
document icon with the folder icon.
--
-
Stefano Pagiola
Food Research Institute, Stanford University
spag...@frinext.stanford.edu (NeXTMail encouraged)
spag...@FRI-nxt-Pagiola.stanford.edu (NeXTMail encouraged)
Bruce Carter
<and...@iguwnext.tuwien.ac.at> writes:
>In fact it!s even worse since icons often mean different things in the
>*same* program.
>An extreme example is the "go back"-arrow frequently used in
>hypercard-stacks. It!s a bent arrow to the left (a bit like the symbol
>for the good old "return"-key). Most programmers use this icon for the
>"go back" action.
>
>Alas hypercard doesn!t treat this "go back" consistently so you will not
>always go back to the last card visited but sometimes somewhere else
>(probably a never fixed bug in hypercard). Because of this some hypercard
>programmers write special go back scripts that go back to the "next
>higher concept". So if you are reading something like a book in hypercard
>this arrow will not jump back to the previous page but to the beginning
>of the previous chapter or the like.
On the contrary, HyperCard always executes the "go back" command
consistently. People who write HyperCard stacks do not, however, always
script it consistently, nor are they often aware of the consequences of
certain actions that affect where "back" is. This is not a bug in
HyperCard.
<->
Bruce Carter, CBI Product Development bca...@claven.idbsu.edu
Simplot/Micron Instructional Technology Center amccarte@idbsu (Bitnet)
Boise State University, Boise, ID 83725 (208)385-1851@phone
James Logan
: So, getting to the point, I'd like to see some sort of effort to standardize
: the meanings of the icons used in computer software. It would be nice to
: create a sort of iconic dictionary and possibly an associated "grammer".
: Care should be taken to keep the "standard" from being too constrictive;
: ensuring free creative expression. This can only help both software users
: and creators by providing a bit more stability in a turbulent environment.
Just a note.
The Air Force had funded work for defining a standard symbol set (icons) to
be used on command and control displays. The purpose of this was to
define a common set of symbols / colors etc. that would be easy to
identify. This would allow officers to see information similarly on different
systems. Thus increasing their understanding, reducing training, and
reducing errors.
It seems to me that the general computing population could derive the
same benefits from standardizing icons. We are deriving benifits from
going towards standard GUIs. Standardized icons would be another step in
that direction.
ja...@cscns.com
James Logan
Ian Rogers
: So, getting to the point, I'd like to see some sort of effort to standardize
: the meanings of the icons used in computer software. It would be nice to
There *is* (was?) an icon standardisation effort. The last ISO
document I received is JTC 1/SC 18 N 3737 (a bit old I admit). The
working group involved is SC 18/WG 9. I guess more information can
be received from:
Secretariat ISE/IEC JTC1/SC 18
American National Standards Institute
11 West 42nd Street
New York
10036
(gee - a standards institute - what a suprise).
I found out about this by attending Paulien Strijland's "Icon
Design" tutorial at CHI'92. No doubt she'll run it again at CHI'94
Paulien is the chief mahooha at Apple's icon design center.
--
Ian Rogers - Research Fellow type person
School of Cognitive Science, Sussex University, Falmer, Brighton, UK
sobi...@lap.umd.edu
spag...@frinext.stanford.edu (Stefano Pagiola) writes:
>2. Clarity of representation.
[...]
>The second simply means that the icon should provide a fairly obvious
>representation of what using it produces. To some extent,
>consistency of use can over-ride this need, as in the paint example
>noted by Robert. In this context, Apple did the world a disservice
>by suing to prevent use of iconic representations it had developed
>(eg the trashcan), since it hindered the development of a common
>language.
Huh? How hard is it to come up with a different representation
of the functionality of a trash can? NeXT came up with a black
hole; I haven't heard of anyone complaining that it doesn't
make sense. I think that people aren't thinking broadly enough
when they assume that there's only one way to represent things
in a GUI. (Yes, this gets perilously close to the ancient
Windows/Mac flame fest, and I *don't* want to revive it. I
think there's a level of discussion above the level of simple
comparison between GUIs.)
Instead of trying to copy GUIs like Mac, Windows, Motif, etc.,
why don't people try and rethink the metaphor? The desktop
metaphor is getting pretty threadbare and is breaking down
in many areas on the Mac, and it never worked quite right
in many other OS's from the beginning. Let's find some other
way to work with information -- take a risk and make a
(comparatively) radical departure. Don't be intellecutally
lazy when you can't copy someone else's system! Standardize
icons within a system, by all means, but don't try and
standardize across systems when they're coming from radically
different perspectives.
-Blake Sobiloff (sobi...@lap.umd.edu)
Laboratory for Automation Psychology
Department of Psychology
University of Maryland, College Park
Jon von Tetzchner Stephenson
the icons are not standardized before a good representation has been found.
An example is the CCITT recommended icon set for supplementary services.
These icons are relatively difficult to understand, even for experts [Lindgaard 87].
There are 3 main problems with current icons:
1. They are not standardized.
2. They often do not follow a common metaphor.
3. They are often too small to be understood (e.g. MS-Windows icons).
If the icons followed a common metaphor, then it would be easier to deduct their meaning.
If a bad standard is chosen, then that will help frequent users as they will start to
recognize the icons, but it will not help infrequent users.
Personally I like systems where it is possible to get information about icons by either
entering them or clicking them. This avoids having to use larger icons, which take up more
screen space. All the information is given when needed.
[Lindgaard 87] G. Lindgaard, J. Chessari, E. Ihsen. "Icons in Telecommunications:
What makes pictorial information comprehensible to the user?"
A. T. R. vol. 21, no. 2, 1987
--
------------------------------------------------
********************************
* Jon Stephenson von Tetzchner *
* jo...@ifi.uio.no *
****** jo...@hal.nta.no *******
* jo...@unik.no *
******************
------------------------------------------------
Joseph Hall
>Robert Mah (rm...@panix.com) wrote:
>: So, getting to the point, I'd like to see some sort of effort to standardize
>
>The Air Force had funded work for defining a standard symbol set (icons) to
>be used on command and control displays. The purpose of this was to
>define a common set of symbols / colors etc. that would be easy to
This is interesting. Is this ongoing? Is there some relevant
material, examples, etc. that could be posted?
--
Joseph Nathan Hall | Thus, STDOUT isn't really the default filehandle for
Software Architect | printf(). It's merely the default default filehandle.
GORCA Systems Inc. | ----- jos...@joebloe.maple-shade.nj.us (home) -----
(on assignment) | (602) 732-2549 jnh...@sat.mot.com (work)
Stefano Pagiola
> >..In this context, Apple did the world a disservice
> >(eg the trashcan), since it hindered the development of a common
> >language.
>
> Huh? How hard is it to come up with a different representation
> of the functionality of a trash can? NeXT came up with a black
> hole; I haven't heard of anyone complaining that it doesn't
> make sense.
The NeXT's black hole has now become a recycle symbol. This actually
works pretty well, IMHO: the recycle metaphor is probably more
accurate than a trashcan since you can recover things from it until
you purge it.
> I think that people aren't thinking broadly enough
> when they assume that there's only one way to represent things
> in a GUI.
Yes, but the point is that you don't want to gratuitously change the
symbolic representation of something. If you think you've got a
better metaphor, then by all means adopt a suitable icon, even if its
different from other people's. But if you don't, then using
different icons to represent the same thing is only adding to
confusion and mental effort (which icons are supposed to minimize).
> Instead of trying to copy GUIs like Mac, Windows, Motif, etc.,
> why don't people try and rethink the metaphor?
Agreed. Without wishing to start a new flame-fest, I think NeXT did
this very well with their WorkSpace. But again, I return to my
original point: if you _want_ to do something differently because you
think its better that way, that's one thing. Its quite another to
_have_ to do it differently even though it isn't any better because
of some turf-protecting lawsuit.
David Gabrius
'radiation', and even mundane things like 'pedestrian in crosswalk'
(which, if I remember correctly, looks pretty similar around the
world) or the 'no' circle-and-slash? Who comes up with these as the
standard symbols for 'X'? They seem to have worked out pretty well in
the sense that once you've seen the biohazard symbol you know to
*avoid* anything with that symbol on it; however, some of the symbols
like the one for 'sensitive to static electricity' are not obvious
until explained.
What I'm trying to say is that maybe some sort of group (other than
the Air Force) can be asked for input/placed in charge of an effort.
I'd like to know some more about the design of existing symbols before
pushing forward into any sort of other standardization.
--
David Gabrius gab...@gem.valpo.edu
Pro Student, Computer Engineering perf...@imsa.edu (IMSA '90)
"And you can find/Your own way out/You can build/And I can will..." -U2
"You miss too much these days if you stop to think..." -U2 | PGP22 available
Blake Sobiloff
spag...@frinext.stanford.edu (Stefano Pagiola) writes:
>The NeXT's black hole has now become a recycle symbol. This actually
>works pretty well, IMHO: the recycle metaphor is probably more
>accurate than a trashcan since you can recover things from it until
>you purge it.
OK, OK, you're right; I guess I need to spend some time with
newer NeXT machines. :-)
>Yes, but the point is that you don't want to gratuitously change the
>symbolic representation of something. If you think you've got a
>better metaphor, then by all means adopt a suitable icon, even if its
>different from other people's. But if you don't, then using
>different icons to represent the same thing is only adding to
>confusion and mental effort (which icons are supposed to minimize).
I agree that change for change's sake should be avoided within an
environment. The issue becomes more difficult, however, when you
change environments. I'm comfortable with the way the Trash mechanism
works on a Mac, and I'll expect the same sort of behavior if I see
a similar-looking Trash icon on a Windows machine. However, *do*
they actually operate the same way -- exactly? If so, it's good
for the me, but it's also copying someone else's work. If it
doesn't, then it's not very good for the me, but that's something
I'll have to live with.
You have to keep in mind that certain protections are necessary
which, while they may not result in the most optimal arrangement
for the user, still do well for the user and provide an economic
incentive for original innovation.
>Agreed. Without wishing to start a new flame-fest, I think NeXT did
>this very well with their WorkSpace. But again, I return to my
>original point: if you _want_ to do something differently because you
>think its better that way, that's one thing. Its quite another to
>_have_ to do it differently even though it isn't any better because
>of some turf-protecting lawsuit.
Your argument is based on the idea that any other representation
of the same functionality won't be as good as the first expression.
I disagree. That's like saying you should be able to manufacture
sunglasses that look like Oakleys, and even say "Oakley" on the
temples, as long as you use a different font for the "Oakley"
logo. Oakley spent a lot of time and money defining themselves and
manufacturing their product; you shouldn't be able to swoop in
with your $10 imitations to profit from their efforts. However,
that doesn't stop you from making sunglasses that have similar
functionality as Oakleys, and they may even look a bit like
Oakleys. And, it also doesn't stop you from trying to license
the manufacturing technology from Oakley, either.
By the same token, Microsoft can make any GUI they want, but if
they're going to make their windows, trash cans, etc., look
substantially similar to the Finder's then they'll have to pay
for the privilege or make it look different. (Heck, who wants
to copy the Mac interface these days anyway? Like I said before,
it's getting pretty threadbare. But that's another thread...)
The point I'm trying to make is that an innovator should be
able to realize a profit from his efforts. If that means that
a competitor has to take a different approach to providing the
same functionality, so be it. They should be able to take
advantage of innovations since the original and produce something
that is at least different, and if not better at least equal in
functionality. There's plenty of room for innovation. IMHO,
as always...
Shane Morris
>...
>There are 3 main problems with current icons:
> 1. They are not standardized.
> 2. They often do not follow a common metaphor.
> 3. They are often too small to be understood (e.g. MS-Windows icons).
>If the icons followed a common metaphor, then it would be easier to deduct their meaning.
>If a bad standard is chosen, then that will help frequent users as they will start to
>recognize the icons, but it will not help infrequent users.
>...
An underlying issue which UI designers should be conscious of is "when is
it appropriate to use icons?" In our headlong rush to adopt WIMPS we are
in danger of using features like icons "because they were there" rather
than "because they were appropriate". Literally speaking, as icon is an
image of some real thing. The reason icons like a paintbrush in a
paint program (as mentioned initially by Robert Mah) is that they
represent something tangible.
Use of icons becomes questionable when there is no direct cognitive
mapping between the picture and the concept it is meant to represent.
Eg. the "running man" icon used in many systems nowadays to represent
"OK, do it" or "run it". Here is an example of using an icon to represent
an action or process - a bad thing as a general rule unless you have an
obvious representation (like a printer to represent "print it"). In the
"running man" case, the user is (presumably) supposed to look at the
image, consciously retrieve the word "run" and draw a connection between
their intention ("run this") and the icon. Apart from being Anglo-centric,
this asks too many cognitive steps of the user.
If the user has the word "run" (or synonym) in mind when they want to run
something, then an icon with the word "run" requires less processing than
a picture of a man.
An amusing and extreme example of this I saw once was an icon of what
looked like a tree branch. It was used to represent the action of
recording a user activity - Ie "log" it :-)
Shane.
--
Shane Morris Email: sh...@tusc.oz.au
TUSC Computer Systems Pty Ltd Phone: (03) 840 2222
666 Doncaster Road, Doncaster, Vic 3108 Australia Fax: (03) 840 2277
Rick Innis
sh...@yobbo.tusc.oz.au (Shane Morris) writes:
>An amusing and extreme example of this I saw once was an icon of what
>looked like a tree branch. It was used to represent the action of
>recording a user activity - Ie "log" it :-)
This reminds me of a system I once worked on. It was written in LISP,
and every so often the system would stop to garbage collect. TO the
user, it just looked the system stopped working for a minute or so,
then continued.
To try and give the user some control over this, an icon
was included on the control panel which them initiate garbage
collection when they wanted to -- for example, before going on a
coffee break. The icon? A coffee cup. The reaction? "Is this
system going to track how many coffee breaks we take?"
Anyone else got any "Icon horror stories" out there? Maybe we can
assemble a Canonical Collection...
--Rick.
--
Rick Innis
SoftQuad Inc. "Have you seen the secret of the Universe?" said
ri...@sq.com Zebedee, arriving. "I know I left it here somewhere."
+1 (416) 239 4801
jim bailey
>and every so often the system would stop to garbage collect. TO the
>user, it just looked the system stopped working for a minute or so,
>then continued.
>To try and give the user some control over this, an icon
>was included on the control panel which them initiate garbage
>collection when they wanted to -- for example, before going on a
>coffee break. The icon? A coffee cup. The reaction? "Is this
>system going to track how many coffee breaks we take?"
>Anyone else got any "Icon horror stories" out there? Maybe we can
>assemble a Canonical Collection...
The original Mac control panel used a tortoise and a hare to represent
keyboard repeat speed. The icons were used in a naive belief that
this would help in localization. Later they were removed because it
is discovered that in some countries they had not heard of Aesop's
fables. Words translate much better than ethnocentric icons.
Terran Boylan
Is there an FTP location for "universal symbols" of the above sort? I'm
especially interested in .gif,.jpg or SGI .rgb/.sgi images.
Mike Sellers
> Robert Mah writes
> > ...
> > When there _is_ some sort of standardization, the meaning of the
> > icons is unamiguous and easily recognizable. For example, on
> > the Macintosh, most graphics programs represent the color fill
> > function with a little paint bucket tilting slightly towards the
> > right with paint spilling out of it. This is, of course, a
> > somewhat arbitrary (though historically based) choice, however
> > because of it's generally accepted nature, anyone who has used
> > one paint program can use this feature in another with no
> > misunderstanding. If you have to sit there and ponder over the
> > meaning of an icon, it's not doing its job.
While I certainly agree with your conclusion --the meaning of an icon must
be immediately obvious-- your choice of the paint can as a supporting example
is ironic. I remember hearing that a person who was unfamiliar with computers
was a participant in a usability study on Macpaint and rated it very highly.
Her only real question was, "why do I click on the graduation cap to
color a shape on the screen?" The 'paint can' _is_ fairly arbitrary in
its representation, especially given that the product was intended for use
by those not familiar with computers. Its familiarity to you and me does
not mean it will be clear to others.
> I think effective use of icons requires one or both of two things:
> 1. Consistency of use.
> 2. Clarity of representation.
I would add, perhaps as part of clarity, immediacy and aesthetics.
An icon must be understandable _instantly_ (I'd _love_ to see a
forced-choice study on the meanings of various real-world icons -- any
takers???). However, it must also be graphically pleasing. We shouldn't
require that people puzzle out what we mean the first time they see an icon,
nor should we produce icons which are visually annoying after the first few
times they've been seen.
This means striking a balance between domain & application consistency,
immediate meaningfulness, uniqueness, and aesthetics, all within a small
square of pixels -- and maybe in monochrome! Hey, no one said it would
be easy. :-)
> ... To some extent,
> consistency of use can over-ride this need, as in the paint example
> noted by Robert. In this context, Apple did the world a disservice
> by suing to prevent use of iconic representations it had developed
> (eg the trashcan), since it hindered the development of a common
> language.
Note that Apple cannot (and did not try to) keep others from using _any_
representation of a trash can. They may be able to keep others from using
a similar bit pattern, and particularly one which bulges when full, but
such subtleties are, I believe, lost on most users. A monochrome trashcan
(Apple), a full color one with flies around it (ICS), an industrial trash
bin (SGI), and a 3D one (ISG) are all going to say "trashcan = get rid of
things" to most users. The common symbology (not a language, folks) hasn't
really been constrained.
> Even with these requirements being met, however, it is not clear to
> me that icons are a viable long-term avenue for development. We don
> not want to end up reinventing the Chinese language and all be forced
> to learn several tens of thousands of symbols.
Let's not overstate the problem. We don't have the need for many of the
types of symbols which are needed in a full-fledged language. Most software
icons represent tools, activities, and states. Few if any represent abstract
verbs, adjectives, etc. Further, icons need not be static as are Chinese
characters. A slider bar is in some ways iconic, but it's dynamism adds a
great deal to its meaningfulness. I don't think the explosion of the number
of icons is the problem -- poorly conceived and designed user interfaces is.
--
Mike Sellers User Interface Team Leader
mi...@isgtec.com ISG Technologies, Toronto, Canada
"Actum ne agas" -- Do not do what has been done.
Furare tantum ab Optimis
gca...@state.systems.sa.gov.au
[stuff deleted]
> 1. They are not standardized.
> 2. They often do not follow a common metaphor.
> 3. They are often too small to be understood (e.g. MS-Windows icons).
>
[stuff deleted]
> Personally I like systems where it is possible to get information about icons by either
> entering them or clicking them. This avoids having to use larger icons, which take up more
> screen space. All the information is given when needed.
>
Has anyone seen the Borland Paradox interface? When you move the mouse over
an icon a description of what it does appears on the status bar at the
bottom left of the screen. Personally I find this an elegant solution to
the confusion of strange icons (especially those in MS Project)
Just my 5c (2c no longer exist in OZ)
I\
Kerry I \ But if I lean out
I \ any further
___________________________________ I*--\ I'll fall out!!!
gca...@state.systems.sa.gov.au OR I \
9018...@lv.levels.unisa.edu.au I \
----------------------------------- I______\
(Standard Disclaimer) _____I__O______
\ ( ) b ^ ^
^^^^^^^^^^^^^^^^^ ^
_____/\____/| ^
YUM >____,\---` \
Benbuck Nason
>looked like a tree branch. It was used to represent the action of
>recording a user activity - Ie "log" it :-)
My favorite is in the game Lemmings. There is a button with the image
of two animal footprints -> paws -> pause. Very cute.
-Ben
--
Benbuck Nason ben...@mri.com to...@cats.ucsc.edu
"I start to think, and then I sink / into the paper, like I was ink.
When I'm writing I'm trapped in between the lines;
I escape when I finish the rhyme." - Eric B. and Rakim, "I Got Soul"
Mike Causer
: Anyone else got any "Icon horror stories" out there? Maybe we can
: assemble a Canonical Collection...
In a CAD system known as Drafting/3000 in 1984 I made the cursor change
into a skull and crossbones when it was supposed to be in a menu but
the user had dragged it out to an area where it was not going to
react. This was intended to mean "danger", but when the program got to
Germany it was taken to be a reference to the S.S. and it was hurriedly
changed to something else.
In the same system there was an icon representing a change to the
background colour. This was essentially the text "3 degrees K", a
reference to the background temperature of the universe which most
users probably never understood. Not one of my better ideas ;-(
We also managed to get the function of an Alert Box implemented as a
"Lert Box" as a jokey reference to the old graffito "Be alert - your
country needs lerts" from WWII England. No-one spotted this, or at
least no-one complained, so it stayed there for the life of the product.
Mike Causer Computervision R&D Ltd, Cambridge, England
Gee-Kay Wong
I do not know if this is general knowledge but there is a
International Standards Organisation Committee Draft (CD) on the
subject of icons. This is ISO/IEC 11581, it is planned to include
the following parts:
ISO/IEC 11581-1: Interactive Icons - General
ISO/IEC 11581-2: Object Icons
ISO/IEC 11581-3: Pointer Icons
ISO/IEC 11581-4: Control Icons
ISO/IEC 11581-5: Tool Icons
ISO/IEC 11581-6: Status Indicator Icons
To date, I have seen parts 1 and 2.
--------------------------------------------------------------
GEE-KAY WONG Internet: gee...@dcs.qmw.ac.uk
Research Associate UUCP: gee...@qmw-dcs.UUCP
Human-Computer Interaction Lab. tel: +44 (0)71 975 5246
Dept. of Computer Science fax: +44 (0)81 980 6533
Queen Mary & Westfield College
University of London
Mile End Road
London E1 4NS, UK
Risto Virtanen
sh...@yobbo.tusc.oz.au writes:
>Eg. the "running man" icon used in many systems nowadays to represent
>"OK, do it" or "run it". Here is an example of using an icon to
represent
>an action or process - a bad thing as a general rule unless you have an
>obvious representation (like a printer to represent "print it"). In the
>"running man" case, the user is (presumably) supposed to look at the
>image, consciously retrieve the word "run" and draw a connection between
>their intention ("run this") and the icon. Apart from being
Anglo-centric,
>this asks too many cognitive steps of the user.
>
>If the user has the word "run" (or synonym) in mind when they want to
run
>something, then an icon with the word "run" requires less processing
than
>a picture of a man.
run an application corresponds to the verb 'to drive' in English.
So the image of running man conveys hardly any meaning in this case.
Aren't icons supposed to alleviate or eliminate the need for translation
and localization?
Roisto
Ken Badertscher
|In article <1vr7tv...@yobbo.tusc.oz.au> sh...@yobbo.tusc.oz.au (Shane Morris) writes:
|>An amusing and extreme example of this I saw once was an icon of what
|>looked like a tree branch. It was used to represent the action of
|>recording a user activity - Ie "log" it :-)
|My favorite is in the game Lemmings. There is a button with the image
|of two animal footprints -> paws -> pause. Very cute.
The terminal program I'm using right now has an icon of a butterfly net to
indicate "capture", and a windshield wiper over a monitor to indicate "clear
screen", a cassette tape to indicate "playback", and an LP with phonograph
needle to indicate "record". Arrrggghhh! Oh, and a jogger, like the one
mentioned elsewhere in this thread appears in this toolbar, too.
I often wish that software graphic artwork would be more often left to
graphic artists.
--
Ken Badertscher I need something...
kb...@netcom.com, kb...@taligent.com ...I just don't know what it is.
Anders Thulin
>Eg. the "running man" icon used in many systems nowadays to represent
>"OK, do it" or "run it". Here is an example of using an icon to represent
>an action or process - a bad thing as a general rule unless you have an
>obvious representation (like a printer to represent "print it"). In the
>"running man" case, the user is (presumably) supposed to look at the
>image, consciously retrieve the word "run" and draw a connection between
>their intention ("run this") and the icon. Apart from being Anglo-centric,
>this asks too many cognitive steps of the user.
Heh. The icon used in TeleUSE to indicate a place where dragged items
can be dropped is a dragon. Drag-on ....
Sigh.
--
Anders Thulin a...@linkoping.trab.se 013-23 55 32
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
Mike Sellers
: The terminal program I'm using right now has an icon of a butterfly net to
: indicate "capture", and a windshield wiper over a monitor to indicate "clear
: screen", a cassette tape to indicate "playback", and an LP with phonograph
: needle to indicate "record". Arrrggghhh! Oh, and a jogger, like the one
: mentioned elsewhere in this thread appears in this toolbar, too.
: I often wish that software graphic artwork would be more often left to
: graphic artists.
At first I read this as "I often wish that software graphic artwork would
be more often left to more than graphic artists." Then I realized that
that was not what Ken was saying at all!
Ken, is it the quality of the graphic you're complaining about, or the
applicability of the graphic to the application? I've seen well-rendered
yet cognitively egregious examples of icons created by graphic artists,
and poorly-rendered good ideas for icons created by engineers, but rarely
have I seen a situation where a nicely graphic icon with no cognitive "fit"
was created by someone who was not a graphic artist.
IMHO, graphic artists with no knowledge of the application, the user,
or computer use in general are more likely to be the source of the kinds
of horrendous icons you mention -- and this is often what happens when
someone picks up the phone and hires a graphic artist to come in and do
cosmetic surgery on their application. For my part, I'd like to see icon
creation more often left to those who are actually usability specialists --
encompassing a knowledge of graphic art, psychology, computer use, and
domain knowledge.
Gee-Kay Wong
In article <50...@isgtec.isgtec.com> Mike Sellers,
mi...@isgtec.com writes:
> -- and this is often what happens when someone picks up the
> phone and hires a graphic artist to come in and do cosmetic
> surgery on their application.
"Cosmetic surgery", a nice metaphor. As in cosmetic surgery
is there enough care and attention to the underlying reasons
for why changes are required both by the client and the
"surgeon"? How important are your looks?
>For my part, I'd like to see icon creation more often left
to
>those who are actually usability specialists -- encompassing
a
>knowledge of graphic art, psychology, computer use, and
domain
>knowledge.
These are, normally, very divergent and differing classes of
skills. I would like to know how often these are found in one
individual "out there". I would personally like to boost the
design/graphic art side of things for myself. But does this
entail retraining, a hobby interest, experience (e.g. seeing
lots of GUIs) or something known as "talent"?
-----------------------------------------------------------
Dave Roberts
the team that understands the whole problem. That way their artistry
will be applied to a metaphor that compelements the program. They
are also normally pretty good (well trained at) spotting those cases
where a metaphor would only apply to some nationalities.
+---------------------------------------------------------------------+
| Dave Roberts - OOUIs R US |
+---------------------------------------------------------------------+
Andrew Gilmartin
jnh...@sat.mot.com writes:
> This is interesting. Is this ongoing? Is there some relevant
> material, examples, etc. that could be posted?
One of my favorite source books is Henry Dreyfuss' *Symbol sourcebook.*
It contains sets of symbols used throughout the world. Some sets are
very well know, such as the Olympics' events, while other, such as the
hobo signs, are real finds. I don't know if the book has been updated
since its publication in '72, but it is still a great source.
-- Andrew
--
Andrew Gilmartin
Computing & Information Services
Brown University
Andrew_G...@Brown.Edu
(401) 863-7305
Scott McGregor
> For my part, I'd like to see icon
> creation more often left to those who are actually usability specialists --
> encompassing a knowledge of graphic art, psychology, computer use, and
> domain knowledge.
The problem is that there is no single identifiable field for this grouping--
it requires several. So there is no specific title, or educational background
or association you can point to that people belong to that is composed
uniformly of people with all the relevant skills.
Additionally, there is a distinction between art and applied art. I know that
many commercial artists used to distinguish themselves from "pure" artists by
calling themselves illustrators, or such--but this distinction seems to be
infrequently made today.
The same problem occurs in advertising and also in physical artifact design.
You can see aesthetically beautiful results that don't convey the meaning
or function intended. But very good commercial artists and very good industrial
designers DO pay attention to meaning and function and part of what is pleasing
about their work is so tightly interwoven the aesthetic and functional aspects
are.
I find it interesting how readily people think of applying graphic artists to
making GUIs, but how little they think of applying industrial designers. As
someone who used to run a graphic design and printing company and who has
also designed software for 20 years, I am acutely aware of the limitations of
the graphic design training, and I would like to see more industrial design
knowledge applied as well.
---
Scott L. McGregor tel: (408) 985-1824
President fax: (408) 985-1936
Prescient Software, Inc. email: mcgr...@netcom.com
3494 Yuba Avenue, San Jose, CA 95117
Prescient Software offers software, consulting and training in
software process, project management and usability.
Terry
> ben...@mri.com (Benbuck Nason) writes:
>
> |In article <1vr7tv...@yobbo.tusc.oz.au> sh...@yobbo.tusc.oz.au (Shane Morris) writes:
> |>An amusing and extreme example of this I saw once was an icon of what
> |>looked like a tree branch. It was used to represent the action of
> |>recording a user activity - Ie "log" it :-)
>
> |My favorite is in the game Lemmings. There is a button with the image
> |of two animal footprints -> paws -> pause. Very cute.
>
> The terminal program I'm using right now has an icon of a butterfly net to
> indicate "capture", and a windshield wiper over a monitor to indicate "clear
> screen", a cassette tape to indicate "playback", and an LP with phonograph
> needle to indicate "record". Arrrggghhh! Oh, and a jogger, like the one
> mentioned elsewhere in this thread appears in this toolbar, too.
>
> I often wish that software graphic artwork would be more often left to
> graphic artists.
The problem is not the artwork creator but the specifier. Artwork is best
created by graphic artists, but they should not specify what the icon
is depicting. When specifing icons, a linguist or psychologist would be
more appropriate.
Terry
--
---------------------------
Terry Raymond
Mystech Associates, Inc.
438 East Main Rd.
Craig Oshima
>> ben...@mri.com (Benbuck Nason) writes:
>> I often wish that software graphic artwork would be more often left to
>> graphic artists.
>The problem is not the artwork creator but the specifier. Artwork is best
>created by graphic artists, but they should not specify what the icon
>is depicting. When specifing icons, a linguist or psychologist would be
>more appropriate.
Not true. Icons should be specified by the users, be they artist, physicist,
or monk (not that I know of any monastery applications ;-) Icons ride on
the power of metaphor, and no one can conceive of better metaphors than
the user. Linguists and psych folks might be more *in tune* with what users
want in icons (and in applications), but they sure don't have any kind of
special insight that allows them to come up with better icons.
Artwork is best done by artists. Human factors is best done by human factors
specialists. Development is best done by developers. Icons (and the most
appropriate metaphor) is best specified by the user of the target market.
At its best, icon design is a collaborative process.
Of course, now that I re-read the very quote I felt I needed I correct, I see
that it's likely that I was casting stones out of line. Terry is right that
artists should not be responsible for specifying icons...for the same reasons
I already evangelized about, and wouldn't dare do again (in the same post =)
Sorry, Terry. (I didn't just ding my post altogether however, since I feel
the lesson is an important one, and many organizations don't really understand
that.
Craig R. Oshima
Applications Developer / HF Engineer
614/792-1761
Stuart Corner
Surely not! If you leave the user to define icons then there is a much greater
problem. The machine then becomes the personal possesion of the primary user.
When that user is "out of the office" and information has to be accessed, then
a secondary user must "learn" a new set of icons. If all machines use the same
icons for the same applications and functions (in a given environment) then
there is little ambiguity. Consistency is the key. OK so this goes against the
grain of HMI, but it seems fairly sensible to me. I would invent bizarre icons
given the opportunity, as I invent bizarre relationships as a memory aid.
Or have I completly got hold of the wrong end of the stick?
--
*************************************************************************
* WHEN GOD CREATED THE WORLD HE Stuart Corner *
* SPOKE. BSc Computer Science. Yr1 *
* HE DIDN'T USE E-MAIL Brighton University. *
*************************************************************************
Stefano Pagiola
> cos...@s.psych.uiuc.edu (Craig Oshima) writes:
>>> I often wish that software graphic artwork would be more often
>>> left to graphic artists.
>>
>> artist, physicist, or monk (not that I know of any monastery
>> applications ;-) Icons ride on the power of metaphor, and no
>> one can conceive of better metaphors than the user. Linguists
>> and psych folks might be more *in tune* with what users want
>> in icons (and in applications), but they sure don't have any
>> kind of special insight that allows them to come up with
>> better icons.
>
> a much greater problem. The machine then becomes the personal
> possesion of the primary user. When that user is "out of the
> office" and information has to be accessed, then a secondary user
> must "learn" a new set of icons. If all machines use the same
> icons for the same applications and functions (in a given
> environment) then there is little ambiguity. Consistency is the
> key. OK so this goes against the grain of HMI, but it seems fairly
> sensible to me. I would invent bizarre icons given the opportunity,
> as I invent bizarre relationships as a memory aid.
I agree with you, but I think Craig had in mind a generic `user' (as
opposed to a generic `artist') rather than an individual user.
Terry Greeniaus
` cos...@s.psych.uiuc.edu (Craig Oshima) writes:
` > te...@zoe.network23.com (Terry) writes:
` > >> ben...@mri.com (Benbuck Nason) writes:
` >
` > >> I often wish that software graphic artwork would be more often left to
` > >> graphic artists.
` >
` > >The problem is not the artwork creator but the specifier. Artwork is best
` > >created by graphic artists, but they should not specify what the icon
` > >is depicting. When specifing icons, a linguist or psychologist would be
` > >more appropriate.
` >
` > Not true. Icons should be specified by the users, be they artist, physicis
` > or monk (not that I know of any monastery applications ;-) Icons ride on
` > the power of metaphor, and no one can conceive of better metaphors than
` > the user. Linguists and psych folks might be more *in tune* with what user
` > want in icons (and in applications), but they sure don't have any kind of
` > special insight that allows them to come up with better icons.
` >
` > Artwork is best done by artists. Human factors is best done by human facto
` > specialists. Development is best done by developers. Icons (and the most
` > appropriate metaphor) is best specified by the user of the target market.
` > At its best, icon design is a collaborative process.
` >
` > Of course, now that I re-read the very quote I felt I needed I correct, I s
` > that it's likely that I was casting stones out of line. Terry is right tha
` > artists should not be responsible for specifying icons...for the same reaso
` > I already evangelized about, and wouldn't dare do again (in the same post =
` > Sorry, Terry. (I didn't just ding my post altogether however, since I feel
` > the lesson is an important one, and many organizations don't really underst
` > that.
` >
` > Craig R. Oshima
` > Applications Developer / HF Engineer
` > 614/792-1761
`
` Surely not! If you leave the user to define icons then there is a much greate
` problem. The machine then becomes the personal possesion of the primary user.
` When that user is "out of the office" and information has to be accessed, the
` a secondary user must "learn" a new set of icons. If all machines use the sam
` icons for the same applications and functions (in a given environment) then
` there is little ambiguity. Consistency is the key. OK so this goes against th
` grain of HMI, but it seems fairly sensible to me. I would invent bizarre icon
` given the opportunity, as I invent bizarre relationships as a memory aid.
`
` Or have I completly got hold of the wrong end of the stick?
` --
`
`
` *************************************************************************
` * WHEN GOD CREATED THE WORLD HE Stuart Corner *
` * SPOKE. BSc Computer Science. Yr1 *
` * HE DIDN'T USE E-MAIL Brighton University. *
` *************************************************************************
I think what Craig is trying to say is that the user's will all use a
certain type of interface that they like. By seeing what types of icons
the user's like best and find easiest to comprehend, developers can then
use those same Icons in all the places that they are relevant. I agree
completely that if every user could invent his own Icons it would be ...
well, Chaos! It's also important that all developers agree on a set that
would be easy for everyone to understand, including beginners, etc. If
the Macintosh had a set of standard Icons for functions and other
commands then it would be much less intimidating for someone who doesn't
use his computer much to learn a new program. For example in Dos (not
that I'm a IBM advocate) all the main things that a user could do where
the same and most programs where pretty intuitive (albeit they only had
text (usually) and didn't have to worry about a set of Icons). I think
that a standard set of icons (and a standard interface which is easy to
understand and learn) would make the Macintosh a much more popular
computer because then anyone could intuitively do what they want to do
and then get what they want out of it. It's not worth people's time to
read a 400 page manual just to figure out how to print your document!
Well, just my 2 bits....
Terry Greeniaus
--
Terry Greeniaus tgr...@ersys.edmonton.ab.ca
Mike Sellers
: >> I often wish that software graphic artwork would be more often left to
: >> graphic artists.
: >The problem is not the artwork creator but the specifier. Artwork is best
: >created by graphic artists, but they should not specify what the icon
: >is depicting. When specifing icons, a linguist or psychologist would be
: >more appropriate.
: Not true. Icons should be specified by the users...
Hoo! Here we have the classic who-does-UI-design debate contained in
just a few lines!
There are problems with each of these strident statements:
Graphic designers often do not have enough knowledge of computers, the
application domain, the specific program, the rest of the UI, or the users'
tasks to create icons which are cognitively transparent (that is, those
which can be understood as soon as attention is focused on them).
Linguists and psychologists, on the other hand, rarely have enough
understanding of how to represent concepts concisely in graphics (or
in text :-) ), and often suffer from the same deficiencies as graphic
designers in areas like knowledge of computer use, the domain, or the
rest of the UI. Further, asking a linguist or psychologist to specify
the "correct" icon which a graphic designer will then create presumes
that the function of the thing can be separated from the form, when in
fact icons *must* have their form and function seamlessly blended.
Thus there is a need for incredibly rich communication between these two
individuals, neither of whom speaks the other's language nor understands
their needs. This is a recipe for confusion and paralysis.
Lastly, the idea of having users design the icons is a seemingly noble
one which both appears to adhere to the paradigm of user-centered design
and absolves the product designers of all responsibility in the matter.
Unfortunately, users are no more endowed with a clear knowledge of what
they need, much less how to represent it clearly, than is anyone else.
Asking the users to design their own icons will set before them a task
for which they are not trained, for which they have little desire, and
which ultimately distracts them from getting their work done.
Clearly, this classical, analytical approach to icon (or UI) design does
not work. What is needed here is a synoptic approach: An icon designer
must have knowledge of graphic art, so that they can actually create icons.
They must understand how people perceive, attend to, and think about icons
and other symbolic forms so they can create the right representations in
their icons. Finally, they must have some understanding of the application
domain, the users' environment, and the visual and computational context in
which the icons will appear so that they are appropriate to the user's needs.
In short, they must be trained in graphic arts, cognitive (and to a lesser
degree linguistic, social, and organizational) psychology, and software
engineering. On top of all of this, such individuals must possess
creativity and the ability to listen to others and give form to their ideas.
Some have asserted that such a mix of skills is vanishingly rare. I do
not believe this is the case. Such people, sometimes called usability
specialists, UI designers, etc., are still hard to find, but they are
becoming more common.
For an excellent article (okay I'm biased, being part of the 'et al')
outlining the skills needed for this kind of activity, see "Skills Needed
by User-Centered Design Practitioners in Ral Software Development
Environments" by Tom Dayton (et al) in this July's SIGCHI Bulletin.
Marta Lyall
>just a few lines!
>
>There are problems with each of these strident statements:
>
edited ---
>Graphic designers often do not have enough knowledge of computers, the
>application domain, the specific program, the rest of the UI, or the users'
>tasks to create icons which are cognitively transparent (that is, those
>which can be understood as soon as attention is focused on them).
>
It it is possible to find graphic designers with the ability to
integrate all of these concerns. If UI design could attract more
graphic designers at the same level of professional achievement as the
senior design engineers who design the software, we would likely see
more successful design. As it is, a talented graphic designer can make
a lot more money and get more professional recognition doing other
things.
In any case, a sucessful set of icons is most likely to be designed by
someone who has been participating in the development of a project from
the beginning. This may not describe the typical graphic designer.
Desiree Sy
>Hoo! Here we have the classic who-does-UI-design debate contained in
>just a few lines!
>[....]
>Clearly, this classical, analytical approach to icon (or UI) design does
>not work. What is needed here is a synoptic approach: An icon designer
>must have knowledge of graphic art, so that they can actually create icons.
>They must understand how people perceive, attend to, and think about icons
>and other symbolic forms so they can create the right representations in
>their icons. Finally, they must have some understanding of the application
>domain, the users' environment, and the visual and computational context in
>which the icons will appear so that they are appropriate to the user's needs.
>In short, they must be trained in graphic arts, cognitive (and to a lesser
>degree linguistic, social, and organizational) psychology, and software
>engineering. On top of all of this, such individuals must possess
>creativity and the ability to listen to others and give form to their ideas.
>
>Some have asserted that such a mix of skills is vanishingly rare. I do
>not believe this is the case. Such people, sometimes called usability
>specialists, UI designers, etc., are still hard to find, but they are
>becoming more common.
Excellent points all. Two things to add.
First, that user input certainly *can* be obtained on icon
design, in precisely the same way that it is obtained with
respect to interface design. Certainly we should not expect
users to act as designers -- but they can *react* to designs.
I've successfully usability tested icons and graphics, not to
mention page layouts. The point is to have something to test --
and those designs should be done by a designer.
Second, that another approach which has worked for me is to work
in concert with a graphic designer. After the user and task
analyses are done, I've sat down with programmers and the graphic
designer to convey relevant information -- including
organizational and psychological data discovered while mapping
out user profiles. With that knowledge, we can draft rough paper
prototypes of both interface and graphic elements. These can
then be field tested under controlled conditions by the usability
specialist. More detailed findings and reactions are then taken
back to the team.
The point I'm trying to make is that while the neatest solution
is to have all the skills in one spot, the team approach is still
extremely viable. The trick is to establish each member's
responsibilities -- each person should contribute those skills
which she or he does best.
-desiree
Dave Anderson
interfaces. Pixels are just another medium. I also architect, design
and develop code. Code is just another medium. It's all art.
Just as there is art that is bizarre, that not everyone "gets", there
are interfaces, icons and programs that are bizarre, that not everyone
"gets". In the world of marketing, successful (ie: useful) products
appeal to the mainstream. Some are better than others at hitting that
resonant chord with people. Nothing to argue about - that's just the
way it is.
I see human factors as an embodiment of "accepted" practices, some
guidelines about how people like to work and interact. If you are good
at designing interfaces and icons, great. If you aren't, find someone
who is. Its all subjective, really. Nobody can predict absolutely how
others will react; it depends on where the audience is coming from.
And after all, icon design is fun. Pixels are very forgiving.
- Dave
Robert Mah
>Just as there is art that is bizarre, that not everyone "gets", there are
>interfaces, icons and programs that are bizarre, that not everyone "gets".
>...
>I see human factors as an embodiment of "accepted" practices, some
>guidelines about how people like to work and interact.
>...
>Its all subjective, really. Nobody can predict absolutely how others
>will react; it depends on where the audience is coming from.
Although you are right that a "good" interface design is somewhat
subjective in nature, I don't agree that guidelines should be simply
`"accepted" practices`. Some guidelines should be, in my view, more of
a philosophy of practice.
For example, some good guidelines that can be followed include...
1. Consistancy - within and between programs.
2. Precdictability - the interface acts as the user expects it to.
3. Clarity - avoid gratuitous elements (Bauhaus school :-)
4. Navigability - provide cues to tell the user "where" he is
5. Unifying Theme - that old nasty "paradigm" word.
6. Test, Test, Test - and test some more.
7. Etc.
Conforming to some of these guidelines may meen sucking it in and
using what, to you, is an ugly icon or something that might not quite
"fit"...but if it makes things easier for the vast majority of users,
that is, IMHO, what you should do.
Cheers,
Rob
--
---------------------------------------------------------------------
Robert S. Mah | Voice: (212) 947-6507 | "Every day an adventure,
One Step Beyond | EMail: rm...@panix.com | every moment a challenge."
Terry
> Craig Oshima (cos...@s.psych.uiuc.edu) wrote:
> : te...@zoe.network23.com (Terry) writes:
> : >> ben...@mri.com (Benbuck Nason) writes:
>
> : >> I often wish that software graphic artwork would be more often left to
> : >> graphic artists.
>
> : >The problem is not the artwork creator but the specifier. Artwork is best
> : >created by graphic artists, but they should not specify what the icon
> : >is depicting. When specifing icons, a linguist or psychologist would be
> : >more appropriate.
>
> : Not true. Icons should be specified by the users...
>
> Hoo! Here we have the classic who-does-UI-design debate contained in
> just a few lines!
>
> There are problems with each of these strident statements:
>
> Graphic designers often do not have enough knowledge of computers, the
> application domain, the specific program, the rest of the UI, or the users'
> tasks to create icons which are cognitively transparent (that is, those
> which can be understood as soon as attention is focused on them).
>
> Linguists and psychologists, on the other hand, rarely have enough
> understanding of how to represent concepts concisely in graphics (or
> in text :-) ), and often suffer from the same deficiencies as graphic
My, not stated, premise was that the Icons were to be used by a wide
variety of users, as would be for a word processor or spreadsheet.
The premise was based on previous postings that discussed the way
different cultures or subcultures interpret phrases and Icons.
Such supermen are hard to find. This is a classical engineering problem.
Engineering organizations have found it effective to have a domain expert,
or system engineer, specify the product functionality and the designer
create the design. When this is done the people involved only need to
know how to communicate in the other person's domain, which generally is a
lot less demanding than completely understanding the domain.
>
> Some have asserted that such a mix of skills is vanishingly rare. I do
> not believe this is the case. Such people, sometimes called usability
> specialists, UI designers, etc., are still hard to find, but they are
> becoming more common.
>
> For an excellent article (okay I'm biased, being part of the 'et al')
> outlining the skills needed for this kind of activity, see "Skills Needed
> by User-Centered Design Practitioners in Ral Software Development
> Environments" by Tom Dayton (et al) in this July's SIGCHI Bulletin.
>
To summarize, the Icons should be specified by a someone who knows how the
users will interpert the Icons. If the distribution of the users culture
is broad then someone like a linguist should be involved, if it is narrow
then a simple domain expert should only be necessary.
Technically Sweet
This thread has gone far enough. Could y'all take it alt.flame?
--
Lance Norskog
thi...@netcom.com
Data is not information is not knowledge is not wisdom.