Future HomeworkTo be reviewed:To reviewIn real lifeUser Interface DesignSlide 6Design alternativesSlide 8PrincipleBook ReviewSlide 11Golden RulesPlace the User in ControlBad WizardsObtrusive AssistanceNonobvious choicesReduce Memory LoadCommon techniquesBe ConsistentSlide 20The UI Design ProcessModelsSlide 23Early phasesLater phasesTask Analysis and ModelingTasks and Use CasesTasksLow-level designSlide 30Slide 31CS427 21-1Future HomeworkReview work of another projectPair with someone on your projectSwap reviews with a pair from a different project (TAs will assign)Meet once to review their workMeet once to review your own workCS427 21-2To be reviewed:Select work to be reviewedShould take two hour meeting to go over itGive it to other pair to read in advanceOne of you moderates the meeting, the other recordsNot how it should be doneWe do it this way to minimize workProduce a report of all the issues that were raisedCS427 21-3To reviewMake a check list of things to look forRead the work, make commentsEvaluate according to check listMeet. Go over items you have found.How should the check list be improved?CS427 21-4In real lifeUsually there are several meetings until all issues are resolvedProject has a policy that determines what would be reviewed“Passing review” is a measure of progressReviews improve checklists, not just the product under reviewCS427 21-5User Interface DesignImportantHardIsn’t covered well by most software development processesCS427 21-6User Interface DesignAfter data modeling?Yes, for information systems.No, for video games.By a specialist?Yes, for mass-market software.No, for in-house IS systems.CS427 21-7Design alternativesNovice usersMenusMake it look like something elseSimpleExpert usersCommands Specialize to make users efficientPowerfulCS427 21-8Design alternativesStandard IO vs. new IOExisting metaphors vs. new metaphorsNarrow market vs. broad marketCS427 21-9PrincipleUI design is more like film-making than bridge-buildingAbout communicationRequires understanding audienceRequires specialized skillsRequires iterationCS427 21-10Book ReviewLearned HelplessnessA user interface is well-designed when the program behaves …Program model vs. User ModelUser model is simpleEvery time you provide an option, you are asking the user to make a decisionCS427 21-11PrincipleUI design is more like film-making than bridge-buildingAbout communicationRequires understanding audienceRequires specialized skillsRequires iterationCS427 21-12Golden RulesPlace the user in controlReduce the user’s memory loadBe consistentCS427 21-13Place the User in ControlNo modesUse a new window instead of a new modeMake modes visibleUndoMacrosHide technical detailsDirect manipulationCS427 21-14Bad WizardsCS427 21-15Obtrusive AssistanceCS427 21-16Nonobvious choicesCS427 21-17Reduce Memory LoadReduce demand on short-term memoryEstablish meaningful defaultsDefine intuitive shortcutsDisclose information progressivelyUse real-world metaphorsSpeak user’s languageLet user recognize, not rememberCS427 21-18Common techniquesMenus with keyboard shortcutsDialog boxesTabsToolbarCS427 21-19Be ConsistentUse visual interface standardsfor operating systemfor organizationfor product or set of productsShow context - keep user from getting lostSystem should explain itselfCS427 21-20CS427 21-21The UI Design ProcessImplementationUser, task, andenvironmentanalysisInterface validationInterface designCS427 21-22ModelsDesign model - what the designer thinks about the systemUser model - what the user thinks about the systemSystem image - interface, manuals, training material, web siteCS427 21-23Pressman says:“The role of interface designer is to reconcile these differences and derive a consistent representation of the interface”CS427 21-24Early phasesWhat are users like?What do they think the system should be like?What is a single, consistent, model of the system that can satisfy all the users?CS427 21-25Later phasesDesignWhat should system be like?How can we make the users understand it?For each aspect of the system, design the system image to match the desired user modelValidationDoes user model match our goal?CS427 21-26Task Analysis and ModelingWhat tasks will a user of the system perform?High level - why people use the systemLow level - tasks involved in using the systemCS427 21-27Tasks and Use CasesUse cases are high-level tasksDecompose high-level ones into low-level onesFind ones that are missingSimplify by generalizingUI design requires more detail than use case analysis usually providesCS427 21-28TasksFor each task:Is it easy to start the task?Is all the needed information easily accessible?Is it easy to see what to do next?CS427 21-29Low-level designMap task into actions that can be directly implemented by standard widgets.Use consistent labels across tasks.Use consistent widgets across tasks.CS427 21-30User Interface DesignUI communicates with the userLike any form of communication, needs feedback and iterationthere are standard ways of making a UIgreat UIs are rare and require creativityCS427 21-31Read next three “chapters” of the “book” on UI design for programmers at http://www.joelonsoftware.com/uibook/
View Full Document