Blame your tools

Interfaces are evolving, and our tools are struggling to keep up. Alasdair Monk explores what our design toolkits should look like

Illustration by Ben Mounsey

Looking back to 20 years ago, our workflow for web design relied heavily on creating a hi-fidelity, fixed canvas in Photoshop that would then be mimicked in HTML and FTPd out into the world. Since then, the increasing ubiquity of the internet has changed everything. We now boast a multitude of devices from which to consume, publish and share via apps. From watches to televisions, we’re now never more than a glance away from our beloved black mirrors.

And yet despite our technological progress, our design toolkit has not evolved with us. Photoshop is not a serious UI tool in 2015. Even newer tools like Sketch are really just an iteration on the nostalgic metaphor of the artboard, the canvas and the paint brush. These tools are destined to create only the illusion of an interface.

It seems to me there are three distinct areas in which our current tooling is lacking: layout (by which I mean the placement of elements), expression (the ability of designers to communicate nuance in animation), and collaboration (our ability to work together).

Designing for paper

Layout is the area in which our tools are most advanced. This is no coincidence, as we’ve had hundreds of years of designing for the printed page to hone our concepts and design systems. Initially our page-based metaphor transitioned seamlessly to the digital screen. However, with the rise of true interactivity on the web, and as we evolved from web pages to web apps, so too our physical metaphors fell apart. Sketch, Photoshop, Illustrator — in fact, almost any popular design tool you can name — is born of the physical world and thereby hampered by a limited mental model of what we’re designing for.

Furthermore, how can we feasibly consider every permutation of screen size and orientation when designing? One solution may be found in the Cassowary algorithm, with which we can mathematically describe layouts using a set of rules (called constraints) for how they should behave.

For example; in CSS, we might create a .box rule, and define the width/height of the box, position it absolutely and centre it using negative margins. This is essentially a hack, and a brittle one at that. If the width or height of our box changes, it won’t be centred unless we remember to update the negative margins, too. Even using flexbox we don’t fare that much better.

Using a JavaScript implementation of Cassowary called GSS, we can be much more descriptive by placing a simple constraint on our box:

.box[center] == ::window[center]; 

This centres the box in the viewport, and will keep it centred regardless of any changes in styling to the box. This simple yet powerful idea was proposed as an extension to CSS, and yet seemed destined to gather dust as an academic pursuit and nothing more.

That was until 2011, when Apple decided it wanted to roll out bigger screens on the iPhone, which previously had remained at a constant size. It also wanted to allow developers to create one ‘universal’ app that could be run on an iPad or an iPhone with minimal overhead for implementing design changes. Its solution was to create the Cassowary-based ‘auto layout’ and integrate it into OS X and iOS.

Apple’s application of Cassowary and the aforementioned GSS implementation inspired me to create a design tool based on constraints, called Bind. It’s an open source experiment into the usefulness of such a tool as part of our workflow.

It seems in the last few months, excitement about constraint-based design seems to have really taken off. This has culminated in the aptly named plugin for Sketch: Constraints by Marc Bouchenoire, which demonstrates the flexibility and efficiency of algorithmic layouts in our everyday work.

The phone in your pocket is likely more powerful than most laptops, and we’re building ever more complex interfaces to match. The tools to design such wonderfully animated UIs have struggled to keep pace with the technology, though

Getting animated

So, our tools are becoming more intelligent in regards to laying out static elements, but what about their ability to express animations and interactions? We now live in an age where the phone you carry in your pocket is likely more powerful than most laptops on sale in your local Currys; and we’re building ever more complex interfaces to match. It’s no coincidence that Material Design places a heavy emphasis on beautiful, fluid animation, the likes of which is rarely seen on the desktop.

The range of tools to design such wonderfully animated UIs has struggled to keep pace with the technology, though. On one hand, we have tools like Marvel and Keynote, which are excellent for quickly describing the general feel of an app, but fall down if you stray from templated transitions. On the other hand, tools like Quartz Composer and Framer enable you to achieve almost anything with native-like speed, but present a steep learning curve to users.

There are however, some brand new tools that are closing the gap between these two poles. My favourite is Principle, which amazingly, at version 0.0.7 is already stable, easy to use and allows for fine-grained control over every aspect of prototyping and animation. To any veteran user of Flash, Principle will make you feel right at home with its timeline-based UI and ‘tweening’ approach to interaction design. Another hot contender is the recently announced Project Comet from Adobe, which not only promises animation capabilities but also the chance to design with live data from the web.

Working together

The last aspect on which I think our current toolkit lets us down is the most innate: our desire to work together. There is simply no commonly accepted way for designers to collaborate and version their work. For many, the solution is to spawn a dozen files in the vein of ‘Design-final.psd’, ‘Design-final-final.psd’, ‘Designdefinitelyfinal-final.psd’ , and so on.

Of course, the engineer’s answer to the same problem is the elegant Git versioning system, which allows a team of thousands to seamlessly commit, merge and fork their way to a finished product. Git works so well because the files it’s concerned with are lightweight plain text and can be read by any text editor. The same isn’t true for the files our design tools create, which can often be hundreds of megabytes big and almost unanimously, saved in a proprietary format that makes it even harder to build tools that will allow us to work together on them.

That’s not to say we haven’t tried. Startup Layervault delivered an excellent product that was compatible with Photoshop and Sketch, but struggled to break even and ultimately shut down earlier this year. Similarly the Git Large File System offers a solution for storing designs on platforms like GitHub while minimising the associated burden of storing and retrieving the whole file with each synchronisation.

Despite such progress, it seems we’re still a long way from true version control and collaboration for designers. It’s a tough problem to solve, but one I believe would revolutionise our industry. The solution will allow designers, wherever they are, to design socially rather than on isolated, bleak white canvases.

Someone will have the skill and the passion to topple our status quo. Someone will make the breakthrough that changes how we work. Maybe it’s you.

Alasdair is a senior product designer on the Human Interface team at cloud application platform Heroku


This article originally appeared in issue 275 of net magazine.