Archive for January, 2010

5 stepping stones for building social experience

January 29, 2010
  1. What’s your social object? Make sure there is a “there” there. Give users a reason to rally. Why would someone come to your site?
  2. Give people a way to identify themselves and to be identified.
  3. Give people something to do
  4. Enable a bridge to real life (groups, mobile, meetings, face-to-face)
  5. Gently Moderate. Let the community elevate people and content they value.

Erin Malone: 5 Steps to Building Social Experiences

The pain of pagination

January 23, 2010

It’s always worth re-visiting ‘best practices’ that are for the most part never being really questioned. Pagination is a good example. While discussing pagination with developers, I got the impression that it is (or it used to be) a best practice for technical reasonsmore than it is based on actual user insight. There are some obvious (technical) benefits of returning database query results in chunks: it allows quick page load, saves bandwidth, server resources, and energy. It allows designers to apply efficient page grids and to send relevant information into the footer. Oh, and it adds some page-impressions to your SEO statistics.

But what about the user? From what I see and hear in usability test session, users don’t like it and don’t really use it. Although modeled on the simple and very familiar pattern of turning book pages (well, may be not that familiar anymore?), pagination works well only for users who are willing to make an effort. Page-turning on the Web is a complex operation involving a series of cognitive and physical steps: understanding the idea of pagination, allocating the pagination bar, understanding the next step required (where am I and where do I want to go), locating and hitting a (more often than not) tiny link.

Most users seem to be satisfied with a limited number of results anyway. This is certainly true for Google-like search results or for all other ‘transient data’ (Scott 2009, p. 155), where data further down the line become less relevant for the user. But what, for example, if you want to check this season’s trendiest trainers that happen to be a list of 123 items in no particular order – and you don’t want to miss any of them? Comparing items across different pages is painful and ineffective. The product pages of the Adidas online shop employ an alternative to pagination that addresses user needs without straining server resources. Content is incrementally loaded on demand, i.e. when the user scrolls through the page. With a bit of buffer, this works very well. Incremental page load (or yahoo-style crolling) requires new thinking around page-layout and meaningful tools, but for many use cases it promises the end of clumsy page poking and the pain of pagination.

Other examples:
Globrix property search
Artists page of Bandcamp (combining incremental page load with pagination)

Database report standards

January 22, 2010
  • Don’t underestimate workload for planning, designing, and developing reports. Check carefully number, complexity, and required format of reports. Consider external business intelligence tools to do the job.
  • Don’t leave report development for the end of the project; utilise given report requirements to sanity-check the technical architecture of the project
  • Check and discuss required format (online, CSV, PDF) for the different reports. Do not forget necessary design work for PDF reports.

    Components of a report:

  1. Title (distinct name of the report)
  2. Report date (when report was generated)
  3. Cut off date OR report period (does the report refer to figures at a given moment in time or over a period of time?)
  4. Any other filter applied to the data set
  5. Columns including raw and calculated data fields? Tinker with row lay out to reflect given hierarchy in data set.
  6. Subtotal figures
  7. Total figures
  8. Concluding statements

User experience mindset (PACE)

January 11, 2010

“The user experience mindset is an acquired condition for which there is no cure.”

Jesse James Garrett talks about new challenges for User experience professionals who increasingly will need to pursue an integrated approach to UX (multi-channel experience including products, services, environment and more).

The actual challenge is to design independently from a specific medium. Or as JJG puts it:

“Experience design is the design of anything, independent of medium or across media, with human experience as an explicit outcome and human engagement as an explicit goal.”

    The four domains of user experience design (the PACE model):

  1. Perception: engaging the senses
  2. Action: engaging the body
  3. Cognition: engaging the mind
  4. Emotion: engaging the heart

Jesse James Garrett’s talk on UX Week 2009 Video

User Interface Flow Models

January 5, 2010

Another common diagram to create is a user interface (UI) navigation or UI-flow diagram (…) to explore how you will architect the UI of your system by exploring the flow between major UI elements, including both screens/pages and reports. This is critical to your system’s success because the user interface is the system to your stakeholders. Not the technology. Not the data. Not really cool frameworks that you’re working with. If you do not architect the user interface effectively you run the risk that you will build a system that your stakeholders aren’t interested in working with. See example from the book ‘Maturing usability

Scott W Ambler

Agile requirements gathering

January 5, 2010

The fundamental idea is that you do just barely enough modeling at the beginning of the project to understand the requirements for your system at a high level, then you gather the details as you need to on a just-in-time (JIT) basis. (…) The goal is to understand the requirements at a high-level, it isn’t to create a detailed requirements specification early in the lifecycle, a traditional practice referred to as “Big Requirements Up Front” (BRUF) which proves to be very risky in practice. Traditional theory is that BRUF is a best practice, but experience shows otherwise. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the requirements change anyway, and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant). Agilists know that any investment in detailed documentation early in the project will be wasted when the requirements inevitably change.

Scott W. Ambler

http://www.agilemodeling.com/essays/agileRequirements.htm
http://www.agilemodeling.com/essays/initialRequirementsModeling.htm#UsageModel
http://www.agilemodeling.com/essays/initialArchitectureModeling.htm

Agile: 3 thoughts

January 5, 2010
  1. Don’t agree on a fixed price for agile pojects.
  2. The client needs to understand and agree to employ agile methods. Introducing Agile through the back door will cause lots of trouble (“We said right from the start: we wanted this (…) feature”) and extra cost.
  3. The whole production team will need to think and work agile.