An Event Apart: Spirit of the Web

by Luke Wroblewski August 28, 2012

In his Spirit of the Web talk at An Event Apart in Chicago, IL 2012 Jeremy Keith described the principles that define the spirit of the World Wide Web and how they impact the work of Web designers and developers. Here are my notes from his talk:

  • How can you measure the soul of the Web? The Web is made up of electrons sitting on servers and traveling down pipes. Because the Web is not physical, we create different mental models to define it.
  • The Web is made up of protocols, standards, and formats. Effectively the Web is agreement. We all agree we’ll use Web standards and Web browsers agree to support them.
  • Files have unique addressable URLs that can be delivered over http. HTTP is the how: how things get transferred. The verbs of the Web (http) are get, post, put, delete. Quickly these boiled down to get and post requests.
  • Get is always a safe request. Post will do something on the server. You never want to include a post request in a hyperlink. Services like Google Web Accelerator can automatically click links and trigger actions.
  • You might want post requests to look like links, which can be done with CSS. But don’t use links where POST (delete, log out, etc.) is safer.
  • Files on the Web consist of HTML, CSS, Javascript, and images. We label bundles of these files as pages, sites, or apps and think of them as how they render in Web browsers.
  • William Gibson described cyberspace as a “consensual hallucination”. Web developers and designers used a similar concept to assume they understood the constraints of the Web: browser capabilities, speed of connection, size of windows, etc. We craved some level of control over the Web and these assumptions gave us a feeling of security.
  • Why didn’t designers accept the flexibility of the Web? We knew many years ago that screen sizes were flexible but our tools may have boxed us in. In tools like Dreamweaver and Photoshop, you start the design process by specifying a canvas size: height and width. We can’t let our tools make many of our decisions for us.
  • Instead of designing within a container, design from the content out. Use techniques like style tiles to set a look and feel for your content. Design UI elements as a set of patterns that can be reused across the site.

Progressive Enhancement

  • Responsive design isn’t about mobile or desktop design. It’s about the Web. The first Web pages ever were responsive from the start: they adapted to various screen sizes. They are also accessible by default. We do things to semantic Web pages to make them un-responsive and un-accessible.
  • Instead of talking about making Web pages accessible and responsive. We need to talk about keeping Web pages accessible and responsive.
  • 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.
  • We often get excited about new things we can use in modern browsers but a lot of time & effort go into thinking about how things will work in older browsers.
  • Progressive enhancement can be used at the highest level (HTML, CSS, Javascript) and at the lowest level (input types, attributes).
  • Accept the fact that Web sites don’t need to look the same in every Web browser. Once you do, the diversity of devices out there won’t be so scary.
  • You don’t have to optimize for every device but you might want to test on different devices. Starting a community device lab will give you access to more devices and help others with testing.
  • Images are not easily married with responsive design. Images are fixed size but the rest of the Web is flexible.
  • Right now people are using Javascript hacks to make responsive images work. Standards bodies are aiming to create elements that can be declared in mark-up. But ultimately, we want the format itself to be responsive (like JPEG 2000).
  • The progressive enhancement principle for images is: begin with small images by default and don’t download both high res and low-res images.
  • From a bandwidth perspective, downloading two images is bad but if you take a small image and size it to twice as big, then load in a bigger image with Javascript, it can feel fast to users. This behavior mimics what lowsrc used to do in older browsers.
  • Images can also be optimized for all screens through color adjustments and even blurring techniques. This is how designers used to make images for the Web. We were limited to 216 colors in the Web safe range.
  • The best way to be future friendly is to be backwards compatible.
  • Performance is essential on the Web. Perhaps the most common way to increase performance is to limit the number of http requests: smaller file sizes and less files.
  • You can also conditionally load content that only adds elements to larger screen sizes. Elements like third party widgets are great candidates for delayed loading.
  • URLs: uniform resource locators are the Web’s killer app. They allow you to access a resource by simply knowing its name.
  • URL design is really important but rarely thought through. Once again, don’t let your tools dictate your designs by having a CMS dictate what your URL structure should be.
  • The domain of site is often set but we can design the path. Apply the DRY (don’t repeat yourself) principle and consider using the address bar as an interface to content, even editing.
  • Designing your URLs first, allows you to think about the API of your site early on in the design in the process.
  • We’re the ones making the Web, we get to decide what it is and how to bring its spirit to life.