CS427: Software Engineering ITopicsHomework 4To be reviewedTo reviewIn real lifeUser interface designWhen and who should do?Design alternativesSlide 10PrincipleBook reviewSlide 13Golden rulesPlace the user in controlBad wizardsObtrusive assistanceNon-obvious choicesReduce memory loadCommon techniquesBe consistentSelection using scroll barThe UI design processModelsReconciling modelsEarly phasesLater phasesTask analysis and modelingTasks and use casesTasksLow-level designSlide 32Next: More UI design1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 21-2TopicsCovered since midtermSpecificationDesignQuality assuranceNextUser interface designTwo more processes (besides XP and RUP)SummaryCS427 21-3Homework 4Review work of another projectPair with someone on your projectSwap reviews with a pair from a different project (TAs assigned, see Wiki)Meet once to review their workMeet once to review your own workCS427 21-4Select 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 raisedTo be reviewedCS427 21-5To reviewMake a check list of things to look forRead the work, make commentsEvaluate according to check listMeet and go over items you have foundHow should the check list be improved?CS427 21-6In 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-7User interface designImportantHardIsn’t covered well by most software development processesCS427 21-8When and who should do?After data modeling?Yes, for information systemsNo, for video gamesBy a specialist?Yes, for mass-market softwareNo, for in-house IS systemsCS427 21-9Design alternativesNovice usersMenusMake it look like something elseSimpleExpert usersCommands Specialize to make users efficientPowerfulCS427 21-10Design alternativesStandard IO vs. new IOExisting metaphors vs. new metaphorsNarrow market vs. broad marketCS427 21-11PrincipleUI design is more like film-making than bridge-buildingAbout communicationRequires understanding audienceRequires specialized skillsRequires iterationCS427 21-12Book reviewJoel Spolsky on UI Design for ProgrammersThree chapters per lectureLearned 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-13PrincipleUI design is more like film-making than bridge-buildingAbout communicationRequires understanding audienceRequires specialized skillsRequires iterationCS427 21-14Golden rulesPlace the user in controlReduce the user’s memory loadBe consistentCS427 21-15Place the user in controlNo modes (vim?)Use a new window instead of a new modeMake modes visibleUndoMacrosHide technical detailsDirect manipulationCS427 21-16Bad wizardsCS427 21-17Obtrusive assistanceCS427 21-18Non-obvious choicesCS427 21-19Reduce memory loadReduce demand on short-term memoryEstablish meaningful defaultsDefine intuitive shortcutsDisclose information progressivelyUse real-world metaphorsSpeak user’s languageLet user recognize, not rememberCS427 21-20Common techniquesMenus with keyboard shortcutsDialog boxesTabsToolbarCS427 21-21Be consistentUse visual interface standardsFor operating systemFor organizationFor product or set of productsShow context - keep user from getting lostSystem should explain itselfCS427 21-22Selection using scroll barCS427 21-23The UI design processImplementationUser, task, andenvironmentanalysisInterface validationInterface designCS427 21-24ModelsDesign model - what the designer thinks about the systemUser model - what the user thinks about the systemSystem image - interface, manuals, training material, web siteCS427 21-25Reconciling modelsPressman says:“The role of interface designer is to reconcile these differences and derive a consistent representation of the interface”CS427 21-26Early 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-27Later 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-28Task 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-29Tasks 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-30TasksFor 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-31Low-level designMap task into actions that can be directly implemented by standard widgetsUse consistent labels across tasksUse consistent widgets across tasksCS427 21-32User 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-33Next: More UI designRead chapters 4-6 of the book on UI design for programmers
View Full Document