Wednesday, May 23, 2007

Fast, Cheap & Somewhat in Control: 10 Lessons from the Design of SlideShare / Rashmi Sinha

Monday, March 26, 2007; Closing Plenary

Creator of MindCampus (user experience research product) and SlideShare (shared space for slideshows) shared insights on application development and IA.

Observations on current web:
  • Agile development is part of Web 2.0.
  • 1st generation—sharing without context
    2nd generation of social networks—connect over objects (photos, question)
  • Users drive navigation; Let good content rise to the top

SlideShare

  • “myspace for over 30-yr olds”
  • will be adding audio soon
  • some are using as courseware
  • Will be releasing API

Approach to developing SlideShare:

  • Create and get feedback afterwards; get answer to the real thing.
    a. Needed to see in use to understand use of the social system.
    b. Don’t have the tools to anticipate social system
  • Don’t need personas when social software users pound you with advice.
    a. Customer service as user research; monitor blogs/rss
  • launch first, refine later
    a. don’t over-analyze
    b. look at best practices, make a guess
  • constant connection with users by monitoring activity and other informal ways; whole team responds to issues that arise.
  • designer-developer role in the team allowed for easier communication—less need for design artifacts; hybrid roles are more common in small teams
  • under invest in visual design—let users feel ownership of space; users less afraid of messing it up
  • Focus instead on making the app as fast as possible.

Much of this approach is surprising and was experimental (seeing as she first developed a product to assist in user research). Through this development, she discovered:

  • you do need to do user research when feedback “becomes a torrent”
    Too much input, then you can’t process.
    Need to decide who you are building for
    New team members need summary info
    Need to improve beyond “low hanging fruit”

Possible application to L&ET:

  • What tools do we provide that could be useful in a "mashup?"
  • How do we staff support for the apps we’ve built?

Links for More Info:

Project Touchstones: How to Bridge Competing Viewpoints and Build Vision, Consensus, and Innovation / Jess McMullin

Monday, March 26, 2007

A key to working with business is to become a peer--design deliverables together.

Tools:
  • Affinity diagrams—sticky notes
    With any data where trying to ID patterns
  • Sketching with clients—conversational; use as a prop to articulate priorities (ask them to draw and then why did you draw it that way)
  • Design the Box—design the elements of packaging (name, tagline, 3 key selling features, imagery/color/type; feature set)--helps to focus on the important
  • Backcasting—start at ideal; what are assumptions and what has to happen—looking at dependencies/relationships; back to current situation
  • Mental model/alignment diagram--lines up user activities with features of product--can build on wall with stickies

Principles for transforming from review/approve to working together
1. codesign—get over hesitancy of showing unfinished work
2. simple—should not have to be an expert to participate
3. concrete—sketching, sticky notes
4. flexible—should mean different things to different people; see technical and business implications in deliverables
5. evidence based—informed; secondary research (gender and video games); qualitiative research—looking at users in context
6. surface agendas—look for things that will; some things are easy to hide agenda behind; figure out how people really feel

Approach
1. getting people to work together—need to have the important folks at the table (ex: marketing VP); difficult to get them to commit
2. peel back the layers—get to agendas

  • ask 5 why’s of any type: how is that important, why did you come, what do you hope to learn

3. partner, pilot, publicize—partner with influencers; small pilots; publicize the success; pulls in senior executives; need to have people there to “make sure you are doing the right job”

With sketching—can stay away from literal representations to help to remove from final product if people tend to get too committed to their view as final; stress at front that we will rip all of it up; emphasize that business skills is what is needed—not design

Consultant versus in-house challenges—point to processes already in place; then add the notions of codesign.

Application for L&ET:

  • We have the perpetual problem of potential candidates for this type of thing with no time to participate. I think that if we went intense and made quick progress, that folks would be motivated to participate.
  • Projects to try this one:
    o search box
    o room scheduler
    o Staffweb
Links for More Info:

Finding Innovation in the Five Hundred Pound Gorilla / Kevin Cheng, Tom Wailes

Sunday, March 25, 2007

Two Yahoo! employees shared ways that innovation is encouraged at Yahoo!

  • Hack Days—24 hour brainstorms
  • Google 20%--engineering dept spends 20% of time to work on own projects/innovate
  • Scrum—agile, short cycle (2 week) product releases

Need to overcome fear of:

  • wasted time,
  • high cost,
  • diverted resources,
  • failure,
  • missed opportunities,
  • unknown


