Slideshare.net (beta)

 
Post to TwitterPost to Twitter
Post: 
Myspace Hi5 Friendster Xanga LiveJournal Facebook Blogger Tagged Typepad Freewebs BlackPlanet gigya icons

All comments

Add a comment on Slide 1

If you have a SlideShare account, login to comment; else you can comment as a guest


Showing 1-50 of 18 (more)

Michael Kowalski

From carsonified, 11 months ago

Michael Kowalski's presentation from Future of Web Apps, in London more

3862 views  |  2 comments  |  18 favorites  |  168 downloads
 

Categories

Add Category
 
 

Groups / Events

 

 
Embed
options

More Info

This slideshow is Public
Total Views: 3862
on Slideshare: 3862
from embeds: 0

Slideshow transcript

Slide 1: User interface design for web applications Michael Kowalski Kitsite.com

Slide 3: What we’re going to cover • What is the difference between designing a webapp and designing a website? • Why is good user interface design important? • What are the characteristics of a great user interface? • What can we learn from interaction design? • What are some specific techniques that I can use to improve my webapp UI? • Where is web UI design heading?

Slide 4: Q. How is designing a web application different from designing a website?

Slide 6: Information

Slide 7: Information

Slide 8: Information Interaction

Slide 9: Web user interface HTML form controls are the primitives of an application user interface

Slide 10: Hey, let’s build the webapp right here! • Democratisation of user interface development • Low cost, rapid development • The web is an open distribution channel • Anybody can build a web app!

Slide 14: Alan Cooper

Slide 15: “The limitations and challenges of web interactivity... set interaction design back several years” Alan Cooper

Slide 16: Web constraints

Slide 17: Web constraints annoyances

Slide 18: Living on the network

Slide 19: Living on the network • Connectivity

Slide 20: Living on the network • Connectivity • Network latency

Slide 21: Living on the network • Connectivity • Network latency • Source code down the wire

Slide 22: Living in the browser x

Slide 23: Living in the browser x • Security sandbox • Box-model rendering • Limited widget set No access to system menus No rich text editing No drawing • Typographically limited

Slide 24: My pet hates • <select multiple>! • Backspace key for navigation! • Form controls are modal! • CSS...

Slide 25: But if web UI sucks so badly...

Slide 26: But if web UI sucks so badly... how come the web is winning?

Slide 27: Why web apps became viable • Cross-platform consistency driven by standards • Asynchrony • Faster networks and computers • “Worse is better”

Slide 28: Innovation from the web Hyperlinks Folksonomy navigation Findability addressability bookmarks Embedding Social apps portlets sharing widgets collaboration

Slide 29: Q. Why is good user interface design important?

Slide 31: • The rise of utility computing (S3, etc) and the adoption of good web frameworks has reduced web development costs.

Slide 32: • The rise of utility computing (S3, etc) and the adoption of good web frameworks has reduced web development costs. • It’s never been cheaper or easier to get an idea to market.

Slide 33: • The rise of utility computing (S3, etc) and the adoption of good web frameworks has reduced web development costs. • It’s never been cheaper or easier to get an idea to market. • In a more competitive market, emphasis will shift from executing first to executing best.

Slide 34: • The rise of utility computing (S3, etc) and the adoption of good web frameworks has reduced web development costs. • It’s never been cheaper or easier to get an idea to market. • In a more competitive market, emphasis will shift from executing first to executing best. • The quality of user experience is becoming the significant differentiator.

Slide 35: • The rise of utility computing (S3, etc) and the adoption of good web frameworks has reduced web development costs. • It’s never been cheaper or easier to get an idea to market. • In a more competitive market, emphasis will shift from executing first to executing best. • The quality of user experience is becoming the significant differentiator. • Also, scaling your app depends on not having to handle support requests (or at least, not linearly).

Slide 36: Let’s not reinvent wheels We can take advantage of many years of research in interaction design. Plus we can look at best practice on the web today.

Slide 37: Q. What are the characteristics of a good user interface?

Slide 38: simple

Slide 39: consistent simple

Slide 40: consistent simple polite

Slide 41: consistent simple polite responsive

