IA Summit 2012 Notes: Beyond Channels: Context is King

This is part of a series of notes from the Information Architecture Summit from 2012. All posts will be tagged ias12. This talk was presented by Emily Wengert (@wallowmuddy on Twitter).

  • 2002 had simple world--intranets and websites. Since then have added phones, tablets, devices in cars, stores, augmented reality--just 10 years later: "I think we're all in trouble. I don't think we can keep up with this much longer."
  • How we approach new channels now (slow ramp-up to understanding the channel)
    • first understand the physical constraints (e.g. screen size)
    • then try to add the user again, try to align it with something we already know and oversimplify ("mobile is on-the-go!")--see Josh Clark's mobile myths
      • Myth: mobile is just used when people are on the go. "I think we got confused by the word 'mobile'" Maybe was initially was true but not anymore.
        • Better: mobile is the lazy man's computer. People just reach for the device in their pocket, hope they can finish the task there. 89% at home, 86% watching tv at the same time.
      • Myth: people want less on their mobile phone than on their desktop.
        • Better: shift priorities, don't remove features.
      • Myth: tablets are just an oversized mobile device or a simpler PC
        • Better: tablets are a content consumption juggenaut. They have created new behaviors, people will spend more time with tablet than on other devices
        • Tablet is replacing paper more than it is replacing other channels
  • We stop thinking about channel and start thinking about context: for instance, in coffee shop cream and sugar sit side by side, but they aren't next to each other in a dictionary or in a grocery store
  • Some example contexts
    • Place
      • Starbucks sign in airport: steam points to starbucks location. Someone had to know where the sign would be located. Print (generally) knows how to use location better than digital does.
      • iPad "augmenting" a department store is worse and slower than just walking around the store. Instead of adding to the store experience it is trying to merely duplicate it, but the users are already having the store experience and the device doesn't do it as well as the original. It could be telling people where items are, if they're in stock, if they could get an item in another location, but it's just the at-home iPad app that doesn't even know the person is in the store.
      • Think about:
        • Where is the user?
        • What goals do they have there?
        • Why are they accessing digital in that place?
        • What other (digital or non-digital) channels are around them?
      • Example: store planning vs visit
        • are they in my store or not?
        • store planning is making a list, finding store, research product, inspiration, inventory check...
        • store visit is checking off list, wayfinding, quick decision making (price, ratings, but not researching lots of items), price lookup, additional sizes and colors
        • change features you want to bring to forefront based on where the user is and what their priorities are at that location
    • Mindset
      • Pandora: set station and walk away
      • Turntable: more social than Pandora, dj wants to show off and get points
      • Pinterest: "I want to be endlessly entertained"
      • Baby registry: fear of making bad decision that would kill their kid--if you only think of as a place to add products miss opportunity to add reassurance, comparative studies, etc. that addresses the fear and uncertainty of having a child
      • Think about
        • what state of mind will my user most likely be in?
        • How might that affect their success in what I'm desigining?
    • Social
      • subset of mindset in many ways
      • Wedding registry: "I don't want to be judged" for having registry at all or for high price points, picture what each group of people are going to want to give--very different from the baby registries
      • Public kiosk: people worried e.g. about seeing weight entered on treadmill
      • Who is around you, e.g. mom's kid--what that means for patience, etc.
      • Facebook social as a platform--JCPenney duplicate their store in facebook but doesn't leverage or pay attention to the context of facebook; Target allows you to contribute to birthday present purchase
      • Think about
        • could there be any peer pressure in the mix?
        • How public is your user? How public would someone want to make what they're doing?
        • Is your user alone? with others? Kids?
        • Are there any expectations that social will be present?

Key take-home points for me:

People have different priorities, attention, and various limitations based on where they are and who is around them. Make sure to consider that when creating experiences for multiple channels. The context is more important than the specific limitations of the devices that they are using, so even though lots of new devices are coming out that we haven't even though of yet we can get up to speed faster if we consider in what context the experience we have in mind is going to happen.

IA Summit 2012 Notes: Adapting ourselves to adaptive content

