Breaking Development: The Most Common Denominator

by Luke Wroblewski September 25, 2012

In her The Most Common Denominator: Supporting More, Sucking Less talk at Breaking Development in Dallas, TX Lyza Danger Gardner walked through the things that make mobile Web development hard and shared her methods of coping with the chaos. Here's my notes from her talk:

  • The mobile Web is hard. 3 Web pages, 2 images, one cache manifest, and no media queries took several developers and designers a full day to build, test, and deploy.
  • Now there’s even more to keep track of: things change and staying on top of everything is hard. We’re drowning in noise.
  • For a mobile Web project to be successful, we have to spend lots of time exploring new solutions and options. Often we don’t know what we’ll find.
  • So we come up with coping strategies: do something mundane & simple, or create something that doesn’t work well everywhere.
  • We need to keep one foot in the trenches but also keep one foot moving forward. We need to keep asking the deeper questions as we move through tactical things.
  • Our tactics need to align with the future, avoid pandering to the least common denominator, and reduce pain as much as possible.
  • We flounder in several ways: we grasp for a sense of control; we get distracted from the core meaning of our projects; we choose battles poorly or don’t realize we have a choice; we lack tested patterns and strategies; and we bare the burden to make things work.

Control

  • What goes into the Web is not what comes out. It renders differently on different devices. There is no “Preview” button that can show what a site will consistently look like.
  • We have to learn to set our content free so it can flow like water into the Web. That doesn’t mean giving up control over everything but focusing on what you can manage.
  • Start basic: get in the browser, make everything responsive and fluid; keep it simple.
  • Photoshop comps shouldn’t be the currency of the Web. This doesn’t mean jettisoning design but instead considering how you describe and sell Web design to clients. Stop selling the impossible: pixel perfect control.
  • CSS resets can help get things in order. Get your viewport under control. Pick one that works for you.
  • Responsive design is allowing the environment to have a role in how things work. As much as possible, carry this fluidity through your work.
  • Be aware of control masquerading as choice: frameworks that create app-like interfaces or promise mobile friendliness.
  • Let the customer into the design process. Stop assuming they are aren’t intelligent.

Core Meaning

  • There is one thing you do control: the core content of your service. Make it flexible, adapatable –it’s why people come to your site.
  • Content needs to be as presentation neutral as possible without losing its core semantic meaning. Too much control and specificity means we lose flexibility. Too little specificity and content becomes too vague.
  • Whenever you use lorem ipsum, ask yourself why? Try to get actual content as soon as possible and simplify before you suppress content.
  • If your exercise for making content, mobile-friendly is crossing out content and removing it, ask yourself why you need it in the first place.
  • Stop treating your CMS as one thing. It’s a series of interconnected process, tools, assets, and people. Taking small steps to decouple things has a big impact.
  • Know your options for storing content: HTML, Markdown, plaintext, JSON. Keep the philosophy of fluidity and responsiveness core to your content structures.

Choosing Your Battles

  • If you think your site works everywhere, you haven’t tested enough.
  • There is a point where you have to draw the line: choose your battles and know when you are not getting enough return for your investment.
  • Pragmatism often has to trump idealism. We need to get things out the door.
  • Each enhancement you build on your baseline creates risks. Evaluate these risks and prioritize appropriately.
  • Beware the binary feature support fallacy. Just because a browser says it supports a feature doesn’t mean they do.
  • Establish a baseline (HMTL5, CSS reset, viewport tag, etc.), Choose enhancement battles (HTML5 shiv, IE conditional comments for CSS, JQuery, custom modernizr), Choose performance (GZIP, reduce number of http requests, reduce overall payload, get the yslow browser extension to test).

Testing The Chaos

  • Have a priority list of what is most important in the project and a set of key devices. Test on/against these priorities.
  • Don’t put testing off until the end of the process. Use tight iteration loops. Mobile demands agility.
  • To test, you need devices: allot budget for a device library or use common-space device labs.
  • Core testing: desktop browsers, a couple crappy devices, and a couple good devices. Then more comprehensive testing at bigger steps.
  • Keep your devices charged and well organized. The easier it is to reach a device, the more likely you will test on it.
  • Ultimately, today’s mobile Web testing is broken but there are some tools that can help: Adobe Edge Inspect, Dragonfly, Wienre, etc.
  • It shouldn’t be so hard to test and ultimately people building the Web are where accountability rests. We need to be more vocal when things break and communicate the issues to browser makers and standards makers.
  • The Web should be a level playing field. We need to be able to rely on our HMTL, CSS, and Javascript so we can focus on what actually matters.