Re: GNUstep Icons and look proposal

[M. Uli Kusterer]

In article <mailman.1660.1092786989.2011.discuss-gnustep@gnu.org>,
 Quentin Mathé <gnustep-quentin@club-internet.fr> wrote:

> http://www.quentinmathe.com/gnustep/documentation/UI/icons/

 Just reading it. Commenting as I go along.

> 2.3 (...)
> You should never create icons directly in contact with the border of their 
> frames, because in many cases an icon can be side by side with other icons, 
> 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.

 Also, MacOS X icons don't include any "breathing space" either, which 
means it'll be easier to port an application if you don't include it 
either. One less metric to worry about customizing for OS X.

> 3.1 Perspectives
> 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 server 
> (WebDav, FTP, etc.), a camera... Very common and repetitive locations related 
> icons like a standard folder should be represented with a 2D view but must 
> then use a 30 degrees counter-clockwise rotation (so they still stand-out in 
> 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 fully 
frontal, while applications are viewed more at an angle, and contain 
some sort of "tool".

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

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

 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 shadow 
at the bottom.

> Any other icons like the documents icons, the toolbar icons and the buttons 
> icons should use a 2D view.

(Nevermind the following -- just noticed chapter 7 covers this)
 Might be useful to mention what to do for an icon that is *both* an 
important location *and* shows up in a toolbar. Like a toolbar that 
contains all hard disks, for example. Have two separate icons for that? 
Allow the 3D icon? The latter would give more consistency, as the same 
object always has the very same icon, while the former would look a 
little better because of matching perspective among items in a toolbar 
or a workspace window.

> 3.2 (...)
> The icons which triggers a potentially destructive action should be partially 
> red. The icons which triggers a exceptional or really special action should 
> be partially yellow.

"exceptional or really special" ... could you clarify? Provide some 
examples of what is, and what isn't special?

> 4.1

What does "just over" mean? Do you mean "the recommendations described 
above"? Or do you mean "right on top of each other"?

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 really 
offer editing them, don't show the "photo" at the right, and only have a 
tool in the icon, or if that doesn't work, make the "photo" or whatever 
smaller and less important-looking.

 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.

> 5. (...)
> Example : A web browser called "Duck" shouldn't use a duck representation for 
> its icon.

 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.

>    €  Don't use text words in the icons, this recommandation is related to 
>    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 text in 
>    the icon, don't use real words in a specific language (or use a dead 
>    language like latin).
> 
> Example :

 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 done 
by the icon".

>    €  Don't use a mascot or a logo in the icons, when the mascot choice seems 
>    to be random in relation with application role. The cool factor with the 
>    icon creation process shouldn't be what you are looking for, but just a 
>    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 
icon"?

> 6.1 (...)
>    €  Views with icons representation should always rely on a square hit test 
>    area (which encloses the icon) when the user needs to manipulate them. 
>    Don't use something like the alpha channel as the hit area. See Fitt's 
>    law.

 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 the 
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 out 
and use the alpha channel, because it's easier.

>    €  When you create files icons, you must take in account that the bottom 
>    part will probably be covered by a badge, then you must ensure that the 
>    key visual part is in the icon superior 2/3 part.

 Good thinking!

> 7.1 (...)
>    €  the used icons must use standard GNUstep icons when it is 
>    possible/adequate. The IconKit provides standard GNUstep stock icons which 
>    have been created to be commonly used accross GNUstep applications. As 
>    such, don't create icon variations of the standard GNUstep icons to use in 
>    your application.

 This could use a little clarification. Does this also apply to the 
default document/plugin icons generated by IconKit? I think I understand 
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 even 
if the developer would like to design their own.

 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.

 Hope my input helped some. I think this is a wonderful document, and as 
a GUI nut, I really like that you're thinking about things like these.

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