This is part of a series of notes from the Information Architecture Summit from 2012. All posts will be tagged ias12. This talk was presented by Karen McGrane (@karenmcgrane on Twitter). Slides are on Slideshare.

  • We need structured content to adapt to multi device future
  • Publishers are like a bellweather or a canary in a coal mine. They are forced to adapt to content problems more quickly than other companies
  • Publishing companies don't have enough people or resources to populate all devices with customized content: "we cant afford to be creating content that will appear on only one platform"
  • Case Study: Conde Nast
    • Paul Ford: This is the golden age of PDFs on the iPad
    • Conde Nast creates custom ipad versions of major titles (GQ, Glamour, etc)
      • not searchable, not selectable, cant save it: it's a giant heavy graphic
      • They are translating all of their art direction into digital twice for portrait and landscape layouts
    • Sales of iPad issues have dropped precipitously since initial novelty. Glamor (their most lucrative print tilte) sold only 2,775 copies in November.
    • Conde Nast changing to more flexible strategy: create once and distribute everywhere, start with workflow to support all of their designs
  • Case Study: NPR
    • COPE: create once publish everywhere. API lets them get content out in variety of different contexts.
      • creates clean, well structured, flexible content
      • no custom development for multiple platforms
      • text, images, audio from CMS runs through API
      • Can see exact same story in NPR.org, mobile site, app, user generated NPR app, public radio player (pulls in from 500 public radio stations), etc. Platforms talk to the API and make the design decisions appropriate for the device (and not how the content is structured by the CMS)
    • NPR pageviews have gone up 80% because of api
    • Biggest impact is mobile strategy: they put the work into structured content and API up front instead of lots of custom development for each platform so they are able to get new apps out quickly
  • Future of adaptive content
    • Set up a reusable content store from the beginning--don't know where content will go or how it will look in any particular channel, but will have the flexibility to reuse it on any new channel in the future
    • Case study: TV Guide
      • in 80s realized in content business, not magazine business
      • required writers to write 3 versions of descriptions: small, med & large
      • didn't want all of their content locked up in files, wanted a variety of flexible content to use in the future
      • company that publishes magazine sold recently for $1--no value in magazine publishing business anymore, their value is the reusable data to sell to variety of platforms
    • multiple sizes--headlines, summaries, etc.
    • meaningfull metadata--platform needs to be able to query content for size and characteristics, platform can make decisions about what it wants to show
    • written for reuse--don't think about use in just one context
  • why are the news organizations able to innovate
    • news organizations already have structured content: journalism students are tought to create packages of content: (headline, deck (short summary), lede (put the most important ideas in first paragraph), photo, captions (of photo) & cutlines (summary of photo), nut graph (bulleted summary of article)
    • however, in a magazine content and form are tightly integrated and publishers have a hard time imagining content set free of appearance
      • hard to think about content broken into little bits, hard to imagine where content lives because it's in so many different places
      • hundreds of years of print primacy have built a particular culture, process, workflow, values
        • Case Study: New York Sunday Review was designed for print first (with very large images) and then handed to developers. Desktop version of website is bad because no one thought about it, mobile site is actually broken
  • We are making the same mistake by designing for the desktop web first!
    • Case study: Amazon product page--most A/B tested page on the internet, but on mobile robot goes and gets data and puts up content until it runs out of space
      • truncation is not a strate...
  • *Content* first
    • not print first
    • not web first
    • not even mobile first
    • clean, well structured, reusable, flexible content
    • designed from the start to go into variety of contexts, even those you haven't thought about yet
    • break up marriage of content and form
  • WYSIWYG CMS infrastructure that lets you see in desktop webpage context, leads you to believe it is in fact "what you see is what you get" without any consideration that it might not be in any other context
    • content developed that way has to be retrofitted for reuse
    • we need a sematic content publishing system so chunks of content can be combined as appropriate for each particular platform
      • content templates encourage reusable chunks content, but that doesn't make it into the CMS
    • break apart content from its appearance on the page
    • people will write better content if they have better tools that fit their workflow, mental models, and metadata needs: "content management is the enterprise software that UX forgot"
      • if you are in the business of producing content, the content management workflow is just as important as the ecommerce workflow, but people don't have metrics for it, they just assume the content writers will learn to deal with it
    • need to take content management workflow usability and fitness to your content writers' needs into account when choosing a CMS, not just requirements like security and support: this is not a luxury, it's a requirement for adaptive content
  • demystify metadata to content writers
    • use metadata to programatically build pages: you are not an editor crafting every pixel on the page, give up the control that you think you have--but you get control back, too, by using metadata to show this content for this reason on this platform
      • metadata is the new art direction (Ethan Resnick)
    • use metadata to help prioritise content
      • How do you take content from the desktop site and put on mobile, where do things fit in overall hierarchy of page
      • Case study: The Boston Globe uses it to rank story importance and make sure their "top story" is interesting, not just the most recently published
      • Designers were already doing this work, but it was getting lost with redesigns and context changes. Metadata stays with the content.
    • use metadata to personalize content based on what you know about user--people have been talking about this for 15 years, and the database part is easy but we need to actually write that metadata to be able to do it
    • use mobile as a catalyst to get all of these benefits: "the more structure you put into content the freer it will become" (Rachel Lovinger)

Key take-home points for me:

Create packages of content including content chunks like title, short blurb, longer blurb, full text, image, and other metadata that lets you pick and choose what you want to display across different devices and different designs. We can use the metadata for other things too, like generating personalized pages full of content of interest to a specific user. Mobile is a wedge to get that to happen, but we need better tools too, the CMS workflow as it stands is not good enough.

How to get me to actually follow you on Twitter

To those companies that follow lots and lots of people in an attempt to get people to follow them back: here are some tips on how to get me more interested in following you, or at least to seem a little bit less sleazy and desperate:

  • Be relevant to my location or interests. I'm looking at you, roofing company in San Diego--I don't have a house (which, to be fair, may be a bit difficult to tell), I no longer live in San Diego (that's right in my profile), and I never, ever talk about home improvement projects.
  • Talk about something besides yourself. If you're fishing for followers like this you're going to get people who aren't necessarily interested in you but are interested in the general field that you're in. Talk about things that are related to what you do that are interesting to the people you want to attract. For instance, the aforementioned roofing company might remind people about routine gutter cleaning or provide tips on safe ways to install things on the roof alongside promotions of their own products and services.
  • Interact with your followers. Even if you're not willing to talk about anything but your own products, you can still prove that there's an actual person behind the account and not just press releases, someone I could ask for advice or details about your products if I find them sufficiently interesting. Also, if you have a link to your website or a press release in every single tweet you look like a spammer; this is a good way to break those up.
  • Don't follow me more than once. If I didn't follow you the first time I'm sure not going to do it if you keep bugging me.

Thoughts on all this vendor prefix nonsense

So, if you haven't heard, some web browser vendors are considering adopting -webkit- css prefixes because a whole lot of developers have been writing css that only uses the webkit prefixed versions of some of the new css3 properties. Bruce Lawson has a nice longer summary of what's been going on, if you want it. Frankly I haven't been paying a huge amount of attention because it all seems so silly (haven't we been down this road before? IE6 was the good browser...), but I've been informed that my point of view is an unusual position that no one else has been taking, and that I should blog about this. This probably means that no one agrees with me, but anyway.

The thing is, after several years of using new css3 properties, I kind of like vendor prefixes for several reasons:

  • They're a big red flag that says that this property, in particular, is not stable or finished, and is subject to change (see, for example, the gradient property, which has changed quite a few times over the past couple of years). I should use it with caution, pay attention to future changes in the spec, and be prepared to update my code. I have limited amounts of attention, so it's nice to know right when I'm using them which ones in particular might break.
  • They let me turn things off for particular browsers. Webkit implements things early so you can play, but it's often sloppy and doesn't always address all the edge cases right away. Usually when something makes it into firefox it's got all of the common uses covered. I have, in production code, intentionally put in the -moz- and un-prefixed version of a css property and left the -webkit- version out. I can still do this, since it's the webkit version that may get implemented in other browsers, but imagine if it were the other way. I like being able to separate one browser from another when it comes to the new experimental properties.

Now, I will grant you that using the prefixes is annoying and harder to read and maintain, but as someone who has made sites work with the IE peekaboo bug and other nasties, it really isn't that hard. Annoying, but really not that bad. And I don't compile my css, but I hear there are tools that will automatically prefix for you. For me, the potential benefits outweigh the difficulty.

And I do honestly wonder how many actual production websites are ruined in non-webkit browsers because the developer only used -webkit- prefixes. I've seen all sorts of webkit-only demo sites that could in fact work in other browsers if the developer had made the extra effort, but I don't think tech demo sites should really count. What are the broken mass-market websites? And what is broken, and why? If there are properties that are only available in webkit that are necessary for a site to function, perhaps the better answer would be to fast-track those properties into the spec?

Mood Boards with Pinterest

I may be a bit late to the party, but I just joined Pinterest. Mostly it seems to be used for crafts, recipes, interior design, and fashion, and my friends that enjoy those things have been on it for a while (beating my early adopter techy friends at early adoption). After playing with it a bit, I realized that it might also be good for mood boards, which are something I've been wanting to try but haven't had a new, from-scratch project to try them on.

Mood boards let you pull together design elements that match a particular theme ("shiny and slick", "old fashioned type and paper", etc.) to help agree on what the theme for a site should be. Pulling similar things that you like together is exactly what pinboard is good for--you can "pin" new design elements that you find on a site, add a new picture, or repin from Pinterest's very nicely browseable interface. I could imagine having clients create a collage mood board with Pinterest, especially using the repinning feature, to pull together elements that match what's in their heads, and then working with them to create a more structured mood board based on the elements they find.

Alternative voices for NVDA!

If you're using NVDA to test your website accessibility (which you should! (Note to self: actually do that on this blog...)), you may be as pleased as I am to discover that there are some alternative voices you can use in place of the default synthesizer.

I had been using Microsoft Anna with the Microsoft Speech API v 5 (I believe this is also called SAPI5), but, while I find it less painful than the default voice synthesizer, it's not very good. I'm trying out the Microsoft Speech platform, available starting with NVDA 2011.3, which has a number of voices available.

Starting with NVDA version 2011.3, the Microsoft Speech Platform is now supported by NVDA. You will first need to install the Speech Platform Runtime. Then you may browse the redistributable language packs for the specific voices for the languages you prefer. Some voices are low quality, so you may have to hunt around for the good ones. These are voices which are by default available in Windows 8. Be careful though not to install the MSSpeech_SR MSI files, as those are not voices. Those are for speech recognition. Keep looking down the list and you'll come to the MSSpeech_TTS MSI files for the individual voices, those are what you'll need.

I like the "ZiraPro" U.S. English voice, and the British one seems nice too. To enable the new voice:

  • Install the speech platform and the the voice pack
  • Start NVDA and go to the NVDA menu (Ins + N) -> Preferences -> Synthesizer and change the Synthesizer to "Microsoft Speech Platform"
  • Go to the menu again, Preferences ->Voice Settings and pick a voice

There! So much more pleasant and comprehensible!

ARIA, feature detection, and the lowest common denominator

For the past couple of months I've been doing a lot of work with accessibility.  Parts of the design of the website I'm working on are very dynamic, with ajax and inline changes and dialogs.  It's relatively easy to get these things to be keyboard accessible (though that has its difficulties, too, perhaps that's another blog post), but the big challenge is getting it to be comprehensible to those who interact with the site with screen readers.

