Too much time is spent talking about attention to detail in user interface design. Forget that. Or at least let’s all agree to take it as a given, a prerequisite.
I’ll lay this out simply: when things are static our brain will pick out the details, when things are in motion we’re in tracking mode and the details escape us. This is the order of things and it’ll likely be a very long time before that changes.
This is one of the truisms baked into the earliest GUIs. On the oldest Macs you’d double click to open a document and a zoom rect would appear to illustrate that an action was in progress. If you dragged a window, on Mac OS or Windows, you’d drag a simple outline. The developer-designers (that’s how it was back then) understood that the immediacy of dragging an outline was more valuable than slowly dragging the object itself. Given the trade offs of the time they were correct.
If you think this is a quaint notion, read this piece in mobile Safari and double tap this column of text to zoom it to fit the screen. Did you see what happened? The lower resolution rendering of the page zoomed to fill your screen and was then replaced by a higher resolution rendering once the transition was completed. This is the modern zoom rect and is enabled by leveraging the extremely fast graphics hardware we enjoy today. What started as a way to quickly render brown wall textures in a 3D shooter is now being used to make interacting with an obnoxiously binary device feel like a more natural, analog affair.
There’s a long litany of effects I’m tempted to dive into here. From the old NeXT window server full-window drag, to OS X fully buffered windows and the Minimize to Dock effect and to Core Animation and iOS in which all content is backed by a texture. I’ll dodge that for now because it’s too rich a history.
If you write interactive software know this: fluidity of motion is more important than accurate rendering, once a scene is static fidelity is paramount.
To boil it down, your take away is: drop fancy rendering effects to achieve the most fluid interaction possible.
If you’re using iOS or Core Animation you’re doing this already in more places than you’d guess. Keep this technique in mind when dealing with your own interaction issues. You can labour endlessly to make accurate rendering as fast as possible or you can appreciate how people perceive things and end up with the best possible interaction.
Always implement the simplest possible solution that fits your understanding of the problem space modulated by your anticipation of the inputs you’ll be dealing with.
This may sound like a re-statement of the K.I.S.S. principle but it’s not — it’s more robust than Keep It Simple, Stupid and is self justifying in the following way: The added complexity of parsing this rule is worth the sacrifice in communicability in order to more accurately express the argument behind it.
The “KISS Principle” is often rejected by those who know better. Their experience in a field has taught them that the simplest possible solution is likely unsuited to any amount of serious usage in the real world. They then abandon this principal and resort to implementing along lines that too often show signs of Second System Syndrome. The resulting code being heavily influenced by what they’ve done before only, this time, improved upon by the lessons they’ve learnt the first time they wrote something similar.
These people are smart and are learning from the mistakes they’ve made in the past. Anyone worth their salt should be at this self correcting level. But there is, as always, another level beyond that.
I call this next level the “Fuck It” level, though that may be too technical a term for some.
Achieving the Fuck It level entails knowing the problem space well enough and understanding the limits of your inputs well enough that you can gauge how complex an implementation will be required to match the requirements you’ve been given. Many nerds come to believe that their task is to come to the most optimal solution given the input and the hardware. That’s cool, they’re nerds, they do that. The actual task is to come to the best solution that suits the requirements in the shortest amount of time. That’s what your manager wants and that’s what the company wants. Where you shine, as a fancy pants and experienced engineer, is in doing exactly that while leaving yourself wiggle room to get more performance and more features out of what you’ve written once they come back to you for more. The trick is never in building the best possible implementation — the trick is in building the implementation that will provide the best possible future. The best possible implementation changes from year to year according to hardware trends or the software you’ve build upon. The implementation that will provide you with the best possible future changes far less frequently. When you understand the problem space well enough you’ll be able to define the implementation accordingly. When you do, implement the simplest possible solution you can and leverage the abstractions you’ve built from your experience to give you as much wiggle room to change things the next time out.
Details change quickly, patterns change slowly, your code base is glacial. Make it broad and adaptive and don’t overly tax yourself fitting into the cracks.
Every year I mean to take the time to note how the leaves grow on the trees around me and how the plants spring back to life. This year I’ll be making a real effort. I’ll be using Everyday to remind myself to go outside and take a photograph of the tree behind my place from my balcony. It will ask me to align my nose and mouth and I will laugh at it as I choose to align my photos with the branches of the tree.
And that’s what you’ll be doing too. We are all going to agree to take a photograph every day of our favourite plant or tree as it starts to recover from being depressed about just how stupidly cold the world can be at times. We will then share these with each other and the collection will be a wonderful crowd-sourcing of spring time happiness.
So, download Everyday and get to work. When you upload your series of photographs email the link to me at spring at kickingbear dot com. I will collect them and we’ll work out a great way to share them. No, I’m not sweating the details. It’s spring, have some fun.
For myself this is a deeply personal project. Each year my favourite tree grows slowly, its foliage gradually fills out and, in doing so, robs me of enjoying the sun as I relax on my deck. My photographs will be documenting how much of an asshole this thing is so that when I chop it down the judge will understand. Some of you may have more positive and happier motivations though. And I suppose that’s ok too.