To overcome fear, start small.

  • Design Day—took user reearch; 1 day, several people; storytelling
  • Local Field Day—45 people, split into 3-person groups, local stakeholders, went to users on same day, made poster boards to ID problem areas
  • Design Exploration—2 days, 2 designers, work into low time; follow with stakeholder review
  • Water cooler conversations—don’t freak people out, plant a seed instead; when multiple people planting a seed, it's important to not go on and on (eventually falls on deaf ears); then escalate; allow the other person to have their own thoughts
  • Consider your sphere of influence--advocate at the level where you do have influence, and then let others influence up the chain for you

Build trust

  • Transparency and visibility; give people ability to see into the process
  • Make clear design deliverables for stakeholders
  • Have a low barrier to entry into the team
  • Do less design deliverables like wireframes and more cartoon storyboarding, prototyping, product simulations to give feel of experience—communicates with others and works through design process (Wireframes as not communicating the concepts or feel).
  • Get more people involved in idea/scope; less involved later while trying to crystallize ideas
  • Brainstorming across functional areas of the organization. Recruit the design team to help the rest of the organization think through the needs.
  • Keep stakeholders informed. Visualize ideas in a way that stakeholders can understand right away. (ex: Video showing user experience—storytelling how a user uses the site; ex: flash video of personas—short and sweet)
  • Build track record

Making Believers

  • User research; field studies
  • Interviews, diaries, watching users in their environment

Overcome fear by making time
Building trust by involving people
Making believers so it can happen

Related Links for More Info:

The Conversation Gets Interesting: Creating the Adaptive Interface / Stephen Anderson

Saturday, March 24, 2007

The beginning of the abstract for this presentation provides an excellent intro:

"With the proliferation of rich Internet applications and interactions more closely aligned with how people think, we face some interesting challenges:

  • Do we design for one common audience and common tasks, or tailor applications around specific audiences and their unique activities?
  • How do we resolve the tension between creating simple applications that ‘do less’ and the demand for new features that some people really do need?
  • As we move beyond usability to create desirable interfaces, how do we handle a subjective domain like emotions?

"These types of challenges could all be addressed by creating a truly ‘adaptive' interface."

Examples of ways that applications could be/are being tailored for niche audiences (i.e. "the long tail."):

  • Expanding text box to accommodate use
  • Using IP address to guess at correct location of user
  • If the person attaches multiple files, give him the number of fields he typically needs
  • Assume info based on meeting types—lunch meeting pulls preferred lunch spaces.
  • Look for iterative actions and reveal features over time to tailor to need
  • Increase the button size if this user consistently misses it
  • Color and saturation to indicate age and importance of content—old data fades in color (see: ShaunInman.com)
  • Prominence of a help link minimizes over time if you never use
  • To fit smaller/different display sizes, changing layout (liquid versus fixed) and content (disappears to fit in new spacebased on display)
  • For mapping application, collapse neighborhood driving instructions based on history.
  • Changing [help] text based on audience? (travel agents versus travelers)
  • Text changes based on regional differences (Coke, pop, soda)—just like we’d do in a conversation
  • Removing L-shaped global navigation when applications are displayed
  • Changing help based on what you know about the person (novice user gets instructions for simpler tasks like drag and drop)

