Re: GNUstep Icons and look proposal

[M. Uli Kusterer]

In article <mailman.2143.1093044056.2011.discuss-gnustep@gnu.org>,
 Nicolas Roard <nicolas@roard.com> wrote:

> So 
> perhaps,
> "sitting on a shelf" could be a more accurate description.

 Well, when I read 2D, I understood "2-dimensional", which to me means 
no depth at all. So, since that wasn't what you meant, then this should 
probably be clarified to avoid having designers do the wrong kind of 
icons. Glad we agree, and it was just a problem of phrasing and/or 
reception.

> 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, that make sense. If an application doesn't deal with 
> documents, its
> main representation should be a single object (a tool?) if that make 
> sense.
> 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.) 
> > 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.
> 
> 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.

> >  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.

> 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.

> >  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.

> >  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.

> 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.

> >
> >  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.

Cheers,
-- Uli
http://www.zathras.de