Progressive enhancement — More than just works without JavaScript

Inception

A spinning top is a beautiful thing. But, we don’t want a business, product or service to be like one. After spinning upright for an extended period, its momentum will lessen and ultimately it’ll topple over. Often it’ll do this violently and unexpectedly. In order for a business, product or service to succeed and endure, its fundamental core must be robust.

Backstory

The internet had over 3.7 billion users in the start of 2017: almost half the world’s population. One of the keys to its success has been it’s simplicity. HTML, it’s most basic building block, has been key to realising it. Tim Berners‐Lee had originally designed HTML at CERN as a way of easily indexing non-HTML files, such as word-processing documents and spreadsheets. HTML had a simple vocabulary that was easy to learn. The first version of HTML contained only 21 elements. Many of these original elements are still in use today. Since it was so easy to learn, people soon started to create documents in HTML alone; linking them together to create a web of pages.

This web of pages required a program called a web browser to view them. The very first web browser had been designed for the NeXTStep operating system. As HTML was so useful, it soon seemed logical to create web browsers that worked on other computing platforms. As soon as there was more than one web browser that was on a different operating system, HTML’s interoperability and backwards compatibility became an important consideration. What should the Line Mode Browser do when it encounters an HTML element it doesn’t understand? What should it do when it encounters an element like the NEXTID which was specific to the NeXTStep browser? In the minimal documentation Tim Berners‐Lee wrote under the section HTML Tags, under the heading “Next ID”, he wrote: “Browser software may ignore this tag.”

This simple statement would later have a massive impact on how the web evolved. It provided guidance on how HTML should be interpreted when a browser didn’t understand a specific tag. When this happened, the browser didn’t stop reading the HTML document. Instead, it just read the contents of the tag which it did understand.

So if a web browser encounters:

<wapuunicorn>The unicorn Scotland’s national animal.</wapuunicorn>

It doesn’t stop loading the page or throw an error, it just renders the text between the tags:

The unicorn Scotland’s national animal.

It doesn’t throw an error instead it just renders the text between them. This tolerance of errors meant that the vocabulary of HTML could grow. We knew exactly how browsers would behave when they encountered new tags they didn’t understand. Web browsers would ignore tags they didn’t understand and render what they did between them.

This was a powerful feature as it’s allowed us to extend the vocabulary of HTML with new tags. And we could extend this vocabulary at different speeds. We didn’t have to wait for everybody to rewrite their browser software to safely start using new tags.

It soon wasn’t long before new tags started to appear. However, some of these tags were being used as visual instructions. Tags like BIG, SMALL, CENTER, FONT didn’t have any clear semantic value like the original 21 Tim had defined.

Håkon Wium Lie was working at CERN at the same time as Tim Berners‐Lee. He had realised the potential of the web and HTML. He also realised the power of the HTML would be compromised if there were tags added just to control visual features. So in December 1996 he proposed a new format to control the visual presentation of HTML documents called Cascading Style Sheets (CSS).

CSS was simple to use and fault tolerant like HTML. Like HTML if a browser encountered CSS it didn’t understand it ignore it. If the selector didn’t exist or the property wasn’t recognised the browser would just drive on by.

selector {

property: value;

}

In the same year that Lie had created CSS a designer called David Siegel published a book called ‘Creating Killer Web Sites Online’. In the Siegel’s book he described a series of clever techniques to help designers make web pages more similar to printed ones. Showing them how to create designs like those you could create using desktop publishing software. A lot of these techniques were hacks. Soon, designers were starting to use TABLE tags and spacer GIF files to help them to create these more compelling design layouts. The techniques misappropriated a lot of tags and destroyed their semantic value.

A year before Lie’s proposal for CSS and Siegel’s book, Brendan Eich, a developer working for Netscape, created the first multi-paradigm programming language for the web: JavaScript. Although initially it wasn’t supported by many browsers it wasn’t long before the many started shipping with support for it. Unlike HTML and CSS, JavaScript isn’t fault tolerant. If a browser encountered JavaScript it didn’t understand, it would throw an error.

In the early 2000’s after the dot com crash, the web entered darker times. These were the times of the browser wars. A time when brave ‘Standardistas’ web users, designers and developers advocating web standards and persuading browser manufacturers to stop competing against each other by creating proprietary technologies. Instead they encouraged working together to create a better web for everyone.

Birth

In 2003 at ‘SXSW Interactive conference’, designers Steven Champeon and Nick Finck introduced the phrase “Progressive Enhancement” in a talk that they gave. Their idea of “Progressive Enhancement” was that an HTML document was made to work with the lowest tech browser’s functionality. Then, further functionality and enhancements to the presentation and behaviour, were then added using CSS and JavaScript.

Lost in translation

The term “Progressive Enhancement” has come to have different meanings to different people over time.

In 2015 at the Responsive Field Day Conference Tom Dale creator of the Ember JavaScript framework defined “Progressive Enhancement” as a technique.

“Progressive enhancement (n.) is the rendering of HTML on the server and then adding behaviour using JavaScript”