Challenges:

  • These kinds of options/features are currently being done primarily with cookies. Could also use rich profiles.
  • OpenID may provide more options when small bits of info about a user can be put together to paint a bigger picture (which, of course, if also a danger).
  • Requires a clean separation of content and the application.
  • First, get the basics right (metaphor of using rough grit sandpaper first; fine detail later)
  • Disclose what you are doing.
  • Provide opt-outs (i.e. "Please logout if you are not [Fred]."
  • Be wary of changing spatial organization (users will look for the same content in same spot)
  • Ease into this kind of info
  • Could use Web 2.0 model of testing live on users

Links for more info:

Information Architecture in Second Life / Stacy Merrill Surla, Lori Bell, Andrew Hinton, Beth Kanter, Peter Allison, Josh Knauer

Sunday, March 25, 2007

Introduction
  • Online gaming can be goal oriented (World of War Craft) or social networking-oriented (Second Life). Second Life can include goals, but they are created by the users.
  • Examples of using Second Life other than a game include for simulations, commerce, meetings, presentations.
  • IA of Second Life--visitors find it difficult to wayfind within environment
  • High learning curve to use, but then also to make environments (CAD, scripting, etc)

Demo of virtual (public) library area:

  • Promote literature through discussions; exhibits; author visits; programs
  • Individual libraries can join in
  • Answering reference questions
  • Created 10 islands in a year
  • Can sometimes crash during busy times
  • Difficult to control the environment—can be interrupted by anyone/anything
  • Can present immersive information (ex: Walk-in books)

Possible Application to L&ET:

  • Span spatial divide by working on a project (any project) within Second Life.
  • Do we have information that can be inserted into Second Life for users to interact with in different ways? Ex: within Second Life, some has combined Google Maps, info feeds and cataclysmic events.
Links for More Info:

@toread and Cool: Tagging for Time, Task and Emotion / Margaret E. I. Kipp

March 25 2007

Analyzed the tags at social bookmarking sites Connotea, and Del.icio.us.
  • Many of the tags were descriptive and useful for other users.
  • 16% (3049 tags) were time/task (i.e toread, toblog) tags. CiteULike has a feature for marking an item for later retrieval. Users appear to still tag things as "todo" or "toread."
  • Additional tags were affective (i.e. cool, boring). Appeared to be review-like rather than marking for future use.
  • some appeared to be for a specific group (i.e. course numbers)

Application for L&ET:

  • What implications are there if we were to allow tagging within LEO? Do we delete this kind of use, or do we allow it to flourish?
Link for more info:

Tuesday, May 15, 2007

The Brave New World: Usability Challenges of Web 2.0 / Jared Spool

Saturday, March 24, 2007

Jared Spool, of User Interface Engineering, reported on research in progress. His company’s mission is to long term, improve quality of lives by elminiating frustrations of technology.

Describes Web 2.0 as…

  • designing with total user experience
  • combining users and content
  • moves beyond traditional interface
  • development/design teams shrinking (because teams are able to do more with less staff by adding onto the work of others)

A recent 37Signals survey asked users what Web 2.0 meant to them. The answer: AJAX, interactive, Rails.

Design tends to focus on three stages, or mutations:

  • Talking horse stage, where people are building stuff with a technology focus.
  • Adding features stage. Ex: Amazon adding features like blogging.
  • Designing for experience stage; Web 2.0. Described as a backlash against too many features. Ex: Craigslist, where individual user experience trumps classic views of design

Components of Web 2.0
1. APIs
2. rss feeds
3. folksonomies/tagging
4. social networks

Web 2.0 is not user-created content. That has always been there. Web 2.0 is leveraging that user-created content.

Ex: Flickr

  • Incidentally, flickr is #5 in popularity for photo sharing. Photobucket is top.
  • Flickr uses a personalized homepage. Most users never see the generic, non-user home page after signing up.
  • Flickr has a programming interface to create stuff (i.e. APIs)
  • The Geotagging and printing tools were adopted after someone else (non-Flickr employee) did the development using the APIs.

1. APIs have their challenges. They make everyone a designer.
They can also create seamless experience with code from multiple sources.

Overheard in New York

  • Example of mashup between Twitter and Google maps
  • Took Twitter streams and mapped it with Google maps
  • The result is randome overheard conversations from the streets of New York. Here's an example from today (4/26/07):

Old lady: This is a full sandwich. I said half sandwich.
Waiter: What's the big deal? I won't charge you for the whole thing -- just eat half.
Old lady: No, no, you don't understand -- I am claustrophobic.

Yahoo pipes

  • Yahoo providing the tools to create mashups with RSS feeds.
  • Then, users offer those mashups to the public.
  • Ex: UST Campus/Library/Community Flickr Associations, which finds Flickr images based on a University of St. Thomas news source, the same university's news blog, and a local news blog.

2. RSS feeds
Challenges include

  • explaining them to users. When do things come and go? Is it refreshing for corrections? How do users subscribe?
  • How do users deal with the number of feeds they track? (Google reader caps at 100 posts before it starts deleting)

3. Folksonomies
Challenges include

  • How tagging is being used. For instance, are tags for “me” and “hi_you_what’s_up?" useful to anyone else?
  • Difficulty in figuring out logic behind someone else’s tag
  • Are you tagging for yourself or for others?
  • Do we monitor? Who? How?

4. Social networking
Ex: Netflix

  • Ratings from friends are separate from everyone else
  • Compare your ratings with your friends
  • Games based on ratings

Challenges arise when more than one person is involved:

  • How do we prevent systems from being “gamed” (scoring/ranking people)
  • How do we encourage behavior; allowing for good behavior to propagate; not anti-social behavior

Challenge of the "long tail" of the Zipf curve

  • only a handful of CDs become really popular;
  • some that become sort of;
  • many that only a few folks like
  • get more sales from those unique—long tail—titles (only sell a couple of copies but there are many of them)
  • 98% of the Microsoft.com users are using 2% of the content; what do you do for the rest of the content?

New IA Challenges with Web 2.0

  • Most of IA has been dealing with known authors and static content.
  • New problem: dynamic content (same known authors)
  • Even newer problem: dynamic content; unknown authors

    Ex: LinkedIn.com
  • tracks contacts
  • can input resume content and output new resume but users don't tend ot put content in correctly.

Possible Application for L&ET:

  • What applications in L&ET would lend themselves to APIs?

Best Practices for Form Design / Luke Wroblewski

Saturday March 24 2007

Forms are used online for
  • shopping
  • access (i.e. registration)
  • data input (same as physical)

And they are how users talk to companies online.

No one likes filling in forms, so let's minimize the pain.

  • Smart defaults, in line validation, clear path to completion can all help.
  • The context matters, including how frequently the person completes the form and how familiar the data is to the user.
  • Consistency can be used with a single voice; errors, help, success.

Ways to analyze performance include:

  • Usability testing; track errors
  • Customer support
  • Site tracking

Layout Best Practices

Top aligned labels (i.e. label is directly above the box that the user fills in)

  • good for familiar data
  • minimize time needed to complete
  • user sees label and form at same time
  • allows for flexible designing (space to accommodate different languages, for instance)
  • need more vertical space
  • contrast is important

Right aligned labels (i.e. label is to the left of the box, aligned to a right margin)

  • close association between label and box
  • harder to scan, which makes it good for unfamiliar forms
  • still faster completion times than top-aligned
  • fit more in vertical space

Left aligned (i.e label is to the left of the box, aligned to the left margin; boxes are left-aligned, too)

  • best for unfamiliar data (left aligned labels—fields left aligned too)
  • easier to scan
  • takes longer to fill out
  • user has no problem associating labels and fields
  • forces user to pause/analyze

Required form fields

  • Asterisk if the convention for required fields
  • Some forms label required fields even if all are required; this doesn't make sense
  • Consider getting rid of optional fields (increases completion rates)
  • For forms that are mostly requited, could flag optional instead of required
  • Make it easy to see required fields at a glance
  • Associate indicators (i.e. required) with labels

Field lengths

  • Expresses expectation—make smaller if only a few characters
  • Random sizes increases visual noise; keep consistent if no expectation of length

Content Grouping Best Practices

  • Important for longer forms (i.e. tax forms)
  • User should be able to scan info at a high level
  • Boundaries (white borders) introduces new visual elements
  • Use minimal amount of visual information


Actions Best Practices

  • Avoid secondary actions
  • Minimize reset button if not important—visual representation of the actions should match importance
  • Consider the use of buttons versus links, and the visual weight of the icon

Help/Tips Best Practices

Used for:

  • unfamiliar data
  • to justify reason requesting

Can overwhelm a form if overused—dynamic solutions could help

  • Inline exposure (pops up info when you click on field) (ex: Intuit snap tax)
  • User-activated inline exposure (i.e small ? next to field)—shows up below or nearby
  • Help visible and adjacent to data request

Interaction Best Practices

  • Make the path to completion clear
  • Remove unneeded fields
  • Allow for flexible data input (i.e. allow different ways to insert dates)
  • Use smart defaults
  • Direct line path to completion (literally, can be graphically illustrated)
  • Offer chance to save for longer forms
  • Use proper html (tabindex attribute) to allow users to tab through a form.

Consider progressive disclosure for complex forms

  • Hide advanced options behind a link (display content below the more common needs)
  • Gradual engagement by offering subchoices
  • Dialog to progress through steps—gradually engage (give them a vested interest)
  • Give them a reason to be excited—show why the user should want first, then give the form (or move them through)
  • Use metrics for what users include in a form (i.e. less than 20% adoption of field, then it goes to an advanced option panel)
  • Progressive disclosure is most effective when user-initiated
  • Maintain clear relationship between selection and result

Feedback Best Practices

Inline validation (error messages appear as the user fills out the form instead of after submit)

  • Ex: password strength indicator
  • Show right away if username is available

Give options as user starts to type
Length limitations (show how many of available characters)

Indicating errors

  • Clear indicator
  • Gives way to resolve—top level message
  • Duplicate language at error spot—secondary indicator

Indicate progress

  • Disable submit button (after user clicks) and replace with animation to indicate progress
  • "Doing something…" messages

Indicate success

  • Top level message—shows in context of form or…
  • Popup success message (in context)
  • Animation (highlight item) to indicate that it’s done

Don’t change inputs (don’t clear after submit)
Warn of likely unknown/difficult information needs before the user even gets to the form.

Possible Application for L&ET:

  • We should review our forms against these recommendations.

Mentions two online form-builders: