An Event Apart: The Long Web

In his The Long Web talk at An Event Apart in Seattle WA 2014 Jeremy Keith outlined how we can build Web sites for the long term and why we should. Here are my notes from his talk:

The Web is so big, it can be hard to consider it all together. At its core though, a Web site consists of text files (different formats): HTML, CSS, Javascript, HTML, SVG, JSON, etc.

Language is one of the most amazing inventions of civilization: it allowed us to transfer ideas between brains in real time/space. Writing allowed us to do that across longer distances and time spans: days, months, year, centuries.

Writing has evolved over the centuries into the system and set of codebases (languages) we use today. These systems were codified in formats.

Example: Francis O'Neill, the Chicago chief of police was an Irish immigrant who wanted to preserve Irish music. He hired Irish musicians and recorded 1,001 songs as sheet music. His work preserved Irish music for generations and is still used today.

Sheet music is a graphic format. When the Web came along, music was codified into a more lightweight text (ABC) format that could be shared quickly and easily.

Progressive Enhancement

Building a Website today means considering how it works on many devices. To do this well, you'll want to test on actual devices. A communal device lab can provide a place where you can test your sites.

Mobile first forces you to figure what is important when you design. The small screen requires you to prioritize the content and tasks you are creating.

Mobile first means working content first. When you do, you might want to consider the URL first. URLs are universal they work on paper, iPhones, command lines, and more. URL design is an important part of making sites understandable and hackable.

Designing your URLs first, allows you to think about the API of your site early on in the design in the process.

After you have URLs together and have thought through your design, break down the components in your site into their atomic bits. From there you can build a deliverable of the components as an HTML page.

The corollary to content first is navigation second. Lead with content and include a direct link to navigation at the bottom. A direct hyperlink works across all browsers and gives people access to navigation quickly and easily. It's a great baseline experience even if you want to enhance the navigation to something different on more capable devices.

The rationale of "no other site is doing this" doesn't hold water. Example: showing passwords by default -this is just security theater.

New input types are now available that allow you to specify formats like number, date, email. These bring up input-specific keyboards on many mobile devices.

Inputmode can be used to set input keyboards like "numeric". No browsers support this yet, but you can start including it because browsers that don't understand it, will just ignore it.

Datalist contains a set of options that can be added to an input field.

In a datalist, you can use placeholder text to insert a random suggestion inside an input field. This is a great example of progressive enhancement: not all browsers can see the most enhanced version but they all can render and use the site.

A Web app is hard to define but it seems to be "a web site that requires javascript to work." But progressive enhancement is not about supporting people who turn off Javascript, it is about avoiding a single point of failure.

Progressive enhancement: start with a baseline and layer on enhancement. It’s not designing for the lowest common denominator, its starting from the lowest common denominator and enhancing as much as you like.

Progressive enhancement is more about dealing with technology failing than technology not being supported.

Web browsers are very resilient, they simply ignore things they don't understand in HTML and CSS. Javascript, doesn't work that way. An error in a Javascript can break an entire Web page.

Make links, links and buttons, buttons. Don't use Javascript to create pseudo-buttons and links that will only work in some places.

Once you set a baseline experience, you can use Javascript to enhance it. For example, take a GIF image and replace it with SVG or Canvas.

SVG is a text file and an image format. But it may have a longer shelf life because you can view source on it.

SVG files can contain CSS and scripts. The CSS can contain media queries so you can change the SVG image as the image size changes.

Conditionally load content from third parties after your DOM has loaded. These includes are often blocking resources and will stop rendering of the page if you don't load them asynchronously.

Start with a link by default, then use Javascript to enhance to 3rd party embeds.

Conditionally loaded content means you don't need to serve exactly the same thing to everyone.

DNS prefetch, preloading, and pre-rendering can help you squeeze more performance out of a Web page. Micro-performance in 100s of milliseconds is a important consideration for the Web.

Performance is the most important part of the Web user experience.

Long Term Thinking

Future Friendly is an attempt to build Web sites that will last. Being backwards compatible is the best way to ensure your sites work on future devices.

Think in the short term (performance in milliseconds) and long term (hundreds or thousands of years) when you build Web sites.

The average lifespan of a Web page is a month. We assume the Web stays up forever but the truth is things disappear regularly. The first step is acknowledging we have a problem.

What about the long term viability of the text formats we use on the Web? HTML has the best chance of staying relevant. The Web has been around for 20+years and the first Web page still works.

Long term thinking is at the heart of HTML and unlike other technology formats it will last for a long time to come.