Before the era of WordPress there was a time when Macromedia Flash was the industry-leading web design solution. Today, that sounds like madness but back then, the world of Flash offered design possibilities that were simply not possible with just HTML, CSS, and Javascript. I studied web design in college under one of the founding partners at The Chopping Block which at the time was the leading New York Flash design and development studio. As absurd as it sounds now, the spark that got me interested in web design came directly from the work I saw being done in Flash which included animated graphics, non-system fonts and unique layouts that I had never seen on the web before. Around that time, I was also coming into my own as a designer and Flash seemed to offer virtually unlimited possibilities in layout, structure and interaction that was far more attractive to me that anything I had seen on a normal website.
On the flip side, the community around Flash lacked unified standards for both development, and especially design. This made Flash very hard to maintain over time. A Flash site could be designed and developed in completely different ways – and users would be tasked with having to learn all kinds of awkward or undercooked interfaces. It was also pretty difficult to make Flash sites search-engine friendly since a Flash .swf file was essentially a self-contained app. In a few years this lead to a messy, bloated, in-accessible Flash development environment that was often slow to load and hard to use regardless of how nicely a Flash site was designed. To make matters worse, Flash depended on a browser plugin that frequently needed updates that forced you to restart your browser—super annoying.
The nail in the coffin for Flash came with the uprise in mobile devices which scarcely supported the weight and dependencies of Flash. Particularly, Apple refused to support Flash in iOS all together which allowed iPhones users to get used to a faster experience. All in all, the thing that attracted me to creating awesome, intelligently designed websites also became the thing that lead to its demise as a popular platform.
A few years after realizing Flash was not the way to go, I discovered WordPress, which opened up a whole new world of possibilities for both content management and accessibility. Compared to Flash, having a lighter, faster and more searchable website that separated content from design made so much more sense than something that was beautiful but slow and awkward to use.
However, moving to HTML-based website development meant sacrificing what I previously viewed as a world of unlimited design possibilities. I realized a website that works quickly and efficiently will be more successful than one that just looks great. Today, I wonder if a similar shift could be on the horizon as accessing websites on mobile devices continues to become more common than traditional screens or desktops.
Fingers vs. Mice
On a desktop, a user moves around a mouse that controls an on-screen cursor that can interact with interfaces on their screen. The mouse is a virtual way to “feel” your way around an interface without actually touching it. If that cursor is moving and it crosses the path of an element that is interactive or clickable, the site will give you a response to let you know that you can do something with that element (think hover states on links). This is how we’ve interacted with screens for decades now and it’s pretty intuitive for most people who grew up using mice. Additionally, the scale of the cursor is pretty small relative to the size of a desktop screen, so the range in size of elements that are clickable can be very small to very big without issue as long as there are cues to let you know that you can do something with any particular element. The cursor is effectively a transparent device as its size and shape don’t particularly obstruct your view but still allow you to complete actions.
On mobile, an entirely different thing is happening. You’re viewing a considerably smaller screen and interacting with it using the your finger to touch the screen which is a wildly different interaction in practice. Since a hover state is impractical for a touch action, buttons on touchscreen devices need to be more obvious with larger clickable areas so that your intent of a given finger tap can be captured more precisely. This presents a conundrum for designers where you have a very small screen that needs to support larger buttons and text while still following the rules of design like hierarchy, scale and composition. Also, a touchscreens requires your actual finger, which is huge compared to the size of a mouse on a desktop screen. Your finger can often times block the view of the site during an interaction like scrolling and swiping and even typing on most mobile OSs will pull up a keyboard that further shrinks the mobile view.
There’s also an expectation of speed that’s assumed on mobile that doesn’t exist as much on desktop. When you’re browsing the web at home or at work on a desktop you’re likely on a faster network and a faster computer, so slow loading speeds aren’t as noticeable. When you’re on the move, however – your phone, which isn’t as powerful as a full computer – is jumping in and out of various networks with varying speeds as you move around. If a site is slow to load, you’ll notice it immediately on your phone and I think the scale of the device has a lot to do with this expectation.
Knowing all of this, does it really make sense to always build sites responsively? How do you convert desktop elements meant for a mouse click to a mobile element that needs to be touched (or vice-versa with a mobile-first approach)? How do you design a singular experience for desktop and mobile when the methods that we use to interact with the websites are so different?
A somewhat shaky case for AMP
As an extreme example, designing sites responsively for both desktop and mobile is like building a car that you can turn into a skateboard when the traffic is bad. Compressing all of the elements of a car down to the size a skateboard would make for a really dense and heavy skateboard which would be a terrible ride (unless maybe you’re riding downhill 😉 ). While responsive design allows us to create a dynamic, flexible, and unified experience, if it’s too heavy and slow, no one will want to wait to get that experience. Wouldn’t it make more sense to carry a skateboard in the trunk of the car and only pull it out when it’s needed?
As much as I’m aware of both the arguments for AMP and against the AMP approach, the physical interaction on mobile makes me lean towards using a more generally unified and consistent mobile experience across the web, à la AMP. I’m not so happy about the market advantage that AMP gives to Google, but it works as solution to the ills of the mobile web that I’ve presented here. Considering the physical limitations of the mobile screen size, how many different ways can we design for mobile screens without also adding bloat and dead weight?
Furthermore, if content is king, a user will be more likely to revisit a site regularly when they’re able to access valuable content quickly and easily. Even if you have the best designed site ever, are users going to come back just to look at that same design over and over again because of how great it looks? Maybe that answer is yes if you’re a web designer, but for the average user, the content is what gets them on the site in the first place and keeps them coming back.
I realize I’m arguing against a need for quality web design that stands on its own design merits. This was what I disliked most about moving away from Flash. At the same time, to me this just means adapting to the ever evolving constraints and freedoms of the Internet as medium.
AUTOMATTIC DESIGN (VOICE RIP) 