Dead Button Syndrome | em-tg

em-tg

Dead Button Syndrome

There is a frustrating design issue I’ve been seeing more and more often that I think should have a name. Navigate to the issues page for this repository. If you already have a slow connection, you might be able to reproduce this easily, but if not you can simply enable network throttling using the developer tools available in most web browsers.

Near the top of the page is a search box for filtering visible issues. As soon as the box appears, try typing in it or clicking the magnifying glass to trigger a search. If you’re fast enough, the search button will do absolutely nothing. Even worse, text you type into the box will be invisible and is deleted after a seemingly random interval.

I don’t know what the name for this is, so I’m calling it “dead button syndrome,” because when it happens to buttons, the control is visible on screen and interactive, but does nothing. I believe the blame for this falls largely on React and Next.js, but I’ve seen it happen even in native programs, so it seems the trend is not limited to the web.

That’s all I really wanted to say, but if you’re interested, here’s a brief history of what I think happened:

The REST Era

In the beginning, web applications worked using a paradigm called “REST.” The browser requested a URL, and the server replied with a document that described to both the user (via text) and the browser (via links and forms) how they should go about making further requests. A search engine’s website might reply to a homepage request with something like this:

InteRESTing Websites<br>action="results"><br>type="text" name="q" placeholder="enter query"><br>type="submit">Search

Have a nice day!

…which to the user appears as a text field and button that they can use to perform a search. The markup tells the browser that when the user clicks the button, it should navigate to a URL built from the string results?q= and the text that the user entered.

Web pages can be slow to load, so the browser will display this form on the screen as soon as it becomes available. Importantly, the button and text input will both be interactive as soon as they appear on screen, even if the “Have a nice day” text hasn’t downloaded yet.

Javascript changed this:

InteRESTing Websites<br>type="text" name="q" id="thetextbox" placeholder="enter query"><br>type="button" id="thebutton">Search<br>We're excited about Web 2.0!<br>id="output"><br>src="./jquery.js">

$('#thebutton').on('click', function(){<br>var params = { q: $('#thetextbox').val() };<br>var results = $.get('results', params, function(data){<br>$('#output').html(data);<br>});<br>});

Here instead of letting the browser make the request, a snippet of Javascript detects the submit button press, makes a request in the background, and then pastes the results into the page. When the browser loads this page, it will still show the text input and button, even though neither are functional until the Javascript files are later downloaded. The search button is a dead button!

The common advice of the time was to design a web page that worked correctly with Javascript disabled, then only use Javascript to make non-critical improvements to the user experience, a practice called progressive enhancement:

InteRESTing Websites<br>action="results" id="theform"><br>type="text" name="q" id="thetextbox" placeholder="enter query"><br>type="submit">Search

Note: fixed the "dead button" issue users were reporting<br>id="output"><br>src="./jquery.js">

$('#theform').on('submit', function(e){<br>e.preventDefault();<br>var params = { q: $('#thetextbox').val(), ajax: true };<br>var results = $.get('results', params, function(data){<br>$('#output').html(data);<br>});<br>});

This version works like the first example when Javascript isn’t available, and like the second example when it is. If the user is fast enough to submit a query by the time the Javascript loads then the website will still behave as expected.

The SPA Era

Web developers didn’t like limiting themselves to the browser’s built-in functionality, and so staged a revolt. Instead of following “REST” and twisting their designs to fit the model of forms and links, programmers invented a new architecture: the SPA.

id="content"><br>src="basically-everything.js">

There’s no more HTML. Instead, the UI is constructed dynamically at run-time by Javascript code. In fact, Javascript controls everything: UI, network requests, styles… even scrolling! With the added control comes the opportunity for improved user experiences: clicking a button doesn’t need to re-request the whole page, and instead can request a tiny snippet of data (JSON-encoded, of course) and update the part of the page that needs changing. In exchange, users need only tolerate a longer initial load time, and the accompanying loading animation.

The SPA paradigm is still the dominant one today, and has been around for so long that an entire generation of programmers has learned it as the only way to do web development. The term “REST” was...