Don’t Call Yourself a Programmer

Posted on April 3, 2012 by Ian

As a twenty-six-year-old software engineer — I shan’t use the word “programmer”, for obvious reasons — who’s only ever really had one job, I probably ought to refrain from posting an opinion on this post:

But I will anyway. It’s true, every single word of it. I’m lucky enough to be in that 10% of jobs that isn’t producing “line of business” software, but that percentage doesn’t seem far off the mark. And all the rest applies — in my industry perhaps more than most, the points about networking and about managers hiring people they know ring true.

It’s a long read, but if you’re in the software industry or at University aiming for a job in software, do yourself a favour and read it. It’s well-written and probably the most concentrated page of good advice you will read this year.

Skeuomorphism Must Die!

Posted on March 20, 2012 by Ian

There have been a lot of rants around the internet of late about “skeuomorphism” in software, largely targeted at the latest versions of Apple’s operating systems. They’ve almost all been negative, possibly because designers hating on the concept are the only ones who felt sufficiently incensed that they looked up the name for it. I’m afraid I’m going to do nothing to buck the trend.

Skeuomorphism is defined as “[producing] a derivative object that retains ornamental design cues to a structure that was necessary in the original”, which in software terms usually refers to making a software interface look like a real-world object. For example, the Apple applications that have recently raised designers’ ire:

Skeuomorphism in software can be useful if (a) the concept the designer is trying to convey is difficult to get across without resorting to real-world objects, and (b) the skeuomorphic interface actually improves things.

In the iPhoto example, the paintbrushes are utterly redundant — the user already knows it’s a photo-editing app. Using buttons instead of photorealistic buttons wouldn’t have made the functions of the tools any easier to understand. In fact it might have been an improvement, as to many users the brushes could imply “this tool lets you draw on the picture”, which is not the case.

In the iCal example, the leather effect adds nothing in terms of usability — in fact it reduces the contrast ratio of the text to the background compared to OSX’s usual grey. All it does is evoke the idea of a leather-bound diary, an object which is fast becoming obsolete. (I tried using a real diary for a while. Gave up when it became apparent that there wasn’t a plugin for it that would sync the contents with Google Calendar.)

And that, I think, is the core of my problem with skeuomorphism. It’s inherently holding us back. Designers of these interfaces have looked at the possibilities of software UIs, glorious blank canvases on which we can draw anything the mind can imagine, infinite spaces of black pixels begging for life and colour, and they’ve chosen to make their software look a bit like leather.

Worse still is where this route leads, because Apple is far from the first company to flirt with these ideas.

Back in the mid-1990s, new and inexperienced users were joining the “computer revolution” in their millions. The advent of mouse-driven interfaces, (relatively) high-resolution and high-colour displays gave software developers a new technique to ease non-technical users into the world of computing.

They could make their fax program… look like a fax machine.

Buttons that look like textured plastic! Fake 7-segment displays to tell the time! Eight speed-dials! Huge amounts of wasted space! Curved corners! Cyan! A giant useless phone-shape attached to the side! A “handsfree” button that cannot possibly make the device more hands-free! This interface, and hundreds like it, are things of horror.

And of course, one company took it too far. They produced a skeuomorphic interface to govern every action the user takes with the computer, an interface so reviled that it bombed commercially and became the in-joke of the software design profession.

Kids: don’t do skeuomorphism. Or you might end up like Uncle Bob.

A Beginner’s Guide to Java Swing

Posted on March 2, 2012 by Ian

For those looking for a quick introduction to laying out Graphical User Interface components using Java’s Swing technology, this guide may prove helpful. (But probably not.)

Swing Components all have a few common properties that affect how they are laid out on the GUI. These are:

alignmentX and alignmentY do nothing whatsoever.
maximumSize sets the largest size the component can be when rendered, unless the Layout Manager feels like messing with you.
minimumSize sets the smallest size the component can be, although this only holds when Venus is in Capricorn.
preferredSize sets the exact size that a component will try to be, provided you have entered the secret unlock codes which are known only to Larry Ellison and the Illuminati.

Swing components are arranged inside their parent panels by Layout Managers. Many layout managers are available to achieve certain common layouts. They include:

