Technology Driven Design
Below is my submission to the Boagworld podcast. For season 18 of the podcast, Paul Boag decided to do an “Open Mic” season, allowing first time speakers a chance to appear on the podcast. You can hear the full podcast on Paul’s site, or subscribe to the podcast and hear the entire season. Now that I have appeared on the podcast it’s time to publish the article I wrote to get my thoughts in order.
Technology Driven Design
There are many ways to approach the design of a website. The various paradigms and schools of thought from atomic and responsive design informing the structure of the code to the more asthetic considerations of material design offer a bewildering array of considerations. All of this complexity, and the industry in which we find ourselves is underpinned by one thing. The browser. I’d like to argue that on the web we are living and working in a world of Technology Driven Design. Throughout the history of what we now call web design there are numerous examples, some of which I’ll discuss here, that show that it’s advances in the technology that allow web design to happen. From something simple like curved corners to big ideas like responsive design, designers working on the web have been driven by advances in the technology available to them. Rather than good design pushing the web forward, it’s advances in the browser that are pushing good design forward.
It’s the capabilities of the browser that are paramount to what we build and therefore how we go about building it. Without the browser there is no web; so no UX with it’s wider implications, no discussion about skeuomorphism, no Google. I’d argue that this makes the browser, and the technology packed into it, the single most important consideration when designing a site today.
As Louis Sullivan said, Form ever follows function. On the web I think that’s doubly important. Clever design can circumvent the limitations of the browser to a certain extent. Inevitably this requires clever hacks with clever coding to go with it. These hacks usually require non semantic code or lots of extra markup that can impact performance, they are generally a bad idea. As the capabilities of the browser improve with time, the limitations are relaxed and the designer can help create more complex functionality. In all this the limiting factor is the capabilities of the underlying technology.
I created a curved corner effect before CSS was capable of doing so. It required a lot of extra markup and knowledge of CSS margins but it was possible using the nifty buttons technique. Essentially stacking block level elements at the top and bottom of the button to create pixel steps, effectively creating a curve. This effect was expanded on to create a glass button, popular thanks to OSX at the time, by varying the colours of each block element. The CSS and extra markup needed for such a simple design detail was, to say the least, a bit bloated.
It could be argued that the designer could still design these things and it was left to a developer to make the designs come to life, and that is certainly true. I’d say that the developer should push back against these things if they are hard to do. It comes back to what hacks are required and what impact they will have on browser performance, the clarity of the code and these days, on the business. If developers need to spend a lot of time working out how to implement a given design then that design needs to be looked it in terms of the current browser capabilities.
The capabilities available in modern browsers are staggering compared to those early days, and designers are keeping up with new developments to produce more complex and engaging sites. These days roll overs and rounded corners are trivial so their implementation is less of a consideration.
Take something like web typography. While a designer could have added any type face they wanted to a web design before the technology was capable of rendering them, the developer would have had to resort to rasterising the entire page, or embedding images for each letter, or simply rejecting the design and using a system font. In practice wha actually happened here was that custom fonts were reserved for headers, logos or other key parts of the site and they were just images. Here the capabilities of the browser dictate the design for the simple reason that any work around to support the flights of fancy of a designer were just not worth the hassle.
An example of the capabilities of the browser simply bypassing designers comes from the early days of the web and is now called responsive design. The browser has always been responsive by design. When people started taking the web seriously and designers caught on to the implications of the technology the first people to actually design for the web, rather than developers exploring, were generally print designers. Those designers would try to impose rules on the page so they could use their well explored, tried and tested techniques to create interesting layouts. This order was typically expressed by asking developers, like me, a simple question. What width of page do you want designed? My answer was always the same. What size is your browser window? If I got an answer to that I would resize the window on the screen and ask again, or perhaps point out somebody else across the room and ask what resolution his display was. The web has always been fluid by design, with shifting limitations and restrictions which needed to be dealt with appropriately. Floats and fluid layouts helped a lot here but due to designers wanting their familiar mental model we had fixed width design.
With the explosion in the popularity of mobile browsers this was really pushed to the fore and rather than embracing the new tools and the flexibility of the web, we ended up with the common pattern of “em dot” domains. These were usually cut down versions of the main desktop website which would fit on the bewildering array of devices now accessing the web. Designers would decide what people really wanted to do when on the go and create a reduced experience for the reduced browsers. This allowed those teams to serve the tiny screens while maintaining their comfortable fixed width site. This allowed those teams to simply ignore the design challenge always inherant on the web.
The various tools that have appeared in CSS to allow for what Ethan Marcotte called responsive design gave us the flexibility to reorder and rearrange things based on the detected width of the page but even with all that available, the now common place idea of responsive design was hard won. Here the technology of the browswer has always been available, and was expanded to offer greater flexibility, but designers who either misunderstood or rejected these capabilities actually held web design back.
It’s not just the visual elements of the design that depend on the browser’s capabilities. Thanks largely to the mobile platform there’s been a rise in location services, for example. A designer could have crafted some location aware customisations to a site but that would have required the user to enter their location before the site knew where they were. Now the user just needs to give the site permission and the browser will automatically tell the user where they are. This aspect of the design would simply not be possible at all without the technology to support that simple interaction.
With the addition of WebRTC we can now address the video cameras built into a lot of web capable devices. We can overlay that video stream with any DOM elements we like, creating real time video conferencing in the browser. We can also overlap an HTML canvas over the video feed to add information to whatever the user is pointing their camera phone at. All from within the browser. These are capabilites that not so long ago would have required a browser plugin or more commonly a device specific app.
Not that long ago a designer wouldn’t have even considered building something like Poekmon Go in a browser but the technology is there to do so now. We have WebGL for full 3D rendering and on top of that we have web based virtual and augmented reality systems to design for. All this would have been simply unthinkable on the web just a short decade ago. A designer could have imagined these things but the feasibility of those designs actually coming to fruition was very small.
Should designers code?
Throughout my career I’ve had people coming up with grand ideas and leaving it to developers to work out how to make these things a reality. Everything I’ve said above would have been possible a decade ago with enough time and a good enough developer, but the solutions would have been sub par to say the least.
To be a good web designer these days there needs to be an understanding of the underlying technology. A designer needs to know the capabilities of the browser and what will be around the corner, they need to know what is mainstream, like flexbox, and what can be used looked at for inspiration, for the future, even if it isn’t quite ready yet, like CSS grid.
We’re straying into the oft repeated question of whether designers should code so I’ll answer with an unequivocal yes.
A painter needs to understand how her paint will be absorbed and bleed on a canvas but doesn’t necessarily need to be a weaver. She doesn’t need to be able to create the canvas but any painter of any decent standard understands how their medium works. A sculptor needs to understand the grain of the vein of marble they take a block from, they need to know how it will crack and flake as they extract a work of art from it. They don’t need to extract the stone from the quarry or mine themselves, though some do. They don’t need to be a geologist but they do need to know how their medium functions. A carpenter needs to understand the grain of the wood they are working with, they understand how it will splinter if cut in a certain way, how the grain around the knots will look when a given piece is plained smooth and varnished. They don’t need to be horticulturists, they don’t need to plant and grow their own forest but they need to understand how their medium will react.
A good web designer should have an understanding of their medium. While the web is a complex beast and I wouldn’t expect a designer to need to know the difference between SSL and H2 (though I wouldn’t expect them not to either) they should know the difference between and span and a div, they should know how to use absolute or static positioning in CSS and perhaps what animation changes would cause a repaint.
Technology driven design
All of this adds up to what I think is an inescapable conclusion. The technology drives the design. A good web designer should understand the technology that they are working with, understand what will be difficult or impossible for a developer to implement and design the site under those limitations. Far from stifling a designers creativity it is those limitations and restrictions that require a creative solution.
Looking to the future, it’s not just the browser either. With chat bots and direct speech interfaces becoming more prevailant the remit if what considerations a web designer should have has expanded greatly. A decade ago a web designer wouldn’t have to consider the complexities of conversational UX, of tone of voice or shared vocabluary but now, again thanks to advances in the underlying technology, that’s were we are.
We’ve seen the designs on the web become more and more complex along with improvements to the technology those designs run on. While through things like the W3C working groups designers and developers can push the browser and add new features to further design goals it is the technology in the browsers of today, and all the future todays to come, that defines what’s possible on the web and it’s that technology and how we can push it that drives web design, as it always has.