The Right Answer

Several years ago – in the late 1980s – I was in a graduate MIS class and the professor posed a question to which he made clear there were multiple answers. After a class discussion the professor brought up the answer he considered to be the right answer. (If you haven't read the problem and answer in the sidebar, do so now.) As I've recalled this event, I've been reminded of a few things, and I've tried to determine what the greater lesson has been over the years.

Problem: You have hired a worker who is to be paid 1 inch of gold each day. You have a single bar of gold that is 6 inches and can only cut it twice. Where do you make the cuts to pay the worker exactly the amount they have earned each day - what size are the three resulting bars?

Answer: Cut the bar at 1 inch from one end and 3 inches from the other end, resulting in 3 bars that are 1 inch, 2 inches, and 3 inches. Pay is as follows: Day 1 - the 1" bar; Day 2 - the 2" bar and receive the 1" bar back; Day 3 - the 3" bar and receive the 2" bar back; Day 4 - the 1" bar; Day 5 - the 2" bar and receive the 1" bar back; Day 6 - the 1" bar.

One of the most important lessons I learned in that experience is that there are typically several answers to a problem and they have varying degrees of difficulty, precision, and accuracy. Sometimes choosing the answer is easy – other times it would seem it is not. For example, if we're choosing which compression algorithm to use, we can relatively easily make the determination based upon whether we want to prioritize speed or the compression ratio; however, if we're trying to balance time-to-market, performance, quality, and user experience the answers are not so easily reached. In real-world scenarios, we may suggest to our hypothetical employer that they fold the gold bar 5 times and make the two cuts at the ends – that answer maintains time-to-market and improves the user experience (the worker has immediate full use of everything they receive), but is that the right answer?

Any time we find ourselves asking if an answer is the right answer, we must look beyond the surface of any potential decisions and ask what we would actually be doing – in language terms, what is the connotation of this conversation rather than just what is the denotation. Phrased another way – what are the patterns we are introducing intentionally and what patterns are we introducing unintentionally? Are we just doing what is good for our organization or are we promoting a greater good or are our customers (or users) seeing the benefit?

In the world of software development, managers and business leaders have been toying with the development triangle for years, trying to squeeze out the best solutions, and just because we're now dealing with web-based applications instead of desktop-based applications makes little difference. Granted, trying to keep the three legs of the development triangle balanced is difficult – and it's harder for some teams than others (but that discussion will have to wait for another post). It's made still more difficult by the fact that none of us like to have the scope of our project constrained by the balance of these three legs. Unfortunately, what many organizations do is prioritize their wants and needs over the needs of their customer. There certainly are times when this is appropriate – the customer simply cannot always be right – but this happens far too often to be valid, especially among Internet companies where development speed – enhanced by bloated code like bootstrap and jQuery or (even worse) user-agent dependent languages like Angularjs – is prioritized over a user experience that people argue simply must have all the bells and whistles. Leadership in these cases is somewhat like the obstetricians who argue that they must have the machine that goes ping, except in the real-world these cases are not intentionally comedic. As a result, many leaders who have prioritized development over user experience or have tried in vain to balance all the legs of the development triangle and not constrict scope, believe the use of various frameworks are a solution they can leverage, and many have attempted just that – going down the Angular.js rabbit hole, for example – but is that the right answer?

No, it's not the right answer. Is there a better answer? Yes. In fact, I would posit that there is a right answer for web-based development – one that prioritizes users over development – but it's one that few developers like or want to admit, because it's not, as we say, cool. The right answer is Progressive Enhancement. Simply put, Progressive Enhancement starts with HTML, and it should be semantic HTML which must include using the appropriate tags as well as ARIA attributes that make it as readable as possible by both humans and machines (I'm looking you, developers who use <i> instead of <em>, <b> instead of <strong>, and never use ARIA states and properties). After the document is created, it is styled using CSS – again paying attention to accessibility (e.g., using clip instead of display or height to hide content) – and finally, layering unobtrusive JavaScript on top of all the rest in a way that pays attention to performance.

Developing in this manner ensures that users will always be able to access your content – be it informational or commercial – regardless of whether or not someone's user-agent supports CSS3 or whether or not the user-agent supports JavaScript or whether or not anyone is doing something like pushing code live without having tested it and introducing an error as a result or blocking JavaScript (either intentionally or unintentionally – and yes, it has happened when a "parental filter" operated by an ISP in the UK blocked access to jQuery via CDN) or whether or not you're running third-party code that is not up to par.

Of course, one of the arguments that I've heard repeated is that there aren't that many users with JavaScript disabled and Progressive Enhancement takes too long, both to write and when rendering (because JavaScript-based rendering is much faster). So, let me just address those arguments – and let me say that this reasoning is not based on some ephemeral justice-based ideology but on solid experience building web pages. (If you're really curious about my work experience, read "A machine-readable resume", where there is both an image of a portion of my CV and a link to the full version.)

While the actual percentage of users browsing the Internet with JavaScript disabled is low (the number is arguably around 1%), that number does not count all the users affected by stuff that is broken by error-infested, untested code, nor does it count users affected by not having access to specific libraries because their ISP decided those libraries were potentially dangerous.

Neither of those groups take into account people who are using accessibility software for whom an otherwise acceptable web page offers a broken user experience. Granted, most accessibility software works acceptably with JavaScript, but without paying special attention to making your JavaScript-enhanced page accessible, e.g., by using aria-live or shifting focus to updated content, users with accessibility issues are still left with a broken experience. Because of the way in which accessibility software works with user-agents, the user-agents are not technically, potentially JavaScript-disabled in general, but the user experience is.

Yes, the number of users with user-agents that recognize a SCRIPT tag is around 1% – and 1% of nearly 3 billion is still a lot – but there is a significant difference between something potentially running JavaScript and something actually running JavaScript – a difference any philosopher should immediately recognize.

As for pages built using Progressive Enhancement not rendering as fast as those built using client-side rendering, I'm going to just come out and say that cannot possibly be true in anything other than a test that is non-analogous to real-life. I suppose client-side rendering might be faster if you were delivering a page with a lot of duplicated content, but in practice delivering a template, a client-side rendering library, and JSON data is not a much smaller payload because most content isn't duplicated. What we've really done with this approach is break up the content – the most important piece – into separate documents. To add insult to injury, there are issues of network latency for each of those three requests (for content), and potentially disastrous re-flow issues, not associated with CSS, as containers are loaded with HTML.

If you coerce a multiple-page application into a single page by delivering partial in-document updates – the way it was done in PayPal checkout products for example – you may see some actual performance improvements and users may perceive some performance improvements – though neither is guaranteed. However, in the case of in-context updates you have to take special care to make sure your page/app is still playing well with accessibility software or you're not only shutting out users you may be violating the law.

As an aside, adding all the accessibility hooks and building out any inadequacies in the various libraries and then testing all the extra code certainly has the potential to destroy any improvement you may gain by avoiding Progressive Enhancement.

Yes, saying you're improving the development experience (or your engineers' lives) is seen as sexy and cool by the engineers building your products and prioritizing time to market is sexy to those who have invested in your business, but as anyone who has pursued event the earliest steps in an Economics program knows, those words don't necessarily what you think they do – it's what your users think, and on the web it's a mistake to not prioritize the user experience over other things.

Our users may not always be right, but when we're trying to solve their problem, more often than not they have the right answer.

Note: if you'd like to read another's thoughts on a similar topic, Nicolas Bevacqua has a few thoughts, and has prompted a few comments as well.