CS427: Software Engineering IAdministrative InfoTopics on UI designJoel on softwareSlide 5UI designSingle modelE-mailDesign modelEudoraObject-oriented user interfaceRelate UI to designCommand patternCommand for “cut text”Slide 15SummaryDesign choicesBase GUI on system designBase GUI on metaphorBase GUI design on idiomsResponse timesEvaluating UIUI metricsUI evaluationEarly UI evaluationVery early UI evaluationSlide 27Size of evaluationJohnson’s LawSlide 30Next: UI implementation1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 22-2Administrative InfoHW4 postponed, due: Tue, Nov 28You can submit it now if you finishedHW5 due on Dec 5Document architecture; you can start nowFinal project report due on Dec 7On-campus group can choose to meet with me or the TAs (Jeff for RUP projects, Valas for XP)Final exam on Dec 14CS427 22-3Topics on UI designLast time PrinciplesPlace the user in controlReduce the user’s memory loadBe consistentModels: design vs. userTodayObject-oriented UI designEvaluating a UI designNext: UI implementation and testingCS427 22-4Joel on softwareAffordanceMetaphor“In most UI decisions, before you design anything from scratch, you absolutely have to look at what other popular programs are doing and emulate that as closely as possible.”CS427 22-5Joel on software“Users don't have the manual, and if they did, they wouldn't read it.” “In fact, users can't read anything, and if they could, they wouldn't want to.”CS427 22-6UI designUI design communicates to userUser model should match design modelBad design model => bad UI designCS427 22-7Single modelDesigners should have a single, coherent model of the systemImplementation should match that modelThe GUI should communicate that modelThe user model should match the design modelCS427 22-8E-mailTasksRead a messageCheck to see if there is more mailReply to a new messageSend a message to a set of peopleStop half-way through writing a message and wait till tomorrowSave a messageCS427 22-9Design modelMessageMailboxIncoming messages go to in-boxMessages in out-box can be marked “ready to be sent”New messages created in out-boxCan move messages from one mailbox to anotherCS427 22-10EudoraCS427 22-11Object-oriented user interfaceObjects represented by lists, iconsOperations are on menus, buttonsPerform operation on selected objectMake a few operations that work on many kinds of objectsSpecify arguments by:Dialog boxMultiple selectionCS427 22-12Relate UI to designWindow for domain object Commands taken from operations on objectDirect manipulation interfaceWindow for use caseSeveral windows on same domain objectWindow might display state of use caseWindow might display argument (dialog box)Commands are steps in use caseCS427 22-13Command patternRepresent commands by objectsCommand can execute itselfExecuted command knows its resultCommand can undo itselfSystem keeps a list of executed commandsCS427 22-14Command for “cut text”dooldbuffer = editor.getCutbuffer();editor.putCutbuffer(editor.getSelection());editor.putSelection(‘’);undoeditor.putSelection(editor.getCutbuffer());editor.putCutbuffer(oldbuffer);CS427 22-15Command patternSuperclass “Command” with interface“do” and “undo”Subclass for each kind of commandConstructors define arguments of the commandCommand subclass defined enough variables to be able to implement undoOptional reading: “Design Patterns” by Gamma, Helm, Johnson, and VlissidesCS427 22-16SummaryDesign of a UI for OO systemsWindow for every objectWindow for every use caseCommand patternCS427 22-17Design choicesBase GUI on System design (technology)MetaphorIdiomsOptional reading: Alan Cooperhttp://www.cooper.com/articles/art_myth_of_metaphor.htmCS427 22-18Base GUI on system designMakes GUI design easierMakes GUI implementation easierUsers don’t like to see the guts of the systemCS427 22-19Base GUI on metaphorCan make system easier to learnCan limit designGood design has some “magic”May not be a metaphorBad metaphor worse than noneXP says (or used to say!) system design should be based on metaphorCS427 22-20Base GUI design on idiomsPeople learn new techniquesIf a system has only a few well-designed techniques, it will be easy to learnReuse existing idioms, and design new onesCS427 22-21Response timesFrom Usability Engineering by Jakob Nielsen0.1 sec - limit for “instantaneous”1 sec - limit for “doesn’t interrupt flow”Consider progress indicator10 sec - limit for “keeping attention focused on dialog” Consider making it a background taskCS427 22-22Evaluating UIMust evaluate UITo see how to improve itTo see whether it is good enough to be releasedCS427 22-23UI metricsSize of written specificationNumber of user tasksNumber of actions per taskNumber of system statesNumber of help messagesCS427 22-24UI evaluationOnce system has users …SurveysFocus groupsMailing list for supportAnalyze help desk logsCS427 22-25Early UI evaluationHave people use the systemGive them tasksFind out what is wrong with itSurveysDirect observationQualitative - did they seem to be having trouble?Quantitative - measure time for tasksCS427 22-26Very early UI evaluationEvaluate paper prototypesEvaluation teamPerson to talk to userPerson to record observationsPerson to play computerUI made from paper, plastic (pop up menus), and colored inkCS427 22-27UI evaluationBe purposefulDecide on purpose of evaluation“Is this menu confusing?”“Can someone start using the system without reading a manual?”Choose tasksMake goals and measure to see if goals are metCS427 22-28Size of evaluationStatistically valid sample: 20-100Most common size: 5Purpose is to invent good UI, not to write a convincing paperPerform evaluations after every iterationCS427 22-29Johnson’s Law“If it hasn’t been tested, it doesn’t work.”Applied to UI:If it hasn’t been tested on real users, it is not easy to use.Feedback is essentialIteration is inevitableCS427 22-30SummaryUser interface design is hardMust understand usersMust understand problemsMust
View Full Document