At that same conference Jeremy Keith described “Progressive Enhancement” as a process and outlined three steps which we could follow to design using this approach.

  1. Identify core functionality.
  2. Make that functionality available using the simplest technology.
  3. Enhance!

A bigger picture

Whilst I disagree with Tom that “Progressive Enhancement” is a technique and I agree with Jeremy that we should view “Progressive Enhancement” as a process,I think we should start thinking of “Progressive Enhancement” beyond screens and browsers. We should start considering the “Internet of Things” (IoT) and beyond. I would suggest just modifying Jeremy’s steps slightly so that they cast a wider net:

  1. Identify core purpose.
  2. Achieving your purpose in the simplest way.
  3. Enhance and iterate.

Whilst identifying core functionality could be the same as identifying the core purpose, the reverse isn’t always true. Achieving the core purpose in the simplest way doesn’t always need technology. And, whilst enhancement is key, provision should always be given to iterate the solutions you create. I say “solutions” plural, as opposed to “solution”, as often you may need to create several. But, this is not always the case.

An example of how this might be: What if I’m a vet and I need to medicate a kitten which is very unwell? I need to know the kitten’s weight to administer the correct medication.

My core purpose is to know the kitten’s weight before I measure out the medicine.

  1. I could make a mechanical scale that allows me to weigh the kitten. I can then record the weight in a notebook and then measure out the correct prescription to treat it.
  2. It would be helpful if I could measure the kitten’s weight more accurately so that I then use less medicine. The medicine is expensive and a more accurate dose will reduce the kitten’s chances of suffering side effects. So, I decide to add a digital sensor that enables me to record its weight more exactly.
  3. I then might decide it would be nice if I added a small computer with a hard drive and a basic lcd display and some basic controls. That enables me to record every time I weigh the kitten, so that I don’t have to remember to note it down in my notebook.
  4. I then might add a bluetooth so that I can aggregate the data to an app on a phone or tablet. But I might then decide that the overhead of maintaining it might be too great. Instead I iterate and enable the scale with wifi that I may post the data I’m collecting onto a website where I can then visualise it and share it with my peers. This allows me to then compare notes with other vets performing similar treatments quickly and globally.

The fundamental purpose is to understand the kitten’s weight so that I can measure out the correct medicine. I can do this with the mechanical scale. I can share data I write in my notes with my peers through email, phone calls or even in person at industry conferences.

The beauty of following a progressive approach means that I can create efficiencies that don’t compromise the objective. Indeed, if a part of that process fails, a progressive approach beyond technology doesn’t mean we don’t use technology. I’m a designer that considers web and brand based solutions, but just because I have those hammers, not all my problems are nails.

A person centered approach

Understanding people and their needs is key. We shouldn’t start by looking at the average user and making assumptions. Research is key and looking at users is important, but we need to look at the extremes. That might be the users on the poorest connection speeds and the oldest browsers, followed by the fastest connection speeds and the latest browsers. If we understand what the extremes are, we can make robust design solutions. We then don’t need to to worry about the rest, as it’ll take care of itself.

Sam Farber founded OXO an award winning cooking tools company as a result of improvements he made to an everyday vegetable peeler. Whilst on holiday with his wife, Betsy, who suffered from arthritis, he noticed she found it difficult and uncomfortable using a peeler with a standard design. This sparked an idea for Sam, sohe and his son hired “Smart Design” to come up with a solution. These vegetable peelers became popular with people suffering from similar difficulties to Sam’s wife. But, they were also championed by Chefs and kitchen professionals across the globe. The design for the peeler that Sam had conceived won countless awards. Sam took his approach to creating them and started applying them to improving other tools.

Break things down into their fundamental components

In the film Inception, a specialist team led by Leonardo Di Caprio are hired to convince a billionaire to change his mind on a big financial decision. They do this by planting a suggestion of an idea that will become the catalyst for him to change his mind. They do this by entering his dreams. I don’t suggest you try and seed ideas in clients or colleagues dreams. I do, however, suggest trying to steer people toward a progressive approach through subtle persuasion. You can do this with real world examples. You can also do this by showing how broadening your view can present opportunities. Opportunities outside your project’s perceived domain.

WhatsApp is 1 of 1200 messaging apps in Apple’s app store. What makes them unique compared to the others is that they created their app for other platforms, creating a J2ME version which allowed them to explode in India, China and Asia as a whole. Providing an app to a poorly served audience was a big contributing factor to them gaining 600 million active users 2014. Consequently making them Facebook’s most valuable acquisition to date at US$19 billion.

It doesn’t need to be that grandiose an example. Broadening your view could also be …

  • Making the only emergency plumbers website that loads a legible list of services on a 3G connection on the train. It’s not just a nice logo, good customer service and a cool slider on your website that build your brand. Being able to access your core service and considering all your users is crucial to this too.
  • Making a website that uses existing tried and tested services, whilst allowing you to test your market. This could be using a WordPress WooCommerce theme to experiment selling a shop’s offline inventory online.
  • It could be investing in getting your company’s message right and having a set of solid well thought out brand assets. And using free or low cost services like WordPress to get your business or idea online.

My path to progress