FlowLayout arranges components in a straight horizontal line, hiding any that it can’t be bothered to display because your box was too small for them.
BoxLayout places all components in either a horizontal or vertical line, expanding to fit them all, but resizing the child components for the lulz.
BorderLayout places components on the top, left, bottom or right-hand side of the panel. If you place two on the same side, they duel to the death until only one survives.
GridLayout arranges components in a grid with fixed size cells. If the component in one of the cells happens to be huge for some reason (e.g. you did not enter the Illuminati secret unlock code), your entire parent panel expands until it consumes the universe.
GridBagLayout represents the eternal influence of the Outer Gods in the affairs of man. Ï̷̫̥̣͈ͯ̌a̱̮̼̣̞͇̬͚ͧ́̉̆ͭͭ͜I̻̝̰̟͕̖͎ͦ̏ͫ̀͗̋͢ã̶̧̭͚͖ͤ͑́̎ͩͅ!̙͉͙̫̋̋͠ ̹͓̝̹͙͉̲͉̰́̽̐̈ͭ͆̎!̛̘̖̺̺̦̙ͦ͗̂͗̈͊͝
f̦̬̲͇̥̗̙̬͆ͦͦ̀̒̕G̸̩̹̞̫̈ͨ͒͆͞r̶̤͆̋i̴̮͖̦̙̤͈̗͍̎͛ḑ̗̰̘̔ͥ͆͢B̻͇͎̣̰͓̀̇͒ͬ̈́͂ͣ̚͠͠ä̲̮̰͚̬͑̎́g̷̲͔̬͓̙̙̑̂ͧ͢L̶̛͍͎̝̲͐̃a̴͈̤̖͚̠̼̳̺̬͊ͥ̕͡ẏ̶̹̃̌͛̀ǒ̴̙̜̭͖̆͆ͮ̀ͫ͌ͤ͠u̶̥͈̝̱̺͖̔̿͗̊ͦ̒̋ͩ́t͖̤̻̥̟̻̻̹̞̻̎͒̅͂͗͑̽̎ͩ̇̇̔̉̌̃ ̵͕̘̬̳͆̒̈́ͭͦ̚͠’̷̘̔͋ͦ͂͝t͍͉͒̄ͨ̓ͧ̋̀h̲̣̜̱̳̝ͣ̓ą̶̸̜͎̝̹̭̹͒̐̄͊ͯ̐g̯̹̔̍ͦ͡n̩͚̞͆͌ͬ̐!̞̪͎͙̼͇͌͊̌

I hope that helps.

Towards a Simpler Desktop

Posted on January 15, 2012 by Ian

In one of my previous blog posts, “Designing for Granddad”, I examined some of the user interface features that cause my grandfather issues when using his computer, and left a few hanging questions as to how we software designers can make our apps less confusing to the novice computer user.

As is my unfortunate habit, I spent some of today checking out how work had progressed on the GNOME-shell and Ubuntu Unity desktop environments. (I enjoyed the eye candy for around three hours before reverting to the UI of least resistance.) Various complexities in their interfaces irritate me and seem to have provoked the wrath of a community of largely experienced computer users. This got me thinking about how I would go back the other way, and design a desktop environment for absolute novice computer users — one without many of the frustrations of modern software.

The Gnome-Shell Interface

My ideas, roughly distilled into a sort of ‘design manifesto’, are:

One activity at a time. Here I actually agree with Gnome-shell and Unity’s focus on full-screen applications, avoiding unrelated yet overlapping windows.
Never hide the means to change activities. Both Gnome-shell and Unity hide their application switcher during normal use, requiring at least a mouse movement or a click to get it back.
Don’t change state with mouse position. Novice computer users often have trouble controlling the mouse. Unity’s auto-hiding dock and Gnome-shell’s “hot corner” could prove frustrating, particularly the latter which completely changes the display when hit.
No system trays. The distinction between the taskbar and system tray is not well-defined and can be confusing. Gnome-shell is a particularly bad offender here, with not one but two tray-like areas.
No notifications (unless they help). Pop-ups confuse and scare novice users. If at all possible, the app should use a sane default rather than asking a question, and do nothing rather than displaying information. If a pop-up does appear, it should be helpful and clearly worded.
Stateless apps and background services. The user wants to get their e-mail. Reading e-mail is a legitimate activity, but leaving a mail client open so that they are notified of new mail is not. Use background services so that it doesn’t matter which apps are running.
Zero tolerance on UI clutter. While UX people like me may sometimes deplore clutter and idolise minimalism on aesthetic grounds, for the novice user, every bit of clutter is something that they feel like they should know how to use.
Explain things clearly. Keep words to a minimum, but ensure that the user always feels confident that they know what clicking a given element will do.
Undo everywhere. Offer an “undo” option wherever possible. If you’re dealing with small but important items (such as e-mail), consider offering a non-destructive way of getting e-mail out of the user’s face — “archive” instead of “delete”.
Use icons and words together. Novice computer users may be young or old, and users of any age may have poor vision or may not speak the language in which the interface was written. These may result in users finding either icons or words easier to understand on a control. Providing both, by using clear iconography and simple text together, helps to alleviate this problem.

