discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep Icons and look proposal


From: Nicolas Roard
Subject: Re: GNUstep Icons and look proposal
Date: Sat, 21 Aug 2004 15:47:34 +0100


Le 21 août 04, à 13:30, M. Uli Kusterer a écrit :

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,
after all.

 Personally, I never had a problem spotting folders. They usually are
rather big and have one continuous rectangular surface, while most other
icons have more detail and a different shape. The folder itself already
is distinct enough in most cases, IMHO.

 But if someone else feels strongly about this, okay, leave it in. I
just find that having some items turned and others upright makes the
design look rather untidy, just as mixing 2D (as in "flat", not "frontal
view") and 3D would. Having it look more tidy and leaving it to the
theme designer to rotate things as they please would allow for more
consistent design, while still allowing for a theme that looks
mixed-and-matched.

Hmm .. yes, I think it's perhaps better to leave it to the designer in the end.
Quentin,your opinion ?


hm isn't it what's described in item 4.1.B ?

 I was mainly trying to contrast the two against each other. Make the
sheet of paper on the left an attribute that is exclusively used for
document-based apps, while having tools and droplets *not* have a sheet
in their icons in any prominent location. But yes, the
document-based-app-icon is really just the design you proposed for
applications in general. I like that one.

Well, yes -- if the application doesn't deal with documents, the proeminent item in the icon will probably be a tool, and no documents representation. More exactly... if an application doesn't deal documents, it shouldn't display
documents (sounds obvious).
Though, your example about an image converter is imho not good -- I think
an icon for such a program could probably include some "images". Plus,
"converting" images is imho editing :-)


 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
icon could
probably be doable (eg a duck balancing a globe..)
Not so sure though.

Generally, application designers like to make their icons recognizable. While usability would benefit from having more generic icons that simply indicate the program's function, allowing some branding of icons will go
a long way to encourage developers to do a proper icon.

 Just like GNUstep is trying to get more exposure by providing a modern
and recognizable theme, application developers will want other people to recognize their app when someone uses it. Since GNUstep already controls
what buttons look like and what icons are used, any opportunity for
developers to add something unique to their applications will help their
product gain exposure. And when more GNUstep applications are
recognized, this will indirectly drive recognition of GNUstep.

 So, if we let developers customize things a little, that'll help
GNUstep, as long as we encourage them to do the customization without
harming usability. So, just a duck would be bad, but integrating the
duck into a more recognizable "web browser" icon (which is often a globe
these days) might be a good compromise.

Ok, I agree.


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
similar)

 Well, okay. Then I guess my example was right on target: It's okay if
different movie or image file types have the same icon if they only
differ in compression scheme. And if the icon design docs mention that
displaying the actual type should be left to GWorkspace, it'll help
designers who think they're doing their users a good deed by badging
their icons with a type string manually.

Yes. I think it will be preferable to have default icons for standard media types, and theses default icons will possibly be badged/composited with other graphics elements -- but in that case, the application developer shouldn't create its own
icon. Does that make sense ? I think it will help the consistency.


 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"?

Perhaps... though it will probably quite difficult to make a good icon
mixing a logo
and something else.

 See above. I think saying where it is okay to use logos and other
corporate identity things and to what extent might be a better choice.
Of course, there's no harm done in warning designers: "designing an icon
is hard enough without having to integrate an unrelated logo - try to
avoid logos in icons so you have more pixel real-estate left for the
important parts". By saying "avoid", you still give them freedom to
break the rule, since there are much more important rules in the
document than this one, and there are worse mistakes to make than having
a little logo somewhere.

Yes, ok.


 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'm not sure. I prefer having the icon as a whole area; alpha channel
is just too
tricky.

 Okay. But you may want to provide a hit-testing function in IconKit
nonetheless. That way, if someone comes up with an insanely great
hit-testing scheme for icons, all it requires would be a change in
IconKit, and all apps would incorporate it. Something like:

-(BOOL)  point: (NSPoint)hitpos inIconAtPosition: (NSPoint)pos size:
(NSSize)dimensions;

right now this would simply do an NSPointInRect(), but if we wanted to
get fancy, this could later be expanded to use some smarter scheme, or
use a hit-testing-mask saved along with the icons, or whatever.

Good idea, yes. We should provide such a method.


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
on-the-fly composition),
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).

 That last part is what I wanted clarified in the icon design
guidelines. Icons that are there as a fallback, and which ambitious and
quality-conscious developers will want to replace with their own,
customized versions, should be marked as such in the list of provided
default icons. They aren't right now.

Well, it's not exactly that -- the "standard" icons should be used, period.

_but_ IconKit could automatically create icons on the fly via compositing different elements; then, the idea is for example to automatically create a default "document icon" for an application, by compositing the application's
icon in the middle of a standard "document" element (eg a paper sheet).

More or less, this mechanism is for the developers that don't want/ can't easily create icons, so that most of the needed icons for an application (like,
its document icon, its plugin icon, etc) would be created
automatically (and with standard elements), helping consistency.

But if, for theses icons the application developer want to do them, it could
provide them directly to the system.

Standard icons are not a fallback, they are expected to be used by the programmer. But IconKit could automatically create icons, and _theses_ are a fallback for the
programmer, as he could possibly provide its own.



 One thing is missing: Designing icons for graceful degradation when
scaling. (...)

That's interesting, indeed.
Normally you will be able to provide an icon in different sizes though.

 Which is the best solution, yes. But e.g. in MacOS X, there are five
predefined icon sizes (12x16, 16x16, 32x32, 64x64 and 128x128, IIRC),
while Finder and the Dock let you freely scale icons. Apple's Icon
Services will automatically scale an icon to whatever size you request,
either by picking a predefined icon of that size, or by proportionally
scaling the closest existing size to fit. This is a pretty cool feature,
IMHO, and only works if designers allow for graceful degradation.

Yes, that's the mechanism that is planned.

--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
 -Arthur C. Clarke





reply via email to

[Prev in Thread] Current Thread [Next in Thread]