[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep Icons and look proposal
Re: GNUstep Icons and look proposal
Sat, 21 Aug 2004 00:15:53 +0100
Le 20 août 04, à 19:47, M. Uli Kusterer a écrit :
In article <address@hidden>,
Quentin Mathé <address@hidden> wrote:
Just reading it. Commenting as I go along.
You should never create icons directly in contact with the border of
frames, because in many cases an icon can be side by side with other
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.
Hm, I think you're quite right, yes.
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
(WebDav, FTP, etc.), a camera... Very common and repetitive locations
icons like a standard folder should be represented with a 2D view but
then use a 30 degrees counter-clockwise rotation (so they still
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
frontal, while applications are viewed more at an angle, and contain
some sort of "tool".
Well, yes. Basically that's why we want to say "applications should go
2D". 2D is merely the perspective of the icon -- ie it could be "3D",
but with a frontal
perspective (to answer your latter comment about ta shadow...). So
"sitting on a shelf" could be a more accurate description.
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
I'm not entirely fond of the 30-degree folder icons, but at least it's
a quite effective
trick to quickly spot folders.. But well, perhaps we shouldn't impose
rules on that,
Having some icons returned and others not makes it harder to
distinguish objects. 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
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.
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
at the bottom.
Yes, that's right, I agree.
What does "just over" mean? Do you mean "the recommendations described
above"? Or do you mean "right on top of each other"?
yes, the recommendations described above.
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
offer editing them, don't show the "photo" at the right, and only have
tool in the icon, or if that doesn't work, make the "photo" or whatever
smaller and less important-looking.
hmm yes, that make sense. If an application doesn't deal with
main representation should be a single object (a tool?) if that make
We probably need to add that to 4.1.A .
If the application works with/on documents, OTOH, you should prefer
some kind of sheet (photo, sound wave on a piece of paper, etc.)
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.
hm isn't it what's described in item 4.1.B ?
Example : A web browser called "Duck" shouldn't use a duck
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.
Hm, why not. Anyway a composition of the application "logo" with the
probably be doable (eg a duck balancing a globe..)
Not so sure though.
€ Don't use text words in the icons, this recommandation is
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
the icon, don't use real words in a specific language (or use a
language like latin).
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
by the icon".
Well, the plan is either to automatically badge the icons using
IconKit, or to let
that entirely to GWorkspace (ie, adding the type below the name of the
file, or something
€ Don't use a mascot or a logo in the icons, when the mascot
to be random in relation with application role. The cool factor
icon creation process shouldn't be what you are looking for, but
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
Perhaps... though it will probably quite difficult to make a good icon
mixing a logo
and something else.
€ Views with icons representation should always rely on a square
area (which encloses the icon) when the user needs to manipulate
Don't use something like the alpha channel as the hit area. See
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
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
and use the alpha channel, because it's easier.
I'm not sure. I prefer having the icon as a whole area; alpha channel
is just too
€ the used icons must use standard GNUstep icons when it is
possible/adequate. The IconKit provides standard GNUstep stock
have been created to be commonly used accross GNUstep
such, don't create icon variations of the standard GNUstep icons
to use in
This could use a little clarification. Does this also apply to the
default document/plugin icons generated by IconKit? I think I
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
if the developer would like to design their own.
Well, the thing is that we'll have a set of standard icons (see chap.
8); the programmer
is strongly advised to use them rather than redoing the same icons. I
think we could
also provides "icons elements" in addition to that (as IconKit support
such the classic paper sheet for documents. The programmer could then
design its own
icons, yet using the standard elements.
IconKit will also automatically create some standard icons
(documents..) for an
application, but the programmer will have the possibilty to override
that, of course (as the
"standard" icon document will be a very simple one -- a paper sheet
with the application icon in the
middle -- it's mostly here as a fallback).
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.
That's interesting, indeed.
Normally you will be able to provide an icon in different sizes though.
Hope my input helped some. I think this is a wonderful document, and
a GUI nut, I really like that you're thinking about things like these.
Thanks a lot !
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
Re: GNUstep Icons and look proposal, Tomaž Slivnik, 2004/08/18
Re: GNUstep Icons and look proposal, Robert Burns, 2004/08/19
Re: GNUstep Icons and look proposal, Banlu Kemiyatorn, 2004/08/20
Re: GNUstep Icons and look proposal, M. Uli Kusterer, 2004/08/20
Re: GNUstep Icons and look proposal, Quentin Mathé, 2004/08/21
Message not available
- Re: GNUstep Icons and look proposal, (continued)