As always, An Event Apart 2012 was an intensely inspiring and informative two days. The talks focused on a few major themes, at least in my mind, and I have broken my takeaway based on those themes: Content First, Responsive Design and Usability / Intuitive Design.

These notes are an overview of what really struck me at AEA12 but are by no means exhaustive. In them, I addressed or referenced seven of the twelve talks.

I didn’t touch on the excellent talks by Scott Berkun, Dan Cederholm, Jason Santa Maria, Whitney Hess and Eric Meyer, primarily because they didn’t fall within what I felt where the most applicable to me.

Content First!

We’ve talked about semantics and separating content from style for a long time but now we really, really mean it.

So, why now? What has changed to force us to get really serious about this separation? Finally, what are the implications of this separation?

• We were always kidding ourself, I believe Jeffrey Zeldman called it consensual hallucination, that we were in control of the content viewing experience.
• Tools and services like Instapaper, Readability, Pocket, etc. have made it easy for users to strip away our designs to improve the reading experience.
• We need to keep in mind why users came to our site. Not for the ads, or the related content, or the widgets but for the content. Our job is to serve the user by making it easy for them to consume our content.
• There will be pushback from other stakeholders but “Design that doesn’t serve customers, doesn’t serve business.” - Jeffrey Zeldman

The implications of this separation or the need for this separation are most readily felt on mobile and the real challenge with mobile is the content.

Karen McGrane focused on the tools that we use to publish our content and how we need to use them in a way that allows us to distribute our content to multiple channels both anticipated (mobile, apps) and those that are coming or that we can’t anticipate.

• Karen used the examples of Conde Nast and NPR, a contrast in publishing approaches
• Conde Nast has built iPad editions of their magazines. They essentially took a big picture of their print magazine and published it for the iPad. That’s not a mobile strategy.
• NPR took a COPE (Create Once, Publish Everywhere) approach. Their content is published in a CMS and distributed via an API to multiple channels.
• Results? Conde Nast has struggled to sell magazines on the iPad while NPR’s total page view growth has increased by more than 80%.
• Our CMS has to allow for structured content.
• Chunk vs Blob - If we are using a CMS, are we chunking the content with meaningful metadata or are we using a blob approach in which we have a single text field with a toolbar that mimics the mimics Microsoft Word?
• Are we coupling content to form? Are we applying style via the CMS or are we separating content and style?
• We have to think about the fact that our content will be published to multiple channels and platforms.
• We have to design systems that accommodate this need.
• We also need a better CMS workflow that meets the needs of our users.
• If our CMS workflow was a checkout process we would scrub every bit of friction out of it to optimize sales. We need to do the same with our CMS.
• The happier CMS users are, the better their content will be, the more content they’ll produce.

Responsive Design

Responsive design, a method for dealing with the varied devices and browser sizes that websites are viewed in, was outlined two years ago by Ethan Marcotte in his watershed article on A List Apart. In a nutshell, responsive design includes a flexible or fluid grid, flexible images and media queries.

In the two years since, responsive design has become one of the most talked and written about techniques since the web standards movement itself. I’m probably overlooking something that was equally monumental, possibly CSS itself, but if I am it’s because the need for responsive design is so great. Just as the need for web standards was great.

When it comes to responsive design, we always focus on browser window size (media queries) as the primary qualifier for segmenting users. Scott Jehl instead focused on accessibility and responsibility in responsive design.

Too often we think of accessibility as supporting those with disabilities but it really means being able to access the things that we build on the web and removing the barriers. As Scott travelled in Southeast Asia, he found that most people access the web over a cell connection. Access was a lot slower. A lot of the web didn’t work as well as he was used to. This was an accessibility issue.

• HTTP requests are a gamble. They are a chance to fail. If a particular HTTP request fails, does our site degrade gracefully?
• We are overly presumptuous about… our users, the networks, how people user our sites and about the scripts that we install and whether they load.
• The average page in 2012 is over 1MB. 196kb of that is the average size of JavaScript files. 63% of the 1MB is image files.
• CSS sends large amounts of code that devices will never need.
• Solutions? Reduce features. Remove content. Prioritize loading of essential content and defer the rest.
• Filament Group is attempting to solve the problems associated with all of these issues with their South Street Projects.
• Many of the solutions that they are working on look like excellent solutions. Some are available now, some will be released shortly. Check out the South Street Projects on the Filament Group github page to see if they will work for you.

While Scott Jehl focused on being responsible with the assets that we load to improve accessibility, Ethan Marcotte addressed the current state of Responsive Design and how we can cut through the feeling of being overwhelmed and start building responsiveness into our sites by solving the parts, not the whole problem.

How do we solve the parts of Responsive Design?

Solve the Layout

• Solve the layout by creating a flexible foundation. He went into some detail about how to do this but it is covered in his excellent book on Responsive Design from A Book Apart.
• Generally, we start with a full desktop design and then work our way down the food chain of media queries until we get to the smallest break point that we are going to develop for.
• This approach is backwards as “The absence of support for @mediaquery is in fact our first @mediaquery.”
• When we think about enhancements to our designs “we should start treating layout as an enhancement.”

Starting Small

• We need to tread carefully when dealing with density and the removal of content that is deemed unimportant. If it’s really unimportant on the mobile is it really that important at all?
• We should simplify our designs before suppressing content.
• display: none; is a last resort.
• Design your source order and see how that informs your design.
• Focus on the content.
• Move away from breakpoints connected to known devices.

Ads, Media and Images

