Illustrations for my ICGG2014 paper

I’ve written a paper for the ICGG2014 conference to go with my talk. It mostly talks about the theoretical side of things, whereas the talk is going to focus on the pragmatic. In case they won’t accept it I’ll post it here soon, but if they do then it will be available online sometime after the conference.

Over the past few years I’ve grown increasingly tired of slick computer generated graphics. They all too often fail to draw attention to salient details and convey meaning. It’s rare these days that I get to make large illustrations, most of my graphic work is for icons, so I do try and savour it when I get the chance. I’ve put the 10 images I drew for this publication below the fold (with LaTeX overlays and captions).

On Icons

As I’m responsible for both the code and the graphics of Grasshopper™, icon design is a significant part of my job. In fact, my very first productive work on computers at all was icon design. When I was 14-ish my dad got an Acorn RISC PC with RISC OS 3.5 and using applications such as Paint, Draw, Artworks and later on PhotoDesk and Compo I spend many a happy afternoon replacing icons for file formats, applications and toolbars. It wasn’t until the start of my actual programming career that icon design became a vital part of my skill set and I have a suspicion that —just like programming itself— it’s something you simply cannot master. No matter how much code you write or how many icons you draw, there’s always room for improvement.

These days I work on Windows and I primarily use Xara for my icon design, augmented by Rhino for complicated 3D shapes and Paint.NET for pixel post-processing. Over the years I have amassed some opinions, guidelines and techniques on the matter, some of which I’d like to share with all of you. Let’s start with what icons are and what they should not be.

1. Icons are visual cues that aid in the process of navigation, messaging or analysis.
2. Icons are conduits of love from developers to users.
3. Icons are not descriptions of features.
4. Icons are not art.

Discoverability

Graphic Interface design —or User Experience (UX) design as it is nowadays called— is not a science. And when you see 99% of all the interfaces out there you’d be hard-pressed to call it “art” instead. To many software developers UX seems to be a necessary evil. On one end of the spectrum we find the applications that seem to have an interface that exactly represents the program code. If there is an SDK function called MergeReferencedTemplateStructures() there will be a menu item called Merge Referenced Template Structures Ctrl+Shift+Alt+M. In many cases I wouldn’t even call this “design”.

Other programmers seem to treat UX design as a challenge to make their software as distinctive as possible. At this end we’ll find hand-crafted GUIs that do not in any way conform to the OS standard. Have you ever noticed for example how all virus scanner software looks completely unlike any other software? Virus scanners use custom images to represent tabs, buttons and toggles. They tend to reserve large areas on the main interface for logos and background images. I do not know why this should be so, the only logical explanation I can think of is that virus scanner developers believe that end users won’t trust software whose purpose is to protect the system if it seems subordinate to that system. The result is that it is often not clear what parts of a virus scanner window are clickable, and due to the non-standard nature of the interface, tooltips are often missing entirely. Not all UX that breaks away from OS-standards is bad by the way. Sometimes there are good reasons for re-designing a UX standard. Adobe LightRoom and Blender are good examples of non-standard UX design that seem to work very well.

Some typical Virus Scanner Interfaces

The most important part in any UX decision is the U. The interface serves only the user. It is not there to make you feel good about being a UX designer. It is not there to provide good screen shots for marketing brochures. It is not there so you can show off your Photoshop icon skills. The only guiding principle worth a damn —and I cannot stress this enough— is the user. There’s just one problem; the user doesn’t exist. Unless you’re writing a program for a single client, you’ll have to deal with users, and as soon as there’s more than one of ’em there will be conflict. All users want features specifically crafted to help them with the idiosyncrasies of their unique and individual tasks. All users want not to be confronted by features made for others. Some users want shortcuts, some users want drag+drop, some users want all features to be in the main menu, some users want all features to be in context menus, some users want toolbars, some users want command-lines, some users want text, some users want icons, some users want animated icons with text. It is easy for a software company to say that they listen to their users, because once you have enough users, every single possible opinion can be distilled from the hubbub. It’s like reading tea-leaves.