Sunday, 31 March 2013

Build a responsive site


Image source: Responsive workflow, but note that the order might not be this linear in reality.
Responsive typography and units
  • Responsive typography
  • Text design: produce a page that contains all the major HTML elements and a basic CSS style, so that everything will be covered.
  • Have three distinct heading styles, rather than ten with subtle variation.
  • Start with the <body> element
    body {
     font: 100%/1.5 serif; /* equates to 16px in most browsers */
     padding: 1em 20%; /* stop content from bumping up against the edges of the browser */
    }
  • The measurements, em & %, are relative to computed font size of its parent.
    Use ems to size typography and vertical measurements,
    and percentages for layout and horizontal measurements.
  • target / context = result
    h1 {
     font-size: 1.75em; /* 28 / 16 = 1.75 */
     line-height:1.1428; /* 32 / 28 = 1.1428 */
     /* Don’t need to declare a unit for the line-height property. */
    }
Responsive images and video
Media queries
  • Design various breakpoints: think first in terms of device classes, not specific devices. I prefer to let the actual content and images in the browser at the same time as making adjustments in response to the screen size. 
  • Add <meta name="viewport" content="initial-scale=1.0, width=device-width"/> between <head> tag. This tells browsers that a website shouldn’t be squashed down to fit on a small screen, and that the width of the browser window should be treated the same as the overall device width.
  • Adopt em-based media queries. Not only will our website adapt based on the size of the viewport, but the size of the font too.
  • To make media queries work for ie, here are the solutions:
Finally,
Test multiple devices, network speeds and in the wild.

(Resources: Build a responsive site in a week:
Part 1, Part 2 (typography and grids), Part 3 (images and video), Part 4 (media queries), Part 5, Responsive workflow)

Monday, 11 March 2013

The powerful cards

Remember: card sorting is not a user interface design method, but a knowledge elicitation exercise to discover users' mental models. It has to make users work harder and really think about how they'd approach the concepts written on the cards.
- Card Sorting: Pushing Users Beyond Terminology Matches
Exploratory card sorting
  • Purpose: to find out how your users classify the information in your domain.
  • Steps of open card sorting:
    1. 30-100 cards (with a title and a short description).
    2. Ask around 15 users to sort the cards into groups.
    3. Users give each group a description of what makes the group a group.
    4. Analyse the data. The terms people use to describe the groups will become the proto-headings of the navigation structure.
A title of the function
A short description
x 30-100 cards
Users: sort the cards into groups
Users give each group a description
Tree test
  • Purpose: to check if people can actually find stuff in your navigation structure.
  • Steps:
    1. 10-20 task cards (with a short description of a likely goal/task that the web site supports)
    2. Prepare a set of group headings, derived from an open card sort.
    3. Write down the sub-groups on the back of each card.
    4. Ask users to pick the group card and then the sub-group card while given the task cards.
"Find an exercise bike"
x 10-20 cards
+
(front)
Sports & Leisure
(back)
Fitness
(back)
Camping & Hiking
(back)
Cycling
Users: pick the group card and then the sub-group card
Trigger word elicitation
  • Purpose: to identify the words or phrases that will encourage users to click on links.
  • Steps:
    1. 10-20 task cards (with a short description of a likely goal/task that the web site supports)
    2. Ask users the words or phrases they would expect to find on a web site that supported that task.
Web broad
  • Purpose: to find out where users expect to find your functions.
Function familiarity test
  • Purpose: to gauge how often people use functions within your application, or to measure levels of understanding.
  • Steps:
    1. Cards contain a title of the function and a short description.
    2. Ask users to sort the cards into three piles: functions I use frequently; functions I use sometimes; and functions I rarely or never use.
    3. Give points and add up the scores derived from all participants to identify the most used functions in your interface.
A title of a function
A short description
sort the cards into three piles
Functions I use frequently
5 points
Functions I use sometimes
2 points
Functions I rarely or never use
0 points
Swap sort
  • Purpose: to find out the most important functions, features or tasks within your interface. This information would help you know how to priortise content.
  • Steps:
    1. Cards contain a title of the function, feature or task and a short description of it.
    2. Ask users to pick the 10 most important cards of them.
    3. Ask users to place the 10 card vertically and rank them in descending order of importance.
    4. Give points from 10 to 1 and add up the scores derived form all participants to identify the most important functions in your interface.

(Source: Card Games for Information Architects by David Travis)

Friday, 8 March 2013

Vision comes first

A user experience vision gives
  • direction, where the design priorities lie.
  • challenge inspires and excites people; brings inspirational sparkles.
  • focus
How to create a user experience vision - "design the box" or "working backwards"
  • Design the packaging of the "product" and agree on the most important message.
  • After 30 minutes or so, each team presents their box to the larger group for 2 minutes.
  • The purpose is to discuss the findings and reach a consensus.
How to refine the vision and present it to non-designers
  • Tell a story: personas and scenarios, which captures the winning idea.
  • Draw a picture: storyboards

(Source: Why you need a user experience vision (and how to create and publicise it) by David Travis)

Tuesday, 5 March 2013

Paper prototyping should never be dismissed

The worst possible way to design a web site is to have five smart people in a room drinking lattes and discussing branding. - Gerry McGovern
Paper prototyping is the method facilitating divergent design thinking, supporting iterative design, and most importantly, testing with users not designers. That is, in the initial phase of design, you should generate dozens of completely different ideas, develop interactive paper prototypes, test them quickly, evaluate and combine the best parts into a converged solution.

According to David Travisa, a paper prototype is a sketch - a quick visualisation of your ideas. He also gave an example illustrating its simplicity and artlessness.

I think the fineness depends on the objectives - to quickly generate ideas. It can be a sketch. To test with users, it should contain as many details as possible, and not be too messy to be understood.

Paper prototyping helper kit is an alternative provided by UserFocus, which supports 'cut and paste' numerously. Together with PowerPoint or Keynote to chain the screens, Morae can then be used to record usability testing sessions.

(Source: 7 myths about paper prototyping by David Travis)