1 / 35

Interface Design

Interface Design. C reating systems that are used! Robert Barnes, PMP robert.barnes@xtra.co.nz Management & IT Consultant, The iE3 Group . Programming Good Practice, 20 June 2002. www.robertb.co.nz/sdlcpresentations. Contents. Why bother? Where to Start? Introduction to UI Rules

uzuri
Télécharger la présentation

Interface Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interface Design Creating systems that are used! Robert Barnes, PMP robert.barnes@xtra.co.nzManagement & IT Consultant, The iE3 Group. Programming Good Practice, 20 June 2002 www.robertb.co.nz/sdlcpresentations R Barnes, 6/2002

  2. Contents • Why bother? • Where to Start? • Introduction to UI Rules • User-Centred Interface Design • Help R Barnes, 6/2002

  3. Good software is • Defect Free • Reliable • Useable • Cost Effective • Maintainable • Watts S. Humphrey, Which is the most important? R Barnes, 6/2002

  4. The most important thing - That there are users who want it • If there’s nobody who wants it, why do it? • To want it, a user must believe that they will get some benefit from it • If users don’t know how to use it (whatever “it” is), they won’t appreciate its benefits • PERCEIVED value is the ONLY reality R Barnes, 6/2002

  5. Misunderstood systems are expensive!! • Lost productivity • Lost Opportunities • Mistake fixing • Training of new staff • Lost sales (Software house) R Barnes, 6/2002

  6. Comprehension is fundamentalto Value Perception How easily can I [understand how to] use it? • Dialogs - user interface, workflow • Documentation - Help and/or Manuals • Training The aim: Systems that users intuitively understand Importance More Less R Barnes, 6/2002

  7. The Challenge R Barnes, 6/2002

  8. Where to Start • Systems Development Procedures • Role of spec., prototype, HELP, in project methodology • Standards • Tools R Barnes, 6/2002

  9. Iterative Development • Involve user early • If no identified user, create a “typical user” Design Proto- Type, V1, V2, … Test R Barnes, 6/2002

  10. User Interface -The Key to Understanding and Appreciation! • Key rule - Must be Intuitive • Icons obvious (Use MS-Standard ones where appropriate) • Dialog Structure logical, easy to navigate • MS Standards where appropriate • Behaviour regular (NO SURPRISES, Idiot proof) • Standard use of keys, Drag&drop, Click, etc. • HELP everywhere!!!!!!!!! R Barnes, 6/2002

  11. User Interface (2) • Key Rule 2 - Must be Useful & Convenient • Fast • Menus/Icons match workflow/functional division • FLEXIBLE WORKFLOWS!!!!! • KEEP IT SIMPLE (Stupid) • Clutter • Attention Spans and Layout • The “7 +/-2” rule R Barnes, 6/2002

  12. Millibulls Bogumeter User Interface (3) • Use of latest technology? • Sizzle or Steak? (Promise or Performance) • Feature Overload R Barnes, 6/2002

  13. User-Centered Design Principles • User in Control • Directness • Consistency • Feedback • Aesthetics • Simplicity Demo (The Windows Interface Guidelines for Software Design -Microsoft Press, 1995) R Barnes, 6/2002

  14. User Control • User should feel in control of the software, not feel controlled by it • User initiates actions • Don’t overuse modal windows • Users should be able to personalise the system to match their skills & experience • Software should be as interactive and responsive as possible R Barnes, 6/2002

  15. Directness • Users should manipulate direct representations of information • Effect of this manipulation on the screen objects should be obvious • Familiar metaphors - provide a cognitive bridge R Barnes, 6/2002

  16. Consistency • Within Product • eg, don’t do this:- xxx command • Does something immediately in one situation • Displays a dialog box in another • With Operating Environment • With metaphor R Barnes, 6/2002

  17. Forgiveness • Provide only appropriate choices • Warn about possible errors • Make actions recoverable or reversible • Avoid “Little Lucifer” messages R Barnes, 6/2002

  18. Feedback • NEVER leave the user in doubt • When does database change? Commit/Rollback • No unexpected (hidden) consequences • Use appropriate messages • Avoid dead screens • typical user will tolerate only a few seconds of an unresponsive interface R Barnes, 6/2002

  19. Aesthetics Visual attributes provide valuable impressions and communicate important cues to the interaction behaviour of objects. At the same time, remember that every visual element competes for the user’s attention R Barnes, 6/2002

  20. Simplicity • Avoid Clutter • 7 +/- 2 rule. Grouping • Natural tab order • Keyboard equivalent • Behaviour of <tab> and <enter> • Should be able to accomplish common action without mouse (unless highly graphical – eg Photoshop) • Messages - avoid jargon, should say what user is to do, give options if possible. R Barnes, 6/2002

  21. Help and Manuals We have the wrong attitude to Help • End-of-project task (waste of effort until design detail finalised) • Not “real task” of developers – needs different skills/people • Too much work • Will create a maintenance nightmare • It costs too much Each of these is wrong! R Barnes, 6/2002

  22. Fallacy 1 - Help is done Last • Traditional attitude - leave to last • Don’t know the detail until then - avoid waste • Can be a slippable/elastic activity • “delivered except for Help” - so OK • How much Help is enough – can’t satisfy 100%, so not worth trying • Haven’t got enough budget/customer won’t fund • Alternative - the Help/Manual is the design/ specification • Written up as details worked out • May be the Customer Specification for proposal/contract • Basis for “RB* Testing” * Right Bastard R Barnes, 6/2002

  23. The Process Concept Next-release Development Updated Users’ Guide Updated Users’ Guide Story/ Job Spec. Acceptance Testing Release R Barnes, 6/2002

  24. The Process – V2 Concept Next-release Development Updated Users’ Guide Updated Users’ Guide Story/ Job Spec. Acceptance Testing Release R Barnes, 6/2002

  25. Keys to Quality Software Concurrent Help/Code development facilitates these. Standish study – these are the major issues in project success/failure Include – • User Involvement • Multiple Perspectives • Shared Vision • Quality Methodologies • Reviews etc • Tools – “Correct by construction” • Quality mindset http://standishgroup.com/visitor/chaos.htm http://standishgroup.com/visitor/voyages.htmc R Barnes, 6/2002

  26. Fallacy 2 - Real Programmers write Code(Manuals are for sissies) • Widespread belief: Different skills required to write clearly, or to code programs. • But structuring skills are the same for documentation as code • “Manual” writing requires a customer focus • If the Analyst, or A/P, can’t do this, then they should work under a technical writer! • Communication is the ONLY part of the job which can’t be shipped off to India! R Barnes, 6/2002

  27. What is Business Writing? “Business Writing is a form of Communication that presents information in the most satisfactory way for the user to find and understand it”. • Shouldn’t developers be focussed on clear communication with the user? • Would you hire a programmer who couldn’t communicate clearly? R Barnes, 6/2002

  28. Profile of a Business Writer • Some of the skills required: • Good communicator • Excellent writing skills • Empathy • Logical and analytical thinker • Feeling for language • Patience • Persistence (Steve Moss, Techwrite Services) • Which of these can a developer do without? R Barnes, 6/2002

  29. Fallacy 3 - it’s too much work • Commonly perceived as • A lot of initial work • An ongoing maintenance nightmare. BUT • Integrate into development cycle - reduces effort • Specification <-> User Manual <-> Help <-> Tutorial • Work that needs to be done anyway • I have an aversion to doing things twice! R Barnes, 6/2002

  30. Fallacy 4 - it costs too much. • Later Change is MUCH more expensive Early Help is part of “Find mistakes early” R Barnes, 6/2002

  31. Use of Help is Grossly Underrated • Help-equipped prototype iteration • Most effective method BY FAR of • Getting system right • Creating User Commitment and Enthusiasm • A Help-equipped rudimentary prototype should be the first deliverable! • Sometimes the system is ONLY help • Procedure “manuals” etc. • BPR documentation R Barnes, 6/2002

  32. Tools • Help creation:- • RoboHelp ($US495) • http://www.blue-sky.com/products/infowho.htm • Doc-to-Help ($US495) • http://www.wextech.com • Helpbreeze: ($349) • http://www.solutionsoft.com/hlpbrz_av.shtml • Forehelp • http://www.ff.com • Visual Help (Pro - $US189, Personal $49) • http://www.winwareinc.com R Barnes, 6/2002

  33. “PseudoHelp” Use WordView97 with Word Document • This is a free download from Microsoft It’s almost as good as real help, but much easier to prepare and maintain Example VBA code from Help button’s Click event ‘ Display Userguide with Wordview from same directory as .MDB Dim UserGuide As String UserGuide = """" & Access.CurrentProject.Path & "\Userguide.doc""" Call Shell("C:\Program Files\WordView\Wordview.exe " & UserGuide, vbNormalFocus) See next slide for results R Barnes, 6/2002

  34. PseudoHelp (2) R Barnes, 6/2002

  35. Review • Involve users in an iterative development process • User understanding is more important than anything else • Design should be User-centred • HELP is NOT an extra R Barnes, 6/2002

More Related