Progressive Enhancement – the web’s strength

The web is a big beautiful mess and we love it.

We’ve has come a long way from the web’s origins as hyperlinked text for scientist to share. We’ve collectively learned a lot about what makes the web so powerful and how to exploit it in that short time. We’ve also made mistakes, swinging off course to unhelpful design extremes, only to swing back and subsequently grow in our understanding as a result.

For example we escaped the pixel-perfect positioning print-media pretence phase [alteration apology] and now appear to be in a equally obsessive javascript rules, app-tastic, web as platform, native competitor frenzy. This time it’s being driven by developers rather than designers. And again the wide inclusive web community will no doubt auto-correct our collective course. The current discussion on the place of Progressive Enhancement (PE) with or without javascript and the what makes the web great, appears to be heralding the start of that process. I hope so.

3 layers of an M&M; content, presentation, clientside scripting

One view of progressive Enhancement

Evidence of the energy in javascript frameworks can be seen in ToDoMVC which has assembled some 64 example frameworks/libraries with new ones coming regularly (and remember MV* is not the only pattern in town). As Allen Pike quipped

Studies show that a todo list is the most complex JavaScript app you can build before a newer, better framework is invented

This situation has led

Let’s stop the rat-race and concentrate on building working sturdy solutions

Of all those frameworks I wondered how many support Progressive Enhancement as a feature? I’ve recently explored several of the latest and greatest frameworks for a new project. These included Angular, Backbone, Ember, Meteor, Polymer, React, Riot, WinJS and I found they don’t. You might argue “there’s a clue in the name “javascript frameworks”; they will need, well, er, javascript. Good point, but that misses what PE is about. The web page should work in a minimal browser, without CSS and Javascript but work better when the technologies are available. To have a blank page with no javascript is a fail.

In fact, I eventually reminded myself of mature (and so boring) jQueryMobile and jQueryUI which both state PE as a design principle but are not MV* in themselves.  T3js also mentioned PE but I’ve not explored how much it is supported. I’m interested to observe that many MV* solutions are not the same as the original Smalltalk MVC which was where I first experienced it. Some like the Flow architecture are much closer with no 2 way binding.

I suspect the reason for this lack of PE is as others have observed, namely with so many developer’s now coming to front end web dev many bring experiences of good practices from large software systems and naturally want to apply them. I’m not saying hard won principles such as modularity, separation of concerns, loose coupling and even MVC itself are bad. Rather the narrow focus on the software engineering with Javascipt can means we easily lose sight of strengths of the web and code ourselves into a corner.

I believe we need to remind ourselves to develop for the web, not just the browser. Better, design for users of the web, not browsers. Users are to be found using a range of devices,  a variety of browsers. perhaps with assistive technology and in varied contexts. We can’t control our users environment, whether its to get a pixel perfect layout or create a javascript platform.

The recent discussion on PE is distilling the concept that the web has it’s own strengths which derive from it’s heritage of sharing scientific information. These include hassle-free access by disparate people on varied devices. The web can do this like nothing else can and PE, responsive design and accessibility are key factors in ensuring it delivers on it’s promise. By supporting a wide inclusive range of devices and user capabilities we gain incredible reach that is of benefit both commercially and individually.

As  PPK said

We’ve lost sight of how to capitalise on that strength, though, and have to find our way back home.

I’m confident we will. My current thoughts are that PE is a key part of what makes the web work best and encompasses both mobile-first responsive design and accessibility. Design for small screens and enhance for larger ones. Design for basic inclusive access and enhance for optimal personalised experience. Taken together and with other techniques that make few assumptions will be able to reap the benefits of the web’s strength.

Perhaps someone will write  a dissertation to explain this user focussed aspect of the web to sit along side Roy Fielding’s “Architectural Styles and the Design of Network-based Software Architectures”. Any volunteers?

Posted in web | Leave a comment

CKEditor Accessibility Checker for content authors

Here’s a mini review after a quick play with a preview of the new CKEditor Accessibility Checker plugin for content creators. The plugin is provided by CKSource who lead the development of the open source CKEditor and provide additional commercial grade services.

WYSIWYG JavaScript editors

If your memory is as long as mine you will recall when WYSIWYG javascript editors first appeared back in the days when we spoke excitedly of DHTML (D = Dynamic = scripted). Designed for use in web programs such as Content Management Systems (CMSs, eg Drupal) these editors replace a basic HTML