As web developers, we often live our working lives inside a web browser. The size of the browser has changed over the years--we've gone from a predictable 800 pixel desktop screen 10 years ago, to a nearly infinite spectrum of device types and screen sizes today. While the medium has stayed the same, how we’re using it continues to evolve, changing everything from interactions, to communication tactics, to how we approach and manage the design/development process.
At last month’s Breaking Development Conference in Nashville, some themes emerged in the presentations about where web development is now and where it’s heading.
The most prominent were: the need for changes in the ways that responsive sites are architected and the way their workflows should be managed and sold. Many speakers touched on building modules or components instead of interlocking cascades of code, especially for experiences over many devices and form factors.
All of the presentations are available on the Breaking Development website if you create a login. Here are some highlights from panels we found interesting.
A running theme was that we can’t keep using the same old workflows and expect them to work for responsive sites. We are no longer delivering fixed-width web sites, so why are we still submitting fixed width creative comps to clients for approval? We need to shift to a more flexible workflow that allows us to spend more time designing in the browser. Changing process to use tools and methods like style tiles, interactive prototyping, design pairing and group improvisation.
Jason Grigsby started the conference speaking about developing mobile first. The idea is mobile uses fewer resources, so we should start with the base mobile site and add to it for desktop. A key phrase used during his panel was “progressive enhancement rather than graceful degradation.” Start small and add, rather than trying to fit desktop optimized (larger) images on mobile.
He showed statistics illustrating the slow-down of ecommerce sites since the adoption of responsive web techniques. The top ecommerce sites are 22 percent slower than in 2011 (5.94 seconds in 2011 compared to 7.25 seconds in 2013). This doesn’t seem like much, but 67 percent of consumers cite slow websites as the main cause of basket abandonment. The ideal load time of an ecommerce site is less than 3 seconds.
Spinning off the workflow theme, Ben Callahan’s talk, Prototyping Style, was about development processes for responsive web compared to traditional web. Going back to the theme of modularity, Callahan showed why the components of a single deliverable project (design, front-end, back-end) may not work as well for responsive. He introduced a concept called “Design Pairing” where designers are paired with developers, allowing design to be done on demand rather than in huge batches of Photoshop comps at the beginning of a project.
This approach has the potential to save weeks in design and speed up development substantially. The caveat is, you must have high-level developers who are capable of making design decisions on the fly.
When it comes to architecting responsive sites, a new methodology that is being recommended is something Brad Frost calls Atomic Design. The idea behind it is we’re no longer designing web pages, but systems of components. By breaking down interfaces to their most basic blocks, we can focus on building reusable pieces. We can then use these pieces together for templates and pages. Frost gives a more in-depth description of the methodology in this blog post.
James Williamson’s talk, Hooray, Icon Fonts, began by showing how icons can convey ideas without language. Icon fonts are not a new concept (remember Wingdings?) but they are very relevant now that mobile computing is taking over. Icon fonts are scalable, as opposed to images, and are much smaller in size.
During a workshop he also held on this topic, we learned how to design, build, and implement an icon font--a process we’ll likely find useful in building responsive sites in the future.
The internet is an exciting thing, and we're still just scratching the surface of what it's capable of. As we do this, it’s important to remember that new approaches may or may not be built upon processes of the past. Some staples--like icons--find new importance. Others, like how we architect or set up and manage the design/development process, may need to be rethought completely.
The bottom line is: Our goal should always be to imagine new solutions and then find a way make those ideas reality.