DOC PREVIEW
U of I CS 427 - Software Engineering I

This preview shows page 1-2-15-16-17-32-33 out of 33 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 33 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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-2TopicsCovered since midtermSpecificationDesignQuality assuranceNextUser interface designTwo more processes (besides XP and RUP)SummaryCS427 21-3Homework 4Review work of another projectPair with someone on your projectSwap reviews with a pair from a different project (TAs assigned, see Wiki)Meet once to review their workMeet once to review your own workCS427 21-4Select work to be reviewedShould take two hour meeting to go over itGive it to other pair to read in advanceOne of you moderates the meeting, the other recordsNot how it should be doneWe do it this way to minimize workProduce a report of all the issues that were raisedTo be reviewedCS427 21-5To reviewMake a check list of things to look forRead the work, make commentsEvaluate according to check listMeet and go over items you have foundHow should the check list be improved?CS427 21-6In real lifeUsually there are several meetings until all issues are resolvedProject has a policy that determines what would be reviewed“Passing review” is a measure of progressReviews improve checklists, not just the product under reviewCS427 21-7User interface designImportantHardIsn’t covered well by most software development processesCS427 21-8When and who should do?After data modeling?Yes, for information systemsNo, for video gamesBy a specialist?Yes, for mass-market softwareNo, for in-house IS systemsCS427 21-9Design alternativesNovice usersMenusMake it look like something elseSimpleExpert usersCommands Specialize to make users efficientPowerfulCS427 21-10Design alternativesStandard IO vs. new IOExisting metaphors vs. new metaphorsNarrow market vs. broad marketCS427 21-11PrincipleUI design is more like film-making than bridge-buildingAbout communicationRequires understanding audienceRequires specialized skillsRequires iterationCS427 21-12Book reviewJoel Spolsky on UI Design for ProgrammersThree chapters per lectureLearned HelplessnessA user interface is well-designed when the program behaves …Program model vs. User ModelUser model is simpleEvery time you provide an option, you are asking the user to make a decisionCS427 21-13PrincipleUI design is more like film-making than bridge-buildingAbout communicationRequires understanding audienceRequires specialized skillsRequires iterationCS427 21-14Golden rulesPlace the user in controlReduce the user’s memory loadBe consistentCS427 21-15Place the user in controlNo modes (vim?)Use a new window instead of a new modeMake modes visibleUndoMacrosHide technical detailsDirect manipulationCS427 21-16Bad wizardsCS427 21-17Obtrusive assistanceCS427 21-18Non-obvious choicesCS427 21-19Reduce memory loadReduce demand on short-term memoryEstablish meaningful defaultsDefine intuitive shortcutsDisclose information progressivelyUse real-world metaphorsSpeak user’s languageLet user recognize, not rememberCS427 21-20Common techniquesMenus with keyboard shortcutsDialog boxesTabsToolbarCS427 21-21Be consistentUse visual interface standardsFor operating systemFor organizationFor product or set of productsShow context - keep user from getting lostSystem should explain itselfCS427 21-22Selection using scroll barCS427 21-23The UI design processImplementationUser, task, andenvironmentanalysisInterface validationInterface designCS427 21-24ModelsDesign model - what the designer thinks about the systemUser model - what the user thinks about the systemSystem 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 phasesWhat 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 phasesDesignWhat 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 modelValidationDoes 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 casesUse cases are high-level tasksDecompose high-level ones into low-level onesFind ones that are missingSimplify by generalizingUI design requires more detail than use case analysis usually providesCS427 21-30TasksFor 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 designMap task into actions that can be directly implemented by standard widgetsUse consistent labels across tasksUse consistent widgets across tasksCS427 21-32User interface designUI communicates with the userLike any form of communication, Needs feedback and iterationThere are standard ways of making a UIGreat UIs are rare and require creativityCS427 21-33Next: More UI designRead chapters 4-6 of the book on UI design for programmers


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?