One example of something I've done is a list with delete buttons.  When a user clicks the delete button, the item it belongs to disappears and a message appears informing the user that the item has been deleted and asking if they want to undo that action.

It used to be safe to assume (or so we thought, anyway) that screen reader users would have javascript turned off.  So as long as a site had a non-javascript fallback, it was "accessible."  Users with screen readers would get a new page, and their screen reader would read all of it including whatever changed, others would get something fancier like an in-page reload. So in the example above, screen reader users could get a completely new page with a shorter list and the success message at the top, everyone else would have the item removed inline.

But the WebAIM 2009 screen reader survey says that the "vast majority of screen reader respondents encounter scripted content".  Only 10% of those surveyed said they turned off javascript, 75% said they didn't, and 15% didn't know.  If 75-90% of screen reader users are getting the javascript version, just having a non-javascript fallback isn't going to cut it anymore. That means that in my list example most screen reader users would push the delete button, the inline removal and status message would appear, and the screen reader would not tell the user either that the item has disappeared or that a status message has appeared without further work by the developer.

Announcing new content with focus control

One method for getting a screen reader to announce new content is by controlling focus. When you click on items or tab through the links you change the focus, and every time the focus changes the screen reader announces the newly focused item.  Javascript can also cause the focus to change, and thus get the reader to announce something new.

