[texworks] About the Icon Design (was: Icon Update)

[Jonathan Kew]

On 11 Jul 2009, at 19:31, Stefan Löffler wrote:

> Hi,
>
> I just wanted to give you a short overview over what I think an icon
> should and should not be. From this, it hopefully becomes clear why I
> did what I did and you can persuade me to the contrary ;).

Haha :) ..... well, maybe I can try, but I'd be glad to hear some  
other people's opinions too. Thanks for your comments, it's really  
helpful to discuss and think about this stuff.

>
> IMO, an icon should be a simple, clear, and above all easy to  
> recognize
> pictographic representation, preferably of what the thing it  
> represents
> actually does. That said, I obviously don't have anything against a
> nice-looking icon with lots of artistic topping. But above all, an  
> icon
> should have clean and simple strokes undisturbed by all the extras.
> Great care must be taken that the icon is still discernible and
> recognizable even at low resolution/size (e.g. 16x16 pixels). Despite
> the fact that modern systems often tend to use extremely large  
> versions
> (96x96 pixels and more) for icons, there usually is still the
> possibility (and sometimes the necessity) to view items as lists,
> resulting in small icons. Note that an icon is substantially different
> from a logo, the letter usually being designed and used only at  
> moderate
> to large scale.

Yes, this makes sense; however, I would suggest that regardless of  
what we call the files, modern GUI systems are tending to use these  
things as "logos" as well as "icons", hence the variety of higher-res  
sizes that we have. If you set an Explorer window in Vista to use  
"Extra Large Icons", they're pretty big (looks like 256px), and they  
need a reasonable amount of "artistic topping" if they're not going to  
look very bland. And similarly in Mac OS X -- the "preview" image  
shown in Finder's column view is using 128-pixel icons, and the Cmd- 
Tab task switcher or the Dock with magnification is similar; Cover  
Flow can go much bigger yet (see below).

Perhaps the best way to handle this is to use "fully-artistic" logo- 
type images for large sizes, and then at small sizes (maybe 64px;  
perhaps 48px and below) deliberately eliminate some of the detail so  
that the small icons remain clean and easy to recognize.

> That said, I'd like to explain what led me to creating the latest
> version of the icon:
> * I added the border to have a rather high contrast outline which
> should hopefully help in recognizing the icon. I admit that at sizes
> larger than 42x42 pixels (where the border should be 1 px wide) it's
> rather heavy, though.

At small sizes, I'm happy with this; but even at the 48px size I'd be  
inclined to make it a bit thinner than it is (remembering that  
antialiasing lets you in effect draw black lines that are < 1px wide).  
On the 96px version I find it much too heavy; at such large sizes, I  
think a more "photographic" appearance rather than a "colored-in line  
drawing" looks much more attractive and polished.

> * I didn't draw the "inky" highlights because I thought the large
> contrast changes inside the letter interfered with recognizing the
> outline of the letter T (and because I'm not that skilled in Inkscape
> ;)). This especially applies to medium resolution icons. In the large
> ones, it's recognizable what it is, and in the small ones, the effect
> vanishes.

This would be a good candidate for "cleaning up" at the sizes where  
the effect becomes too small to be useful, yet makes the icon less  
clear. I think it adds to the attractiveness and visual interest at  
"logo" sizes, so I'm reluctant to lose it altogether.

(BTW, I also preferred the darker blue of the Blender icon, FWIW.  
Can't remember if I said that.)

> * I broadened the bar of the "T" because at small sizes, it was hardly
> visible (partially due to the fact that the "T" is tilted).

And in particular, the bar is "away" from us and so perspective thins  
it down compared to the serif at the foot. I think it's perfectly  
reasonable to compensate (slightly) for this; the adjustment you made  
didn't look at all "wrong" to my eyes.

>
> All in all, the result matches the design of most icons more closely
> than before, IMO - it's more icon-ish (this assessment may be biased
> though, as designs are system dependent).

Yes, they are. I'd certainly agree that it is more akin to, say, the  
Tango icons used in the toolbars; but those are never used at large  
sizes, whereas (depending on system setup and user habits) users will  
see the application (and document) icon at much larger sizes, at least  
some of the time.

> If we're talking about a logo
> intended for larger sizes, I fully agree with everything
>
> On 2009-07-11 13:16, Jonathan Kew wrote:
>> [criticism/suggestions]
>>
>> (Just the opinion of a non-artist, of course!)
>
> As am I ;).
>
>> Now, what I was going to request.... in addition to the application
>> icon, it would be good to have icons for associated documents, which
>> at least some systems will display. If you look in the res/images
>> directory you'll see that I have created a simple TeXworks-doc.png
>> that the latest Mac build is using, but this was just hacked together
>> in Photoshop, and would probably be better regenerated from Blender
>> source if you're up for that. Also, it would be nice to have distinct
>> document icons at least for text and PDF file types, while keeping  
>> the
>> visual association with the application itself.... would you (or
>> anyone) care to give this some thought? :)
>
> I like your version as it is (though it was "hacked" ;)). I'm not sure
> if they work well unmodified for 16x16 px, but other than it's simple
> and recognizable.
>
> It may be nice to have a distinction between different file types in  
> the
> long run (tex, pdf, sty, whatever else TW eventually will support),
> similarly to what Adobe is doing.
>
> The only other idea I had today was not to include the "moveable type
> T", which doesn't really make that much sense if we go with the
> interpretation that we use that image to represent TW because TW is
> doing typesetting (OK, it's not, really, but I'll ignore that for now
> ;)). Following in this direction, the documents should not be
> represented by the "moveable type", but rather by a printed letter.
> Unfortunately, I don't think anyone would associate a document with a
> large, blue, printer letter "T" with an application represented by the
> "moveable type T". But still I like the idea ;).

Suppose we kept the basic document with the superimposed "moveable  
type T" as a unifying feature; text documents (not currently  
distinguishing .tex from .sty or .cls or....) could have a "lines of  
text" effect added, as many programs seem to do for text files in  
general, while PDFs could show an impression (in blue) of the T on the  
paper, showing that the "printing" process has happened. (Ok, our  
process isn't actually printing, it's typesetting, but I think we  
could take that liberty.)

>
>> If you have the time (and inclination) to do this, it'd be ideal to
>> have the icons generated at 512px, as I think that's the largest size
>> anyone needs for now, well as any "source" that may be relevant, and
>> any smaller sizes (256, 128, 48, 32, 16px) that benefit from
>> fine-tuning rather than simply scaling the original. Oh, and of  
>> course
>> the Windows .ico format, for those of us who haven't yet attempted to
>> build those.
>
> Ahem, who needs 128, 256, and 512 px? 512 px is half of the size of  
> some
> screens (particularly laptops, beamers and the like). For me, all of
> these would no longer fall under the classification of icon.

Vista can use at least up to 256px, as noted above; for really huge  
versions, try the Cover Flow view of a folder on Mac OS X. I'm  
attaching a screenshot (scaled to 50% and compressed) of browsing the  
Applications folder in this mode. Not that I would ever use this  
personally, but it definitely likes HUGE "icons"! This screenshot is  
of an entire 1440x900 laptop screen...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot.jpg
Type: image/jpeg
Size: 99385 bytes
Desc: not available
URL: <http://tug.org/pipermail/texworks/attachments/20090711/d2df84e2/attachment-0001.jpg>
-------------- next part --------------