I’ve mocked up a couple of interfaces to show a desktop environment that adheres to these principles. The first shows the “desktop”, taskbar and an example notification:

The second shows the mail app with example messages:

Is there anything you particularly like or hate about the mockups or the design principles behind them? Bear in mind that if you consider yourself tech-savvy or a software designer yourself, you’re probably not the target audience for this desktop environment — pretend to be your mother or grandfather for a minute and see how you feel about the suggestions I’ve made.

I’m happy to go further with these designs if you think it’s useful, and of course your own ideas and suggestions are more than welcome. The comments section is yours!

For anyone wondering, the mockups in this post were generated with Mockingbird, an excellent UI mocking web-app.

Designing for Granddad

Posted on January 5, 2012 by Ian

Slate‘s recent article, “2011 Was a Terrible Year for Tech”, coins the term “mom-bomb” for the moment that technology journalists declare a gadget so easy-to-use that it is actually useful to people who aren’t technology journalists:

He begins by praising the gadget’s intuitive interface and its easy setup process, but eventually he finds that mere description doesn’t adequately convey the product’s momentous simplicity. That’s when he drops the mom bomb: This thing is so easy that even my mom could use it.

I’m blessed with parents that, by and large, ‘get’ technology. Their VCR never flashed 12:00 (and now they have a DVD recorder); they both have Android phones that they can happily e-mail from. My grandparents are a different story, of course. Two of them have almost never used a computer, but my Granddad has a nice new shiny one and uses it regularly. But as the article points out, what tech journalists and we tech-savvy users think is simple and ‘user-friendly’ often falls far short of the ‘mom (or granddad) test’.

A few observations spring to mind:

Moving photos from a digital camera to a computer is one of the simplest tasks non-’tech-savvy’ users often want to do. But when you plug in a digital camera, Windows 7 helpfully pops up this dialog:
Do I want to “Import Pictures and Videos” using Windows, or using Windows Live Photo Gallery? What’s the difference? Do I want to “Copy pictures to [my] computer”? Do I want to “Download images”? Where will the photos go? Will they still be on the camera? I just want to see my photos, so I click “Open device to view files”, but what the heck is “DCIM”?
I set Google as his browser homepage, and since then, he has been getting his news not from the BBC News bookmark I created, but using the ‘News’ link on Google’s own menu that appears at the top of its pages:

…which is great, except that Google can change that menu at any time. And of course they are doing exactly that:

To my granddad, and many other novice internet users, the distinction between bookmarks — which only change if you want them to — and web page navigation menus — which can change at the webmaster’s whim — is not necessarily clear.
Even simple mouse commands can be unclear and difficult. In the example above, Google’s instruction to find the new menu is to ‘roll over’ the logo. When the novice user figures out that means ‘hover the cursor over’, they’re greeted with a JavaScript popup which will disappear again if their cursor accidentally wanders too far from the popup.

It’s my family duty to be tech support, and occasionally I am called upon to fix things that have actually gone wrong. But more often than not, I am called upon to try to rationalise a simple task that is unexpectedly complex to perform. This complexity has usually arisen because the software’s developers and most vocal users are so immersed in common UI paradigms that they just don’t notice that the complexity exists. For the novice user, on the other hand, even your software’s installation wizard is complexity they’d rather not deal with.

The Slate article is right to cite Facebook’s user interface as a particularly onerous example of software complexity. Feeds, live updates, inboxes, hidden inboxes, walls, profiles, Timeline, comments, likes, tags — some users need and revel in that level of complexity, but a significant number just want to, say, see what their kids are up to. I’m nervous that one day soon, my granddad will ask me to set him up with a Facebook account. I’ll dutifully comply, log him in, and give him this:

Where does one even begin? There are multiple feeds, multiple menus, pop-up and pop-down boxes. How do you add one of these “status” things? How do you add a friend? How do I send a message to someone? What’s public and what’s private? Why is there so much stuff?