This technique is limited in several ways.  First, only interactive elements cannot be focused in older browsers--in other words, the paragraph explaining that the item has been deleting cannot be focused (or announced), but the undo button can be. It's not a great experience, but it's probably better than a full page reload or no feedback at all.

Second, changing the focus also moves the screen reader's position in the page. If the user is in the middle of a list and the announcement is at the beginning, now they've got to move all the way through the list. The screen reader probably has hotkeys to let them do it quickly, but still it would be nice if they didn't have to do that.

Finally, it's just hard to get this to work reliably in all browsers (this is web development, what did you expect?! ;)).  Sometimes the focus just disappears unless you add a timer to wait before focusing. What it focuses on when you hit tab at that point varies widely, sometimes within the same browser. I even got firefox to decide that tab meant select the next line of text, or to say one thing and highlight another, or to just have the screen reader announce "Unknown object" or nothing at all.  Sometimes the presence or absence of a screen reader affects whether it works or not. All in all it's a pain in the butt.

Announcing new content with ARIA

A newer alternative to using focus is ARIA Live Regions. (If you're new to ARIA and accessibility, I highly recommend the design pattern section of the ARIA author guide, it's very helpful not only for the ARIA properties but for keyboard control and other accessibility best practices) ARIA live regions allow the screen reader to announce changed content or all content of a given section of a page whenever something is added, removed, or changed.

