1. Professorial Paradox Matt Fritz Denise Ma Donald Stern Michael Tang Evan White

2. Usability Problems - System-as-is does not exist. - Currently using a Spreadsheet - Hard to manipulate/revise: - Time consuming - Complicated task that leads to errors - Requests must be interpreted before being input

3. Usability Problems (cont.) - Constraints/Requirements of the system include: - Instructor preferences for courses - Teaching loads (How much a professor may take on) - Course release (What a professor can get out of teaching) - Going on leave - Required vs. non-required courses - Multiple users (Admin, and professors) - Only Admin may commit a version of the schedule - Pointer-based interface (Due to drag and drop functionality)

4. Methods 1. Elicitation - Interviews with Admin and professors (the user population) - Small user population makes this more useful than surveys 2. Implementation - Brainstorming - Prototyping - Revision 3. Evaluation - Heuristic Evaluation - Cognitive Walk-Through - User Tasks

5. Sample User Tasks 1.Login as a faculty member 2.Login as an administrator 3.Register a new faculty member 4.Assign a professor to a single class 5.Assign team-teaching professors to a single class 6.Check required courses for a faculty member 7.Request courses (faculty member) 8.Create a schedule in the system based on a provided spreadsheet

6. Sample Interview Questions Professor Specific: - What specific terminology currently exists for tasks/processes? - What does the course request process entail? - What kinds of tasks are generally carried out by professors? - Should the system prompt to save before quitting? - What tools might help make tasks and processes easier and more transparent? Summer Specific: - Does the request process change for summer sessions and if so what does the process entail?

7. Sample Interview Questions Administrative Specific: - What does the approval process for requests entail? - What does the commitment process for schedules entail? - What specific terminology currently exists for tasks/processes? - What kinds of tasks are generally carried out by administrators? - What information does the registrar need to know and in what format? - Should the system prompt to save before quitting? - What kinds of users does the system have and what do they have access to? - What tools might help make tasks and processes easier and more transparent? Summer Specific: - Is there a different approval process for summer sessions and if so what does the process entail? - How many courses may professors teach? - Do any other processes change for summer sessions?

8. Schedule Breakdown The Time Plan/Task Allotment: 1. Elicitation - Interviews (by 4th week) - Questions prepared as a group (4/15) - Interview given by: Matt and Mike 2. Implementation (by 4th week) - Brainstorming done as a group - First prototype put together by Donald, Matt and Denise 3. Primary Evaluations (by 6th week) - Heuristic Evaluation - Prepared by group and deployed by Evan, Mike - Cognitive Walk-Through - Prepared by group and deployed by Evan, Mike - Use-Case - Prepared and deployed by group

9. Schedule Breakdown (cont.) 4. Revision (6th-8th week)* - Editing of interface based on findings from evaluations 5. Secondary Evaluations (6th-8th week)* - Cognitive Walk-Through - Prepared by group and deployed by Evan, Mike 6. Finalize Interface (9th week) - Final implementation by Donald, Matt and Denise - Final Paper Draft by Donald, Matt and Denise *Phases 4 and 5 are iterative and may thus be repeated as necessary over the 2-3 weeks alloted to them

10. Live Demo http://www.burbankparanormal.com/inf132

11. Thank You! Questions?