Progressive enhancement is more than just working without JavaScript. Although in the past I have gotten caught up with design and by accident, into thinking it is. There was a time when I spent a lot of energy trying to come up with smart solutions around this. I would try to mimic behaviours best suited to JavaScript by misappropriating CSS and HTML. This was because I had started to fear I was using the wrong technologies to solve problems. Fearing I was applying them badly or not following whatever best practice was being championed at the time.

I’ve often felt lost at sea with a lot of the new technologies coming along and the speed at which they happen but then four things happened:

  1. I started to reconsider the first’s: Mobile-first; responsive-first; accessibility-first; content-first; security-first; offline-first; documentation-first; API-first; performance-first. All were valuable considerations. But, instead of viewing them as techniques I viewed them as check points in my simpler progressive process. I found a lot overlapped and created constraints that helped me create better solutions.
  2. I decided to get work peer reviewed. Friends with whom I had spoken and had created software that they were distributing, on well policed platforms, often talked about the review processes. Whilst I wasn’t planning on selling software (or themes) on a platform, I did think having a third impartial party reviewing my work could be invaluable.
  3. I joined the WordPress community. Whilst I’m not suggesting that everyone gets involved with the WordPress community, I do suggest getting involved though with some sort of community that has crossover with your industry. For me, as it is a fundamental part of my day to day work, I found going along to WordPress meet ups and getting on the WordPress slack channel helpful.
  4. I embraced a beginners mind. I’ve decided that there is no shame in going back and relearning the basics again and again. I found many of Zac Gordon’s lessons on WordPress really useful. I’ve also re-read specifications and old articles over and over again and every time I always learn something new.

I now have a robust progressive process. And, because of it, I’ve gained more confidence and started to enjoy experimenting and learning some of the powerful new tools we have on the web. Things like CSS grid and WordPress’s powerful new RestAPI. The latter allows for JSON end-points, so that I can easily add things to pages without the need to refresh them. This can help to create more native app like experiences in our web browsers. But, as it was said in Spiderman: “With great power comes great responsibility”. Always consider the core purpose of what you’re trying to do especially if it’s on a client project.

What about the naysayers

It’s too simplistic

A lot of people say that having a progressive approach is to simplistic and it can’t be used on a project as complicated as theirs.

I would argue that this isn’t the case if a project considers progressive enhancement it can:

  • Reinforce the brand;
  • improve the accessibility;
  • make it more inclusive;
  • and often highlight inefficiencies.

It’s too complex

On the other end of the spectrum, people argue that having a progressive approach is too complex. They can get everything they need done with frameworks and plugins, or using techniques and tools that allow them to serve their typical user.

I would argue that there are plenty of tools out there that help you to do what you need to do quickly. There are plenty of frameworks and plugins out there that still work well using a progressive approach and consider the first’s. If budget is an issue and you’re using WordPress why not consider using a child theme? A lot of the default themes that ship with WordPress are ideal for this. I would also suggest trying to use less third party plugins.

Aren’t you potentially duplicating a lot of functionality

Yes. But, I would argue that it’s worth the trade off as long as you consider your redundancy. You’ll end up with a more resilient design solution. You’ll also have much more clarity on what the project goals are and you’ll learn things far more deeply.

Sounds like a lot of work!

Yes, it is a lot of work initially starting to develop a progressively enhanced process. Like learning anything new though, it’s about building the habit and embracing the change. When you first bake a cake you may need to use a recipe and a scale and carefully measure everything out. But, once you’ve done it several times, you barely glance at the recipe or weigh the ingredients because you’ll have built the habit. A baked cake is better than raw cake mix, which is better than just eggs flour and sugar. And a cake that you’ve baked yourself is going to be more memorable than one that you’ve bought at Tesco.

Vilfredo Pareto’s observation that only a “vital few” of the pea pods in his garden produced the majority of peas. 20% produced 80% of his peas. Once you’ve honed your progressively enhanced process, you should aim to spend 20% of your project identifying a core purpose and making it work in the simplest way. The remaining 80% of the time should be enhancing that and iterating through refinements.

Like an iceberg, the consequences of design decisions are much larger than what you might perceive. Decisions on processes can affect the success. And, ultimately affect how a brand or business is perceived. It’s essential that we consider function over form and its potential scale. Apple is successful as a company because it considered all of its potential influence both internally and externally. It’s what makes it such a premium brand.

Build your own progressively enhanced process

  1. Identify core purpose.
  2. Achieving your purpose in the simplest way.
  3. Enhance and iterate. Even if that means you need to duplicate parts of your solution for different environments.

Practice the first three steps until 20% is steps 1 and 2 and 80% is enhancement and iteration.

Refine your approach

  1. Remember to consider the first’s.
  2. Build peer review into your process
  3. Carefully consider using new things.

Sell the approach to others

  1. Subtle suggestion by defining the core purpose (think: the movie “Inception”)
  2. Use examples to illustrate robustness and it’s greater reach.
  3. Dispel the myths surrounding the subject. It’s not a technique that means something works without JavaScript.

Embrace progress and advance!

This article was first published on my blog here.