In the world of User Experience (UX) design, we spend so much time thinking about how software will be used and by whom — personas, use cases, red routes and all the rest. But in the majority of software I see when working with novice users, it seems that either the novice user has not been considered, or their persona is paid lip service while the latest excitingly complicated new features are bolted onto the software.

As creators of software and of user experiences, I know we can do better than this.

Do you have any thoughts on how we can design better for the novice user? Just want to vent about an app with a particularly poor UI, or about a relative with a particularly poor grasp of computing? Fire away in the comments below!

Of Software and Magic

Posted on December 9, 2011 by Ian

Lightning crackles through my hind-brain, adenosine receptors lighting up in sequence as caffeine molecules finish their long journey from the hillsides of South America to the grey mass of proteins from which spawn consciousness. My eyes open wider, and with them my mind. Fingers flicker and dance across the keys of mankind’s most arcane device. Thoughts, ideas, visions flash across my mind, patterns forming for just milliseconds. Then they explode through neural pathways, twisting and contorting muscles that touch keys across the tiny portion of the real world that is still required for man and machine to work in harmony. Then on again, electrical pulses once more, completing the journey from pattern in flesh to pattern in silicon.

In another time and place, perhaps I would have been a shaman, ingesting powders of strange jungle plants to achieve the same state beyond mere consciousness, the same ability to communicate with the world, that I now achieve with caffeine and a keyboard. For the creation of software is unlike any art or act of engineering that came before it, and at times it borders on magical.

The carpenter’s and the artist’s work both begin with an idea in their mind, but the end product of each one’s endeavour is a real, tangible object. What’s more, the carpenter’s chisel marks and the artist’s brush strokes become part of the work itself, forever a sign that human effort created it. But not so the magic of the programmer. We have minimised our tools as far as we can, allowing fingers to dash across keys as fast as our muscles allow, and still we yearn to do away with them entirely. Like the Chi to a T’ai Chi practicioner, the keyboard to us is a limitation on the speed we can translate thought into reality, and the more we minimise it, the more effective we are.

At the end of the craft of software, there is no finished item that can be picked up, examined for workmanship, burnt to ash. There is just a pattern of magnetic domains on a disk somewhere, an electromagnetic pattern the mirror twin of the electromagnetic pattern in a brain that spawned it. By using a strange tool and a bizarre language which few understand, we take the patterns in our heads and overlay them on the world as pure information, pure pattern-stuff.

And that, dear friends, is nothing more or less than the practice of magic.

In Praise of Partimage

Posted on November 29, 2011 by Ian

For weeks now, I’ve been attempting to wrangle Symantec Ghost, the corporate cousin of Norton Ghost, to back up and restore the contents of a partition on a RAID. I’ve fought with device drivers, manually built Windows PE images using WAIK with Symantec’s outdated instructions, fought off continual pestering from a probably well-meaning call centre operative, and significantly contributed to the drinks coaster industry.

In desperation, I wondered if a simple dd from a Linux LiveCD would do the job, and the helpful folk at the UNIX/Linux Stack Exchange pointed me at various partimage-based backup/recovery distros such as Clonezilla and PING.

Surprise surprise… they worked out of the box with no hassle whatsoever.

Now they may have a few issues — PING, for example, has a particularly odd interpretation of the function of the “Cancel” button on occasion — but they do the job, for free, in minutes, compared to the hundreds of pounds and weeks of my time I unsuccessfully put into trying to use their commercial equivalent.

The slow, steady rise of open source software has never given us “The Year of Linux on the Desktop”, but it has vastly increased the number of times that I think “there must be some advantage to this commercial program that justifies its cost” before quickly realising that no, there really isn’t.

SuccessWhale is Terrifying: VPS Edition

Posted on October 10, 2011 by Ian

Just under two years ago, my SuccessWhale Twitter client was gaining new users at a steady rate and, as I noticed with alarm, was about to blow through my then-limited bandwidth allowance.

I’ve since relocated all my web stuff to Dreamhost, taking advantage of their unlimited bandwidth offering to plow through 10 GB and more a month. But now I’m coming up against the last remaining limit of my shared hosting – memory usage.

Both Westminster Hubble, which constantly crawls MPs’ social networks and RSS feeds, and an increasingly complex SuccessWhale, churn through a ton of memory. I don’t have a nice scary graph for this one, but at peak times, I’d estimate that my web server kills over half my PHP processes due to excess memory use. That means Only Dreaming basically goes down, while SuccessWhale throws errors around if it even loads at all.

