Unformatted text preview:

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 InfoHW4 postponed, due: Tue, Nov 28You can submit it now if you finishedHW5 due on Dec 5Document architecture; you can start nowFinal project report due on Dec 7On-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 designLast time PrinciplesPlace the user in controlReduce the user’s memory loadBe consistentModels: design vs. userTodayObject-oriented UI designEvaluating a UI designNext: UI implementation and testingCS427 22-4Joel on softwareAffordanceMetaphor“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 designUI design communicates to userUser model should match design modelBad design model => bad UI designCS427 22-7Single modelDesigners should have a single, coherent model of the systemImplementation should match that modelThe GUI should communicate that modelThe user model should match the design modelCS427 22-8E-mailTasksRead a messageCheck to see if there is more mailReply to a new messageSend a message to a set of peopleStop half-way through writing a message and wait till tomorrowSave a messageCS427 22-9Design modelMessageMailboxIncoming messages go to in-boxMessages in out-box can be marked “ready to be sent”New messages created in out-boxCan move messages from one mailbox to anotherCS427 22-10EudoraCS427 22-11Object-oriented user interfaceObjects represented by lists, iconsOperations are on menus, buttonsPerform operation on selected objectMake a few operations that work on many kinds of objectsSpecify arguments by:Dialog boxMultiple selectionCS427 22-12Relate UI to designWindow for domain object Commands taken from operations on objectDirect manipulation interfaceWindow for use caseSeveral windows on same domain objectWindow might display state of use caseWindow might display argument (dialog box)Commands are steps in use caseCS427 22-13Command patternRepresent commands by objectsCommand can execute itselfExecuted command knows its resultCommand can undo itselfSystem keeps a list of executed commandsCS427 22-14Command for “cut text”dooldbuffer = editor.getCutbuffer();editor.putCutbuffer(editor.getSelection());editor.putSelection(‘’);undoeditor.putSelection(editor.getCutbuffer());editor.putCutbuffer(oldbuffer);CS427 22-15Command patternSuperclass “Command” with interface“do” and “undo”Subclass for each kind of commandConstructors define arguments of the commandCommand subclass defined enough variables to be able to implement undoOptional reading: “Design Patterns” by Gamma, Helm, Johnson, and VlissidesCS427 22-16SummaryDesign of a UI for OO systemsWindow for every objectWindow for every use caseCommand patternCS427 22-17Design choicesBase GUI on System design (technology)MetaphorIdiomsOptional reading: Alan Cooperhttp://www.cooper.com/articles/art_myth_of_metaphor.htmCS427 22-18Base GUI on system designMakes GUI design easierMakes GUI implementation easierUsers don’t like to see the guts of the systemCS427 22-19Base GUI on metaphorCan make system easier to learnCan limit designGood design has some “magic”May not be a metaphorBad metaphor worse than noneXP says (or used to say!) system design should be based on metaphorCS427 22-20Base GUI design on idiomsPeople learn new techniquesIf a system has only a few well-designed techniques, it will be easy to learnReuse existing idioms, and design new onesCS427 22-21Response timesFrom Usability Engineering by Jakob Nielsen0.1 sec - limit for “instantaneous”1 sec - limit for “doesn’t interrupt flow”Consider progress indicator10 sec - limit for “keeping attention focused on dialog” Consider making it a background taskCS427 22-22Evaluating UIMust evaluate UITo see how to improve itTo see whether it is good enough to be releasedCS427 22-23UI metricsSize of written specificationNumber of user tasksNumber of actions per taskNumber of system statesNumber of help messagesCS427 22-24UI evaluationOnce system has users …SurveysFocus groupsMailing list for supportAnalyze help desk logsCS427 22-25Early UI evaluationHave people use the systemGive them tasksFind out what is wrong with itSurveysDirect observationQualitative - did they seem to be having trouble?Quantitative - measure time for tasksCS427 22-26Very early UI evaluationEvaluate paper prototypesEvaluation teamPerson to talk to userPerson to record observationsPerson to play computerUI made from paper, plastic (pop up menus), and colored inkCS427 22-27UI evaluationBe purposefulDecide on purpose of evaluation“Is this menu confusing?”“Can someone start using the system without reading a manual?”Choose tasksMake goals and measure to see if goals are metCS427 22-28Size of evaluationStatistically valid sample: 20-100Most common size: 5Purpose is to invent good UI, not to write a convincing paperPerform 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 essentialIteration is inevitableCS427 22-30SummaryUser interface design is hardMust understand usersMust understand problemsMust


View Full Document

U of I CS 427 - Software Engineering I

Download Software Engineering I
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Software Engineering I and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Software Engineering I 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?