Structure and Function: IA for Web Applications

1
Structure and FunctionIA for Web Applications
2
Structure - IA with content

• In a content-only site, the user interface is
  easy,
• the information architecture is hard
• Lots of things
• topics with different sub-structures
• grows, hard to know how its going to expand
• but its understood

3
Function - UI for applications

• For desktop applications, the information
  architecture is easy
• the user interface is hard
• lots of different actions a user can take
• they interfere with each other
• effect of actions needs to be clear to the user
• but its understood

4
How is UI different on the web?

• Supports more tasks at once
• lots of domain-specific tools, not one general
  purpose tool
• Supports different tasks
• shopping, communication, decision-making
• Combines traditional tasks with more things

5
Typical Web applications

• Shopping, for simple and complex products
• Decision-making
• Auctions and marketplaces
• Verticals - applications embedded in portals
• Process tracking, workflow, negotiations
• Status tracking

6
Structure of this talk

• Team structure for these projects
• How users and their intentions are different
• Common IA challenges in a Web application
• Object structure
• Navigation
• Other
• Basic Advice

7
Teams and Collaboration
8
User Interface Designers

• Design the task flow, and thus the page flow
• Design page-level interaction
• Bring a lot of knowledge about human-computer
  interaction
• Collaborate on
• information display
• page layout
• navigation

9
Are you being a UI Designer?

• Are you
• choosing where to put info and buttons on a page
• deciding when to show users info and when not
• designing task flow
• If so, learn the user interface domain as well

10
Building a team

• Typical design team
• UI Designer, Information Architect, Visual
  Designer
• Useful people
• Ethnographer, technical writer, usability tester
• Be flexible in ownership of tasks
• Be collaborative in the design process
• Be clear about inputs and outputs

11
Different Audiences, Different Goals
12
Who are the users?

• People at work
• Trying to make money
• Trying to save money
• Users often arent the people who buy the system
• People at home doing something important

13
Same questions, different answers

• Frequency of use
• all day, every day
• Level of domain expertise
• often deep
• Language
• jargon is extensive and important
• How optional is it, what happens if it fails
• not very - either its important or they are
  forced

14
Common Challenges
15
Information limits task

• Structure of things and their attributes sets
  what is possible
• IA needs to see how the info interacts, flexes
• Know what users should change, when, why
• Guess what tasks the information allows that
  havent been thought of
• Overlaps with a DBA role

16
Information limits task
If the user cant enter it here, it cant be
chosen, searched on
17
Information affects understanding

• The users mental model is made of things, their
  attributes, and what can be done to them
• Make relationships between attributes sensible,
  obvious
• Know what attributes will be compared in
  trade-off decisions
• Have the UI surface interaction between
  attributes, the effects of actions

18
Information affects understanding
19
Keeping users in a task

• Ubiquitous navigation increases the chance for
  mistaken moves
• Collapse general navigation
• use sequence nav
• Avoid related links on the pages for a task
• Use pop-ups for honest side tasks
• Try to make tasks short
• On a web app, users WANT to stay on task

20
Keeping users in a task
sequence navigation with collapsed global nav-
MetaDesign
21
Navigating between tasks

• Some tasks need instant access at all times
• need to understand the users day and mix of
  responsibilities
• Some tasks are related and grouped
• need to know the users more general intention to
  decide connections between tasks
• Tasks are less likely to expand than lists of
  things
• horizontal navigation often works

22
Navigating between tasks
Switch active orders and adding new ones, rarely
email
Switch between sourcing, buying, and looking for
partners
23
Flexible navigation

• Different situations demand different navigation
• Looking for a task vs. completing a task
• finding a thing vs. finding a task
• different users, with different roles and
  permissions
• Some of this is in the global nav, some is an
  issue of links that appear or dont appear

24
Flexible navigation
Buyer has a different navigation than the agent
25
Navigating tasks and sub-tasks

• Use pop-ups judiciously
• If the sub-tasks are optional, highlight the
  typical next step
• Design a good multi-level sequence navigation
• This is tied to the UI area of task flow, but
  determines pages and structure

26
Navigating tasks and sub-tasks
Effective use of pop-ups helps support
sub-tasks -MetaDesign
27
Look for a thing, then choose a task

• The e-tail model, but often have more tasks
• Have the right tasks available at the right level
  in the object hierarchy
• What can I do to a class of objects?
• What can I do to one object?
• At what point do you have matrix navigation

28
Look for a thing, then choose a task
List of things with actions attached
29
Maintaining tasks over time

• Many tasks extend over days and weeks
• Have workbench for users tasks, what they are
  responsible for
• Display status and provide access, due dates
• Notification of events, with email or on that
  workbench

30
Maintaining tasks over time
Workbenches monitor and provides access
31
Searching an application

• Users are looking for how to do a task, not for a
  piece of info
• Many pages should not be searched at all
• Heavy use of meta-tags rather than full text
  search
• Search is often part of a task, not just
  navigation

32
Basic Advice
33
Task-focused research

• Cant rely on card-sorts
• Listening in context is often the only way to
  find jargon
• Different groups of users are different
• Collision repair shops differ in how they order
  parts, who does it, what they call the tasks

34
Wallow in the information

• Things, attributes, and relationships have a huge
  impact
• Things define tasks
• Tasks determine things

35
Start IA and UI at the same time

• UI (page flow) controls IA below the top level
• Both need to learn the same stuff, work on the
  same design problems
• Knowing the things requires knowing the tasks

36
Is this information architecture?