ARIA is still a spec, however, and not fully supported anywhere. And the wrinkle with using it is that it must be supported both by the browser and by the screen reader or you're back at the no accessibility at all state.

Since it is still a spec, I imagine there are a lot of screen reader users with browser/reader pairs that don't support it yet (if someone has real numbers on that I'd would seriously love to have them), so I tried to combat that by using both aria and focus.  Theoretically, ARIA-enabled users would have the entire "Item X has been deleted. [Undo]" message read to them, non-ARIA users would have just "[Undo]", and everyone else wouldn't notice anything.

That is not what happens. In some ARIA-enabled browser/screen reader combos, the reader will begin to read the status message, then get interruped and just read "[Undo]". This is actually worse than not adding ARIA at all.

The need for feature detection

This is actually a classic problem for web development. Theoretically, a site can be designed so it works well for the lowest common denominator, and is progressivly enhanced for newer and newer browsers. However, in practice the browsers that fall between no support and full support frequently implement only some of the required features, or they implement them badly or incompletely, making the experience much worse than the no support scenario. But we can detect which features are available, or sometimes check how they're implemented (e.g. IE6's box model) to figure out if the experience needs to be degraded to the next tier down or otherwise altered in some way.

The list example would be a great place to use feature detection--if there's no ARIA support, focus the button, otherwise don't.  Unfortunately, so far as I can tell there's no way to detect if there's a screen reader at all, let alone anything about ARIA support, which leaves me with the following options:

  1. Remove javascript, provide a worse experience for non-screenreader--users (most of them) but a semi-accessible one to the screen reader users
  2. Give up on the new stuff, just use focus--most users will not notice a difference, some screen reader users will have a worse experience than they could have but it will be semi-accessible for all of them
  3. Design for the future, expect users with old screenreader/browser combos will eventually upgrade to a much better experience--users without screen readers again won't notice a difference, users with screen readers and ARIA will have a pretty nice experience, for everyone else it's inaccessible (but it's a decreasing number....)
  4. Provide a second site without javascript
  5. Give up on the whole accessibility thing entirely, it's just too hard

I don't like any of those options, but I need some help from browsers and screen readers to make good compromises possible.

I have heard people argue against just what I'm asking for, or screen reader detection in general (and I appologize that I can't find links to the arguments). The people who don't want it worry that web developers will misuse the power, and we'll have sites that say "Sorry, you can't see this site because you're not using Jaws forWindows" when in fact the user has a browser that's perfectly capable of handling it.

The thing is, though, we've already done that and learned it was a bad idea. I remember sites I couldn't access for not using Netscape 3 when I was using IE 5 (back when that was a good browser). We know better now, and I think those of us who know enough to create an accessible site in the first place can handle the responsibility of screen reader feature detection.