Slide 42: consistent simple polite responsive pragmatic

Slide 43: consistent simple polite responsive aesthetically pragmatic pleasing

Slide 45: Interaction design concepts

Slide 46: Concept 1 The user

Slide 47: You are not the user!

Slide 48: Real world process or object

Slide 49: The implementation model

Slide 50: The user model

Slide 51: The user model

Slide 52: The user model Mismatch between the user model and the implementation model is a source of usability problems

Slide 53: Users have different levels of expertise Novice Intermediate Expert

Slide 54: Users have different levels of expertise Novice Intermediate Expert

Slide 55: Users have different levels of expertise Novice Intermediate Expert

Slide 56: The rule of 7

Slide 57: The rule of 7 • Short term memory holds around 7 distinct things • Fades in 10 - 20 seconds

Slide 58: Spolsky’s 3 laws of users People can’t control the mouse

Slide 59: Spolsky’s 3 laws of users People can’t read People can’t control the mouse People can’t remember

Slide 60: A polite interface assumes the user is busy and has more important things to do than think about how the app works.

Slide 61: A polite interface assumes the user is busy and has more important things to do than think about how the app works. • Talks the user’s language • Designed around the user’s conceptual model • Focused on achieving user goals • Is tolerant and forgiving

Slide 62: Concept 2 Metaphor

Slide 63: Metaphor A shopping basket • Add to the basket • View the basket • Go to the check out

Slide 64: Metaphor can be a useful way of gluing together the user model and the implementation model • Metaphor gives developers a language to discuss the model • Warning: metaphors can get you in trouble if you follow them too literally

Slide 65: False metaphor

Slide 66: Concept 3 Aordance

Slide 67: Affordance is... “the perceived and actual properties of the thing... that determine just how the thing could possibly be used” Don Norman, The Design of Everyday Things

Slide 68: A tale of two buttons Save Save

Slide 69: A tale of two buttons Save Save

Slide 70: A tale of two buttons Save Save

Slide 71: A tale of two buttons Save Save

Slide 72: A tale of two buttons Save Save

Slide 73: A tale of two buttons Save Save

Slide 74: A tale of two buttons Save Save

Slide 75: A tale of two buttons Save Save

Slide 76: The #1 affordance on the web Home | Help | Your profile

Slide 77: The #1 affordance on the web Home | Help | Your profile • This is a learned affordance

Slide 78: New affordances evolve

Slide 79: Fitt’s Law T = a + b log2(D +1) W where T is the average time taken to complete the movement. a and b are empirical constants, and can be determined by fitting a straight line to measured data. D is the distance from the starting point to the centre of the target.

Slide 80: Fitt’s Law T = a + b log2(D +1) W

Slide 81: Fitt’s Law T = a + b log2(D +1) W Targets that are smaller and/or further away require more time to acquire.

Slide 82: Bigger targets are better Browse Search

Slide 83: Bigger targets are better Browse Search

Slide 84: Bigger targets are better Browse Search

Slide 85: Bigger targets are better Browse Search

Slide 86: Affordance techniques • Bevelled edges and gradients on buttons • Texture, eg. grippy corners on draggables • <label for> • Tooltips (via title attribute on <a> tags) • Cursor hinting

Slide 88: Concept 4 Excise

Slide 89: Excise is noise in the interface • A “cognitive tax” on the user • Effort that is not directed towards the users’ goals • Frequently exposes the underlying implementation model • Satisfies the needs of the technology rather than the user • Visual clutter is excise • Customisation is usually excise

Slide 91: Too much affordance is excise Therefore: • Trade off affordance against excise to prioritise more frequent tasks • Provide extra affordance transiently, eg. on mouseover • Reduce the affordance on less commonly used controls

Slide 92: Using links for commands Save Cancel • In a form, hyperlinks have less affordance than buttons, so can be used to reduce excise. • Use a different colour to distinguish command links from navigational links.

Slide 93: Progressive disclosure Use progressive disclosure to reduce excise Show more

Slide 94: Progressive disclosure Use progressive disclosure to reduce excise Show more less • Disclosure arrows • Hyperlinks to popups or overlays • Dropdowns In a goal-oriented design, not every function has to be accessible from every screen.

