[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep Icons and look proposal
|
From: |
Quentin Mathé |
|
Subject: |
Re: GNUstep Icons and look proposal |
|
Date: |
Sat, 21 Aug 2004 17:35:38 +0200 |
Le 20 août 04, à 20:47, M. Uli Kusterer a écrit :
Hi Uli,
2.3 (...)
You should never create icons directly in contact with the border of
their
frames, because in many cases an icon can be side by side with other
icons,
like in a toolbar or a dock-like application.
Don't do that. Let the designers use the full size of their icon
graphic, and make the application that displays the icon add the border
when drawing. Having empty space in icons is simply a waste of pixels
that need to be compressed, and the application designer has to
calculate a rectangle for the icons anyway.
Also, MacOS X icons don't include any "breathing space" either, which
means it'll be easier to port an application if you don't include it
either. One less metric to worry about customizing for OS X.
I think I disagree with you…
First what you said is not true, most Mac OS X icons include a
"breathing space", it is even an implicit rule for an application icon
which can be placed in the Dock, otherwise Dock icons would be in
contact when they are side by side.
Anyway we need a rule here, to avoid the Mac OS X problem where most
icons have a "breathing space" and some haven't, and I think it is a
better rule to said to the icon designer that the icons shouldn't be in
contact directly with their frame than the reverse; moreover to have a
"breathing space" will help to port Mac OS X applications, because it
is an implicit rule with Mac OS X icons as I said.
3.1 Perspectives
2D icons are a better choice when you display a lot of similar icons,
(...)
Thus, GNUstep icons should use a 3D view for
important or relatively rare icons like the applications icons or the
locations related icons such as a home directory, a hard disk, a
server
(WebDav, FTP, etc.), a camera... Very common and repetitive locations
related
icons like a standard folder should be represented with a 2D view but
must
then use a 30 degrees counter-clockwise rotation (so they still
stand-out in
comparison of other icons).
I like the idea, but this will result in a very odd mish-mash of
perspective on the desktop. I'd suggest only changing the perspective
for icons depending on where they will be used. E.g. on OS X, toolbar
icons are supposed to be flat as if sitting on a shelf, while file and
folder icons (and volumes, cameras, ...) have more perspective so they
look like they're on a great plain. However, documents are usually
fully
frontal, while applications are viewed more at an angle, and contain
some sort of "tool".
I disagree here also, because the Mac OS X icons perspectives is way
more odd mish-mash than the rules we propose. The problem with Mac OS X
icons is there is no strong rules outside the toolbar and document
icons cases, then everybody is playing with perspective. Font Book
application icon, Folder icon, Hard disk icon etc. are using 3d
perspectives but which are really not identical, and that is just basic
examples, contrary to our proposition where we have one 3d perspective
and one 2d perspective.
I must said also, our goal is not to copy Mac OS X Aqua guidelines, we
have just tried to study their errors which are numerous in my opinion
and also to retain the nice ideas they have developed.
Also, I would get rid of the 30-degree folder icons. Find some other
way, like making them more plain and simple, using only a few colors,
while making more important and less common icons more detailed and
interesting.
As it explained, in our guidelines, the shape variations is the most
efficient way to speed the icons perception, especially at small size
like 16*16. We could also use vivid colors like red to mark the folder
icon but I don't think it is a good idea to have red folders even
without considering color perceptions problems which affect many peole.
As such in my opinion, I think we have with the "30 degrees folder
icons", the most distinctive shape possible when mixed with documents
icons, then it is currently the best solution I can think of,
especially when you consider the fact it will still be less "intrusive"
than applications icons when the icon view (32*32 size or more) is
used, this is also important.
Having some icons returned and others not makes it harder to
distinguish objects.
As I said just over, in my opinion it makes the difference very clear
between the icons.
In Germany, folders already look nothing like
folders in the US do. We have special "hanging register" folders that
look vaguely like US folders, but they're only used in very old
offices,
and as such many people will take a while to recognize them. Stylizing
and turning them by 30 degrees will make them even harder to recognize.
The same problem then apply to Mac OS X, where the folder icons are
represented in a way which I have never seen in the real world.
Moreover it is not a problem related to our guidelines but more to the
largely accepted way to represent folder icons in the actual desktop
environments.
If you think we should replace the folder semantic with something else
or you have ideas on a new way to represent folders which would be
universal, we would be happy know more on that…
I'd also suggest you change "2D view" to be more like "sitting on a
shelf", which will look much cooler because it would still have a
shadow
at the bottom.
Any other icons like the documents icons, the toolbar icons and the
buttons
icons should use a 2D view.
(Nevermind the following -- just noticed chapter 7 covers this)
Might be useful to mention what to do for an icon that is *both* an
important location *and* shows up in a toolbar. Like a toolbar that
contains all hard disks, for example. Have two separate icons for that?
Allow the 3D icon? The latter would give more consistency, as the same
object always has the very same icon, while the former would look a
little better because of matching perspective among items in a toolbar
or a workspace window.
We will add a note in the chapter 3 to precise that section 7.1 covers
that.
3.2 (...)
The icons which triggers a potentially destructive action should be
partially
red. The icons which triggers a exceptional or really special action
should
be partially yellow.
"exceptional or really special" ... could you clarify? Provide some
examples of what is, and what isn't special?
You are right, we should add some examples, it will be done.
4.1
What does "just over" mean? Do you mean "the recommendations described
above"? Or do you mean "right on top of each other"?
May be we should change that for "the recommendations described above",
because it would be more correct.
I'd also offer an additional guideline:
If an application is sufficient in itself and doesn't create any
documents, or only converts between two file formats, but doesn't
really
offer editing them, don't show the "photo" at the right, and only have
a
tool in the icon, or if that doesn't work, make the "photo" or whatever
smaller and less important-looking.
If the application works with/on documents, OTOH, you should prefer
some kind of sheet (photo, sound wave on a piece of paper, etc.)
slanted
to the left. That way, the icon will already give a little indication
whether this is a droplet/tool, or whether this is a document-editing
application. This'll help give the user the right expectations when
opening the application.
We will study this suggestion, it could be interesting.
5. (...)
Example : A web browser called "Duck" shouldn't use a duck
representation for
its icon.
Is it okay to have a duck somewhere in the icon, to at least tie the
icon to the app's name a little? You may want to mention explicitly if
yes or no. I personally would say, you should be allowed to do a little
branding, like having the icon be a duck balancing a globe, or a web
page with the picture of a suck and some text on it, or whatever you'd
use for a browser.
Nice remark, we will take that in account and probably make our rule
less restrictive and more precise.
€ Don't use text words in the icons, this recommandation is
related to
the previous one . Take in account that icons would be difficult to
translate, and harder to read than in the label. When you want use
text in
the icon, don't use real words in a specific language (or use a
dead
language like latin).
Example :
My favorite example was always Photoshop, though QuickTime and Windows
media player, IIRC, also have the bad habit of using a generic "media
file" icon that is badged with "TIFF", "MOV", "AVI" or whatever text.
Though I wouldn't know what other cue to use in such a case. Yes, it
should look like a picture or movie file, but should we indicate the
file type beyond that? If not, you may want to mention: "Indicating the
file type more precisely is the job of GWorkspace, and shouldn't be
done
by the icon".
Your suggestion is not precisely related to the recommendation you
quote, because the recommendation talks about text words and TIFF, MOV
or whatever are not text words in my opinion. Anyway the IconKit will
permit to badge the icon without having to create special icons, but we
think it would be more efficient to have the Workspace in the icon view
mode shows an informative text (describing the type) under the icon
label like the informative blue text in the Mac OS X Finder.
€ Don't use a mascot or a logo in the icons, when the mascot
choice seems
to be random in relation with application role. The cool factor
with the
icon creation process shouldn't be what you are looking for, but
just a
very desirable side effect.
As with the "Duck" example -- should this really be prohibited, or
would we rather want to say: "don't use a mascot or logo *alone* as the
icon"?
I think you are right here, we should accept mascot or logo when they
are not alone and not prominent.
6.1 (...)
€ Views with icons representation should always rely on a square
hit test
area (which encloses the icon) when the user needs to manipulate
them.
Don't use something like the alpha channel as the hit area. See
Fitt's
law.
What about overlapping icons? I think there should be a compromise
here: The outline of the icon should indicate the clickable area, but
any holes on the inside of an icon should also constitute a click in
the
icon. To drag out the famous MacOS 9 proof of Fitt's law: The CD icon
should have a circular clickable area, but if you click the CD's hole,
it will count as a click on the CD as well.
So, if icons overlap, you can click on the edge of the document icon
underneath the CD to get at it without having to move the CD around and
put it back again. But IconKit would have to provide a hit-testing
function that takes care of this. Otherwise people will just chicken
out
and use the alpha channel, because it's easier.
I strongly disagree, hit area based on the alpha channel are a
nightmare. In my experience, hit area based on the alpha channel makes
overlapping icons manipulation even more difficult or errors inducing
than when a rectangular hit area is used.
€ When you create files icons, you must take in account that the
bottom
part will probably be covered by a badge, then you must ensure
that the
key visual part is in the icon superior 2/3 part.
Good thinking!
Cool !
7.1 (...)
€ the used icons must use standard GNUstep icons when it is
possible/adequate. The IconKit provides standard GNUstep stock
icons which
have been created to be commonly used accross GNUstep
applications. As
such, don't create icon variations of the standard GNUstep icons
to use in
your application.
This could use a little clarification. Does this also apply to the
default document/plugin icons generated by IconKit? I think I
understand
it correctly, but just to be sure, it would be nice to have a few
examples here about which icons are provided just in case the developer
didn't care to provide any, and which icons are intended to be used
even
if the developer would like to design their own.
To clarify the things a bit :
- IconKit composited documents and plugins icons are there to be used
when the developer doesn't want to create its own icons.
- In any other cases, the developers should create its own icon only
when there are no adequate stock icons available (icons which match the
needed concept or action to express).
One thing is missing: Designing icons for graceful degradation when
scaling. This is something Apple have in their icon design guidelines,
and which I think is important especially for non-professionals.
Basically, the designer should make sure that the important parts of
the icon (usually the outline of the icon and the lines separating
different objects in the icon) have more emphasis, line weight or
contrast than patterns, lighting and gradients used in the icons. That
way, when the icon scales down, the important lines will stay visible,
while surface patterns and textures, which aren't that important for
recognizing what it is, will gradually blur.
The MacOS X trashcan is a good example. Scale the dock up and down. At
the smallest setting, the grid mesh of the trash looks almost like a
solid tin surface, while the hole at the top of the can always stays
recognizable as such.
We will include such explanations, it will be a nice addition. We have
already projected multiple resolutions icons support in the IconKit.
Hope my input helped some. I think this is a wonderful document, and
as
a GUI nut, I really like that you're thinking about things like these.
Thanks a lot for your extensive review.
Quentin.
--
Quentin Mathé
qmathe@club-internet.fr
- Re: GNUstep Icons and look proposal, (continued)
Re: GNUstep Icons and look proposal, M. Uli Kusterer, 2004/08/20
Re: GNUstep Icons and look proposal,
Quentin Mathé <=
Message not available