It is possible that you will see sites that are alternative versions specifically tailored to screen reader users. And some people seem to think that's a problem, too, but personally I wonder if it's really that bad. Alternative versions don't mean less or different content, they usually mean different presentation. Mobile users get alternate versions all the time because the full-size desktop version just isn't a good experience on a mobile device for all sorts of reasons, but the developer can provide something better.  I wonder if maybe that's ok here, too.

And let's not forget, some sites already have alternate, "accessible" versions of their sites (option 4 above) because getting the original working is just too hard.  Feature detection might actually make it easier for them to consolidate by making it easier to make the original accessible for all users in the first place.

Email contact nicknames

I always find it a little jarring when I see email in my inbox from my parents with their full names. I don't think of my parents as Carol and Larry, they're mom and dad. It's worse when I want to send it--I think every single time I write an email to my mother I start by typing mom, backing up and replacing it with her name. This is especially irritating because I know a lot of other people with similar names, so I have to select between them or type the full email address, but I've only got one mom.

I figured out some time back that I can fix that on my cell phone by adding nicknames, and it just works when I start typing in mom or dad. I noticed tonight that gmail contacts also has this option, but apparently it doesn't use it anywhere. Their full names are still in my inbox and typing in "Mom" brings up nothing in the "to" field. Plus the contacts section, though better since the redesign, is still an awkward way to do this--what I'd kinda like is something more like the way IM client aliases tend to work, where I can just right click and nickname someone right there.

Oh well. I got sorting 10 after 9 in filenames in Windows 7, maybe there's hope that they'll get this one right someday, too.

Touchscreens, games, and Fitts' Law

I've been thinking a lot about mobile design lately--what makes a good small-screen design, what makes a good touch-screen design, and how does that compare to devices that have  a cursor like some Blackberry models, etc.  To that end, I've been trying out a lot of mobile apps.

One that I was playing with recently is called DreamScape.  It's a very pretty, enjoyable little game, the object of which is to pop bubbles.  More points if you pop multiple bubbles together with one tap.  It's very relaxing, rather like popping bubble wrap but with a little more skill, more aesthetically pleasing sounds, and pretty backgrounds.

I realized after a few minutes of playing that this game is all about Fitts' Law.  You get more points for more overlapping bubbles, and the more bubbles you have overlapping the smaller the clickable space is likely to be.  You get more points when you get the upgrade that makes the bubbles move faster.  I believe you get more points for smaller bubbles, though the rules don't really specify.  And the bubbles that are an instant game over are the largest size.  And it's doing all of this with a notoriously inaccurate stylus--the finger.

It's not really anything novel, games have been making use of size and speed to increase difficulty for ages, and this certainly isn't the only iOS game to do so.  But what struck me as interesting for other sorts of touchscreen applications is that the bubbles in some parts of the screen seem more difficult to hit because of the way I was inclined to hold my hand there: there are some angles where the place I think I'm pointing at does not actually match the place that my finger actually touches first.  That means that there are some places on the screen where you can get away with smaller buttons or targets than others.

It's something to think about for future designs, and to keep in mind when testing them.

Things in their proper place

I'm always thinking about design. Sometimes this leads to some really nerdy observations at inappropriate moments, but my friends say they love me anyway. Lately, having just finished (hah, "finished"...) moving, I've been thinking a lot about design with regards to furniture arrangement.

It's absolutely amazing how much less stuff I feel like I have when it's not in boxes or disassembled for moving.  It takes up so much space on the floor, and then it's out and in an appropriate place and hey, I can see the floor again.  Surely it's taking more space than it was before, and yet it feels like it's taking up so much less.

Part of that is I'm not having to vault over it just to get across the room, but I think it's more than that.  I think that things that are useful become somehow invisible until you need to use them.  The boxes and disassembled bookshelves are not useful, they are in the way, and they're a reminder of all of the work that's left to do.

I've heard people talk about technology like microwaves as "becoming furniture," which is the same sort of effect--it's no longer a gadget that must be oohed over or deciphered, it's a useful tool that lives over there and that no one thinks about much.

There's a lesson for me in interface design in there, though I haven't quite decided what it is yet.  But as I design in the future I'll be thinking of turning menus, etc. into furniture.