Slide 96: Concept 5 Modes

Slide 97: Modes The same gesture has different meanings depending on what mode the application is in

Slide 98: Modes Approve Reject That’s the stupidest thing I ever heard! I agree with every word of your brill... Buy Vi@gra from us!!!

Slide 99: Modes Approve Reject That’s the stupidest thing I ever heard! I agree with every word of your brill... Buy Vi@gra from us!!! Modal Choose the command mode first (eg. “Approve” and then select the item to action.

Slide 100: Modes Approve Reject That’s the stupidest thing I ever heard! I agree with every word of your brill... Buy Vi@gra from us!!! Modeless Make a selection first, and then choose Modal Choose the command mode first (eg. a command to then to that selection. “Approve” and apply select the item to action.

Slide 101: Modes

Slide 102: Modes • With a few exceptions, modes are bad

Slide 103: Modes • With a few exceptions, modes are bad • The exceptions: graphics and other drawing apps

Slide 104: Modes • With a few exceptions, modes are bad • The exceptions: graphics and other drawing apps • Transient modes are less bad

Slide 105: Modes • With a few exceptions, modes are bad • The exceptions: graphics and other drawing apps • Transient modes are less bad • If you are using modes, then the current mode should be visible right where the user is looking (eg. by changing the cursor).

Slide 107: Concept 6 Posture

Slide 108: What is posture? • Defined by Alan Cooper in About Face • Identified 4 different postures for apps • Posture relates to amount of attention that a user will give the application

Slide 109: Sovereign

Slide 110: Transient

Slide 111: Auxiliary

Slide 112: Daemonic

Slide 113: Immersive

Slide 114: Concept 7 Preattention

Slide 115: Preattention variables • Hard-wired rules of human perception • Things we see immediately, without conscious thought

Slide 116: Visual properties Intensity Shape Colour Symmetry Texture Motion

Slide 117: Visual properties Intensity Shape Colour Symmetry Texture Motion

Slide 118: Spot the odd one out

Slide 119: Spot the odd one out

Slide 120: Grouping

Slide 121: Use grouping and visual properties to: • Prioritise what’s important and most useful • Associate related commands or information • Distinguish between controls that behave differently • Establish consistency

Slide 122: Bad Amazon • Buttons are variably sized • Poor alignment and inconsistent guttering • Giftbox icon is excise • Colours used inconsistently

Slide 123: Concept 8 Locus

Slide 126: I’m looking here

Slide 128: I’ll notice this

Slide 130: I probably won’t notice anything here

Slide 131: Concept 9 Feedback

Slide 132: Communication Action Visual cues Feedback time

Slide 133: Communication Action Visual cues Feedback (“feedforward”) time

Slide 134: 0.25 After seconds, the user will assume that it hasn’t worked and try again

Slide 135: Feedback rules

Slide 136: Feedback rules • If an action will take more than 0.1 sec to complete, visually indicate that it has started.

Slide 137: Feedback rules • If an action will take more than 0.1 sec to complete, visually indicate that it has started. • Use spinners or progress bars for actions that 1 second. will take more than

Slide 138: Feedback rules • If an action will take more than 0.1 sec to complete, visually indicate that it has started. • Use spinners or progress bars for actions that 1 second. will take more than • Document load events should not take more 10 seconds. than

Slide 139: Feedback rules • If an action will take more than 0.1 sec to complete, visually indicate that it has started. • Use spinners or progress bars for actions that 1 second. will take more than • Document load events should not take more 10 seconds. than • Acknowledge completion modelessly

Slide 140: Feedback rules • If an action will take more than 0.1 sec to complete, visually indicate that it has started. • Use spinners or progress bars for actions that 1 second. will take more than • Document load events should not take more 10 seconds. than • Acknowledge completion modelessly • If completion will take longer than a few seconds, the new status should be displayed non-transiently

Slide 141: Now Current state • What’s happening now? • Am I logged in? • Are my friends logged in? • Is there new activity I should know about?

Slide 142: Next Visual cues • What’s going to happen next? • What will happen if I click this?

Slide 143: Concept 10 Icons

Slide 144: Icons Icons can be useful because: • Don’t take up much screen real state • Take advantage of human spatial recall • They have become a familiar idiom • Can add colour and visual interest

Slide 145: The trouble with icons

Slide 146: The trouble with icons • In a modeless interface, most command affordances will be verbs.

Slide 147: The trouble with icons • In a modeless interface, most command affordances will be verbs. • Verbs are hard to draw.

Slide 148: The trouble with icons • In a modeless interface, most command affordances will be verbs. • Verbs are hard to draw. • Most icons are therefore hard to interpret without a label.

Slide 149: The trouble with icons • In a modeless interface, most command affordances will be verbs. • Verbs are hard to draw. • Most icons are therefore hard to interpret without a label. • Icons work best in sovereign posture applications where space is at premium and users have the time to learn the icons.

Slide 150: Rules for using icons • Use icons sparingly. • Use icons that convention has made familiar (eg. document icons) • Label your icons, using the app vocabulary. Avoid puns! • Don’t forget your app’s colour scheme and lighting angle.You may need a larger palette of colours for hinting - but still keep it constrained. • Get professionals to design them!

Slide 152: Concept 11 Learnability

Slide 154: Learnability is... • what we usually mean when we say “intuitive.” • Because most web apps have a transient posture, this is particularly important - your app has to be relearnable as well as learnable. • Warning Too much guidance can be excise

Slide 155: Concept 12 irectD manipulation

Slide 156: Direct manipulation

Slide 157: Direct manipulation • The user acts directly on a visual representation of an object, and immediately sees the result.

Slide 158: Direct manipulation • The user acts directly on a visual representation of an object, and immediately sees the result. • Examples: • Drag and drop • Drag resize • Drawing tools

Slide 159: Direct manipulation • The user acts directly on a visual representation of an object, and immediately sees the result. • Examples: • Drag and drop • Drag resize • Drawing tools • Downside: generally poor affordance

Slide 160: Evaluating web app UI Divide up into groups of about 4 Pick a web app Evaluate aordance, excise and feedback Look for good and bad points Suggest at least one improvement 15 minutes

Slide 161: <br/>

Slide 162: Techniques

Slide 163: Technique 1 UI first

Slide 164: Design the user experience first

Slide 165: Design the user experience first • Before user research?

Slide 166: Design the user experience first • Before user research? • Before data modelling?

Slide 167: Design the user experience first • Before user research? • Before data modelling? • Before technology choices?

Slide 168: Design the user experience first • Before user research? • Before data modelling? • Before technology choices? Yes! Avoid getting railroaded by the implementation model

Slide 169: User research • Formal user research can be expensive, tricky and inconclusive • Long-tail users might be hard to come by • Informal research with a handful of users can give useful insights • Beta launching can get early feedback from real users • Apple vs Microsoft

Slide 170: Technique 2 Personas

Slide 171: Sarah Turner Justin Finch “Sooner is better.” “I’m not much of a technology buff, to be Occupation: Head of honest” PR Occupation: Bookseller Wants to get prior approval on new Wants to get info about corporate comms. new releases as painlessly Worries that her staff as possible. Low will not use the new app expectations: thinks the unless it’s really simple. app will be pointlessly Must have controlled complicated. Dislikes hard costs. Sarah can be quite sell from publishers; wants demanding. to make up his own mind.

Slide 172: Sarah Turner Justin Finch “Sooner is better.” “I’m not much of a technology buff, to be Occupation: Head of honest” PR Occupation: Bookseller Wants to get prior approval on new Wants to get info about corporate comms. new releases as painlessly Worries that her staff as possible. Low will not use the new app expectations: thinks the unless it’s really simple. app will be pointlessly Must have controlled complicated. Dislikes hard costs. Sarah can be quite sell from publishers; wants demanding. • Not a market segment to make up his own mind. • A representative individual

Slide 173: Technique 3 Goal-directed design

Slide 174: Goal-directed design Task Task Task Goal Task Task

Slide 175: Goal-directed desig