It looks like I’m left taking the expensive plunge of moving my hosting to a VPS rather than a shared solution, which is a jump I’m nervous to make, especially since none of my web properties make me any money. Most worrying of all is that VPS prices tend to vary by available memory, and I don’t actually know how much memory all my stuff would take up if it were allowed free rein. And nor do I have any way of finding out, bar jumping ship to a VPS and taking advantage of free trial weeks.

So, dear lazyweb, do you have any experience with this sort of thing? And can anyone reccommend a good (cheap!) VPS host that fulfils the following criteria:

LAMP stack with “P” being both PHP and Python (or *BSD instead of Linux)
Full shell access
Unlimited (or at least 100 GB) bandwidth
Unlimited (or at least 10 GB) disk space
At least 20 MySQL databases
IMAP mailboxes & mail forwarding

I’ve been recommended linode by a friend which seems great for tinkering, though the price scales up rapidly with RAM use and I’m not sure I want to deal with the hassle of setting up Apache, MySQL etc. by myself. And there’s Dreamhost’s own offering, which would be virtually zero-hassle to switch to, but probably isn’t the cheapest around.

So, citizens of the interweb, I seek your advice!

Announcing: SuccessWhale version 2.0!

Posted on September 4, 2011 by Ian

Ladies and Gentlemen of the Internet, I am pleased to announce that SuccessWhale version 2.0 has just been released and is now live on SuccessWhale.com.

SuccessWhale is a web-based client for Twitter and Facebook, written in PHP, JavaScript and MySQL. It offers a multi-column view that allows users to merge together information from all their connected accounts and view it at a glance from any web browser.

The big changes between version 1.1.2 and 2.0 are:

Facebook support
Support for multiple Twitter (and Facebook) accounts
As many columns as you want
Columns that combine multiple feeds
Lightboxed images from Twitpic and yFrog
New themes
Numerous bug fixes!

You can see a screenshot of it in action below:

I would particularly like to thank Alex Hutter, Hugo Day, Erica Renton and Rg Enzon, whose help in finding bugs and suggesting new features has been instrumental in bringing SuccessWhale up to version 2.0 today.

SuccessWhale is an open source project, and the source code is licenced under the GPL v3.

UI Through the Eyes of a Child (Part 1/n?)

Posted on July 31, 2011 by Ian

My son is at the age where every question starts with “why” and everything, no matter how obvious, is to be questioned. I regularly get asked about various iconography and bits of user interface that seem intuitive to me, but to someone without many years of experience are clearly not. Through his eyes, I am beginning to understand the issues faced by new users of computers, mobile phones, and so on.

When playing with Google Maps, for example, he clicked on one of the stars I’d used to mark places we often go. Up popped the bubble with the place’s name:

“What’s that arrow for?”

To me, the little right-pointing arrow on that Google Maps bubble is a clear indication of “more information is available if you click this”. But to Joseph it clearly wasn’t — and why should it be? Why does an arrow suggest more information? It’s being used to point somewhere (conceptually off-screen) that you might want to go, like a signpost, but it doesn’t itself imply that you will find information that way. And why pointing right? Because we live in a culture that writes left-to-right, and we expect things to go from more general to more specific in that direction. Is a right-pointing arrow as intuitive to an Arabic or Chinese speaker?

An offline example came a few hours later at my parents’ house. They have a new oven, which like most others has a “mode” dial and a “temperature” dial. Both had icons above them. The temperature dial had a thermometer, which was immediately intuitive to Joseph — presumably through previously having seen pictures of thermometers, as in this day and age the temperature is measured by apps and websites, not a thermometer.

But the icon for the mode dial (which I’m afraid I didn’t photograph) looked a bit like a square around everyone’s favourite “loading” animated GIF:

“What does that mean?” Joseph asked.

I couldn’t give an answer to that. It was there because the other dial had an icon, and aesthetically they had to put something on this one. But it didn’t imply “mode” — the other symbols around the dial did that. ”This one’s a light, this one looks a bit like grill flames, this one’s got a fan; okay, that sets the mode.”

This is another thing I’ve seen in many user interfaces — and probably a few of my own. To the designers it might have looked pretty; a focus group might have sat around and said “okay, I guess we can see how that means mode“. But it’s basically clutter — a UI element that means nothing and does nothing.

In conclusion, when trying to design a truly intuitive interface, ensure that it is tested by people who aren’t experienced at using similar products. Ideally, it would appear, give it to a three-year-old and see what questions they ask.