CS427: Software Engineering IHomework assignmentsFinal examTopics on UI designEvaluating UIUI metricsUI evaluationEarly UI evaluationVery early UI evaluationSlide 10Size of evaluationJohnson’s LawMore from Joel SpolskyImplementation concernsSimplicityMake controls obvious and intuitiveSafetyUse standard librariesSlide 19When to build your ownSeparate UI from applicationUI in ASPSlide 23BenefitsDownsideUI in JavaResultsSummary of separationLast words from JoelUI PatternsNext: Open-source1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 23-2Homework assignmentsHW4 due todayReviewsHW5 out, due on Tue, Dec 5Document architectureFinal project report due on Dec 7 or per agreement with graderOn-campus group can choose to meet with me or the TAs (Jeff for RUP projects, Valas for XP)CS427 23-3Final examDec 14: 7pm-10pmLet me know ASAP if you have conflictsExam will include all material from the course with emphasis on after-midtermDec 7 (last lecture): course summary, review sessionCS427 23-4Topics on UI designPreviousPrinciples and rulesModels: design vs. userObject-oriented UI designTodayEvaluating a UI designUI implementation and testingCS427 23-5Evaluating UIMust evaluate UITo see how to improve itTo see whether it is good enough to be releasedCS427 23-6UI metricsSize of written specificationNumber of user tasksNumber of actions per taskNumber of system statesNumber of help messagesCS427 23-7UI evaluationOnce system has users …SurveysFocus groupsMailing list for supportAnalyze help desk logsCS427 23-8Early 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 23-9Very 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 23-10UI 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 23-11Size 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 23-12Johnson’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 23-13More from Joel SpolskyDesign for people who have better things to do with their livesText? Mice?Memory?CS427 23-14Implementation concernsSimplicitySafetyUse standard libraries/toolkitsSeparate UI from applicationCS427 23-15SimplicityDon't compromise usability for functionA well-designed interface fades into the backgroundBasic functions should be obviousAdvanced functions can be hiddenCS427 23-16Make controls obvious and intuitiveIs the trash-can obvious and intuitive?Are tabbed dialog boxes obvious and intuitive?Is a mouse obvious and intuitive?CS427 23-17SafetyMake actions predictable and reversibleEach action does one thingEffects are visibleUser should be able to tell whether operation has been performedUndoCS427 23-18Use standard librariesDon’t build your own!If necessary, add to it, but try to use standard parts instead of building your ownCS427 23-19Use standard librariesProvide familiar controlsProvide consistencyReduce cost of implementationLibrary designers probably better UI designers than you areCS427 23-20When to build your ownYou are a platform provider orYou have special needs and a lot of money andYou are not in a hurry andYou know what you are doingCS427 23-21Separate UI from applicationUI and application change independentlyUI and application built by different peopleG U I l i b r a r y G U I A p p l i c a t i o nt e s t sCS427 23-22UI in ASPASP – embed Visual Basic code in your HTMLVB can call other codeCOM objectsMTSQuestion – how much VB goes in the web page, and how much goes outside?CS427 23-23Separate UI from applicationHTML is UIPut as little VB on web page as possibleASP has just enough VB to call a COM objectCS427 23-24BenefitsWrite automatic tests for COM object, not for UIPeople who write ASP don’t need to know how to program wellProgrammers don’t need to be good UI designersCS427 23-25DownsideCOM objects generate HTMLBut you can make standard set of “adapters” and so don’t have to duplicate codeLists, radio buttons, etc.Code tends to creep into ASPRefactorReviewCS427 23-26UI in JavaLearn to use your library (Swing)Separate application objects from UI objectsUI objects should just display or respond to eventsPut as much logic as possible in application objectsClose-box clicked: UIHas-changed: application objectCS427 23-27ResultsEasier to testAutomatic tests for application objectsTest GUI manually, and write automatic “smoke tests”Easier to changeCan change “business rule” independently of GUICan add web interface, speech interface, etc.CS427 23-28Summary of separationSeparate code into modulesTo enable people to work independentlyTo make system easier to changeTo make work easier to reuseSpecial case: Separate UI code from application codeCS427 23-29Last words from JoelInvent some users Figure out the important activities Figure out the user model -- how the user will expect to accomplish those activities Sketch out the first draft of the design Iterate over your design again and again, making it easier and easier until it's well within the capabilities of your imaginary users Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn't matching the user model.CS427 23-30UI PatternsA catalog of techniquesOrganizing contentGetting aroundOrganizing the pageGetting input from usersShowing complex dataCommands and actionsDirect manipulationNeither rules nor processOptional