[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep Icons and look proposal
M. Uli Kusterer
Re: GNUstep Icons and look proposal
Sat, 21 Aug 2004 21:02:52 +0200
MT-NewsWatcher/3.3b1 (PPC Mac OS X)
In article <address@hidden>,
Quentin Mathé <address@hidden> wrote:
> 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.
you're right, I wasn't aware the dock didn't have room between its
icons, but I just tried it with a 128x128 black square and yes, I got a
continuous black rectangle when placing two such icons in adjacent spots.
But is there any official guideline for leaving "breathing space"
around icons? I must have missed that in Apple's guidelines. From what I
see, most icons have, for lack of a better term, 'accidental' breathing
space, due to the fact that their shape is irregular, and also due to
the fact that most of them have shadows in the lower right.
IMHO breathing space in icons is the wrong solution to the right
problem. When an icon is scaled down, breathing space may be reduced or
disappear entirely. And also, this breathing space effectively leads to
"dead pixels" that have to be compressed into the image, even if they
are never used. If you let the application keep space between the icons
it draws, that's a more efficient use of image data.
Anyway, if you really want breathing space in the guidelines, you
should tell designers how much. Is one pixel enough? Two? Only on the
lower right, or all around the icon? Must this margin be completely
empty, or should the designer just avoid this area, but if the corner of
a piece of paper penetrates into this area, it's ok?
> 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 think we agree here. I understood "2D" as meaning an actual,
two-dimensional image, but Nicolas cleared that up for me. I have no
problem if they are basically similar and 3D.
> 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.
IMHO, red is too strong an indicator, and should be reserved for
important icons. Having all folders red could result in visual clutter,
due to color perspective and other properties of the color "red".
> 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.
Well, I'm still not a fan of the 30-degrees slant, but you've made a
good argument for this. I haven't done any research into whether this
actually helps, and I haven't had problems noticing folders on other
computers, but different people have different needs.
> > 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.
Actually, the OS X folders look very close to German "hanging register"
> 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
> 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
Well, I don't really have a sure-fire idea, but I think the proportions
are important. Folders should heve a relationship of height X width of
about 1 x 1.5, and should actually be modeled after an existing physical
folder, and not just after other folder icons. I've seen themes where
folders were square, or where the tab was attached to the wrong side of
the folder, which made them un-recognizable as folders to me.
So, as long as you get a decent designer to do the icons, I think it'll
> 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.
Yeah, I think that came up a while ago when GWorkspace got its beating
;-) Seriously, I would think that even informative text has no business
being in an icon, and I would mention that if I were to draft icon
design guidelines. There are too many icons that just consist of the
first letter of the program's name already. :-)
> 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.
Well, I actually find it useful. I guess we agree to disagree.
> Thanks a lot for your extensive review.
Oh, it's nothing. You're the ones doing the hard work of implementing
this, after all. *That* is the hard part.
Re: GNUstep Icons and look proposal, Quentin Mathé, 2004/08/21
Message not available
- Re: GNUstep Icons and look proposal, (continued)
- Re: GNUstep Icons and look proposal,
M. Uli Kusterer <=