[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 14:30:14 +0200
MT-NewsWatcher/3.3b1 (PPC Mac OS X)
In article <address@hidden>,
Nicolas Roard <address@hidden> wrote:
> "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
> 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
> 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
> 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
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
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:
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.
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)