• Ads have a fixed width with dimensions that are desktop-centric and there’s not really a responsive solution at this point.
• Smashing Magazine has taken an interesting approach to ads. Widescreen readers subsidize small screen readers. Ads are removed on small screens.
• Images and Video - Consider what is responsible to deliver to users.
• Check out the Responsible Images library on Github.
• A simpler page may be the answer.

Why all this talk about mobile and designing for mobile?

Luke Wrobelwski addressed mobile, which he contends is the seventh form of mass media following print, recordings, cinema, radio, TV and internet. If mobile is a form of mass media, then it changes the way we design for it.

Is mobile another form of mass media and not just the internet on a small screen?

By the numbers.

Is it massive? 371K babies born per day. 378K iPhones sold per day. 900K Android devices activated per day. 1.8 million mobile devices per day. Per Day!

Hitting us very quickly.  Fastest technology to reach mass market adoption. http://technologyreview.com/business/40321/

Connections. Can we broadcast onto these things? 6 Billion connections today. 10B connections in 2016. 26X world traffic growth.

Can it do what all of the things that mass media did before it? Yes, and more.

Luke did an excellent job at presenting the problem with designing for mobile using a desktop-centric mindset. In a nutshell we can do the following to help our mobile users:

• Don’t remove critical features but remove unnecessary form fields.
• Use input tupes and attributes
• Use touch gestures
• Push things forward using near-future technologies like facial recognition, finger identification, sms authentication, etc.

Why bother to put in the extra effort? These things are on us all the time. Always On. Available at the point of inspiration.

For those that would be attending the An Event Apart single day session on developing for mobile, Luke left us with a tantalizing question. “What’s going to eat mobile?”

Finally, Josh Clark and Jared Spool focused on usability and intuitive design in their own, entertaining way.

Buttons are a hack!

Josh Clark, the author of Tapworthy helped us think about how we can prepare our work now for what is to come - speech (Siri) and texture (touch).

Touch is going to remove the administrative junk that have been added for the desktop GUI. Touch cuts through complexity and allows us to work with information.

So what’s the big deal about touch? Why do we have to rethink our designs? The traditional UI doesn’t work as well. A tradition UI has tiny tap targets on a big beautiful screen. The further the target is away and the smaller the target is, the harder it is to hit the goal.

Gestures like pinching and swiping are the keyboard shortcuts of touch!

Unfortunately, web browsers aren’t very good at touch. We are essentially limited to tap and swipe. We need to focus on the browser less. The focus on browsers is a problem for our community. The web isn’t about browsers! The web is viewed in apps, books, and other containers where you don’t have control of the browser.

We have to think creatively about the solutions and implementations that we use.

How To Teach Touch (or anything)

How do we teach touch? Especially unlabeled and abstract gestures. The less a gesture resembles a real life gesture or a desktop convention then the more likely your gesture is an easter egg and that’s no good.

Jared Spool’s talk addressed user knowledge and intuitive design and really sort of dovetailed with Josh’s talk.

When something is unintuitive, it changes our focus from our original goal to just getting the unintuitive thing to work.

Jared explained the “Magic Escalator of Acquired Knowledge, MEoAK.”

We are interested in two points on the escalator.

• Current Knowledge of the user
• Target Knowledge the user needs to accomplish a task.
• The Knowledge Gap is the difference between current and target knowledge. This is where we need to do design.
• Intuitive Design is when What a user knows matches what the need to know to accomplish a task.
• Simplifying is when we bring down target knowledge to current knowledge.
• To understand current knowledge - watch users.
• To understand target knowledge - usability tests.
• Paper Prototyping helps you get to the knowledge gap.

Josh proposes the following for teaching touch.

• You’ve got to do it right. Your interface metaphors need to inform your user how to use your application. Apple Address Book swiping doesn’t turn the page but deletes content, for an example of how not to do it.
• Find a three year old and use them as your beta tester. They won’t get what the app does but they can test out your user interface.
• Think of yourself as a novice user.
• A gesture without a visual aid is inert.

He also suggests playing more video games and approaching the teaching of your users the way video games train a player.

• Coaching - but it has to be done better than Clicky. “Are you trying to write a letter?”
• Leveling Up - Ease your users into the app. As they demonstrate proficiency, show them new tips. Demonstration and practice. Think about your apps as levels.
• Power Up - Mastery is where the power ups come in. A reward. An achievement. Not just a useless badge.

The disaster known as redesigns

In addition to intuitive design, Jared Spool also addressed redesigns and how you should never do a major redesign.

• Large “Big Box” retailer spent $100,000,000 to redesign website. Launch day: 20% loss in revenues.
• Large law firm. Redesigned intranet to use MS Sharepoint instead of static HTML. The entire law firm was shut down for three weeks.
• One of the Top 20 Websites hired a top design firm for a complete UX overhaul. Pageviews decreased 40% on launch day.
• United merged with Continental, flipped the switch on website launch. Result: Complaints out the whazoo!

Experienced customers have high current knowledge. When you flip the switch, it goes away. Users are unhappy, of course. Even with training and support tools, they are unhappy.

Amazon doesn’t do big redesigns. They incrementally change / update. Little piece by little piece. You are bringing down the target knowledge by doing it incrementally.

An executive succinctly put it this way, “We’ll be successful if, the day it goes live, nobody notices.”

I’m thankful to all of the speakers and to Jeffrey Zeldman and Eric Meyer for creating An Event Apart.

Hopefully these notes are helpful to someone.

Now, back to work.

  Don't put anything here
  

• Author: G. Brad Hopkins
• About Me: I bought my first computer - an Apple Performa 6320 - when I was in college and have been building websites ever since. I like long walks in Illustrator and candle lit dinners with ExpressionEngine.
• @gbradhopkins