240 likes | 365 Views
CSCI 588 Project Status Review 17 October 2006. Cover Page. Team 19 Joshua Garcia: 1287 Umesh Dangat: 0337 Aditya Devdhar: 8062 On-Campus. Topic Description Mr. Mercury – The Mechanic. The system responds to problems detected by the hardware
E N D
Cover Page Team 19 Joshua Garcia: 1287 Umesh Dangat: 0337 Aditya Devdhar: 8062 On-Campus
Topic DescriptionMr. Mercury – The Mechanic • The system responds to problems detected by the hardware • Problems include overdue oil changes, flat tire, theft, etc. • Sends notifications • Recommends solutions • Recommends when to enact the solutions Assumptions: The system will not actually detect the problem because the hardware performs that functionality
System Requirements • The system shall notify the user by cell phone, PDA and/or PC • The system shall only run on Windows CE / Windows XP • The system shall not actually detect problems because the hardware will perform that functionality • The system shall notify the user of the problem detected by the hardware • The system shall provide appropriate solutions to the problem • The system shall allow the user to enable and disable maintenance and repair scheduling • The system shall provide the user the option to select which device the system sends notification to • The system shall maintain a history of problems and their solutions • The system shall allow all resolved problems to be deleted • The system shall allow unresolved problems to be accepted and executed or postponed for a later resolution
View Problem & Solution Resolved Problems Select Date Select Time Delete Problem & Solution Notifications Accept Solution Unresolved Problems Main Menu View Problem & Solution Postpone Resolution Settings Select Scheduling Source Maintenance and Repair Scheduling Enable/Disable Maintenance Choose Notifications by Problem Type Breakdown Theft and Vandalism Choose Notification Device(s) Navigation Map
User Profile • User characteristics (who is the user) • any user who drives a car • User tasks (what tasks the user performs) • Settings • Type of device - Cell phone, PDA, Comp • Type of problem-Maintenance, Breakdown, Vandalism • Handle notifications • Resolved • Unresolved • User workload Critical natured system • User environment Anywhere a user can carry PDA/Cell/Comp
Dialogue styles selected • Dialogue Interaction Style : Menus +Direct Manipulation + Form Fill in • Menus • Intuitively get user input • Buttons make choices lucid • Effective screen space utilization • Direct manipulation: • Use of Calendar to select the day to handle the automobile problem. • Form Fill in • Enable/disable report of certain problems
I/O Devices • Input Devices • Stylus: General Input • Most popular integrated input device with PDA • Convenient and easy to use • Keyboard • Mouse • Cell phone keys • Output Device: • PDA High Contrast Screen: • Integrated in the PDA\ • Monitor • Cell Phone Screen
Summary style Guide • The general look-and-feel of the application consists of buttons, forms and tables • Menus of buttons are placed on the center of the screen • Buttons are placed either entirely on top or bottom of the screen • The title of the screen is found at the top of each screen using the same font and color • Tables follow the general format of grey for the headers and blue for the background • Backgrounds will be consistent with either all colored in white or containing the picture of car parts
Use of Color/Fonts/Visual Design • Colors • We have abided by the “Aaron Marcus’ ten commandments for colors” in choosing 5+/- 2. • We have used the contrast colors guideline to make text more readable. • Tried to avoid use of bright and high intensity colors • We have used familiar color combinations like red for “breakdown” and “theft”. • Fonts • kept large enough to be legible, we have kept in mind the fact that this system can be used on a Baby-UI. • Visual design • Constant background theme of nuts and bolts, to show similarity of design amongst all slides. • Tables are used extensively to show the various features of problems encountered to keep the data more organised.
We chose buttons rather than pull-downs because the GUI Design Tips suggest “Don’t hide functions under pull-downs” and “Use buttons and function keys” for frequent options. Navigating to notifications, in particular, is a frequently used options. The Design Tips also mention that buttons allow for a larger click area and clearer labels. Since our system runs on PDAs and PCs, these qualities are desirable. As stated in the not-so-good checklist, we avoided grey default background by leaving the background as a simple white with faded images of automobile parts. The automobile parts represent the idea of fixing automobiles. We avoided color combinations of text and background that make the text hard to read by keeping the simple black text with white background and faded images. To assure the page can fit on a PC, cell phone or PDA we sized and positioned the window so that the window is useful immediately when opened. We achieved this sizing and positioning by keeping the window small with just a few buttons and a title that has pictures along it. Home Page
Problem Notifications Page • The problem notifications follows closely to the home page because it allows further navigation to the detailed pages for resolved and unresolved problems. • Buttons are used for frequent options (choosing between resolved and unresolved problems) as suggested by the GUI design tips. • The background is carried over as well since the page follows the same kind of format. Just like the home page, the background aims to convey the idea of automobile repair through car parts. It avoid being a distracting by making the images look lighter and faded and, thus, prevents having too many focal points on the page as suggested as suggested in the not-so-good checklist. • To allow navigation back to the main screen a hyperlink that uses standard colors for unvisited and visited links is used as suggested in Jakob Nielsen’s list.
Resolved & Unresolved Problems • We used buttons for frequently used options again. In this case, the frequently used options were viewing problems and their solutions along with deleting the problems. Thus, we have a button for viewing and a button for deleting. As suggested in the GUI design tips, we used mouse-oriented widgets to make point-and-click selection easier. We used checkboxes to allow selection of which problem would be viewed or which problems would be deleted. • We used color to convey meaning for breakdown problem types in the table. It is a cultural convention that red conveys that a serious error has occurred of some sort. In this case, the serious error is that something in the user’s automobile has broken down. • We made the table of problems use up most of the screen in order to make it the focal point of the page. This avoids the having no focal points or too many focal points as suggested in the not-so-good checklist. • To allow backwards navigation, we provided links in standard blue for unvisited and purple for visited links.
To contrast problem and solution we show the problem on top and outside a visible table, while we show the recommended solutions as a table below the problems The buttons follow the same form as previous buttons giving the user a sense of uniformity and repetition of function View Problem
We provide the user a form of direct manipulation in the form of a calendar so that s/he can choose a day to handle the automobile problem The drop-down list prevents the user from entering erroneous times The drop-down list is set up in a fashion that makes use of proper grouping and alignment to make the time easily readable and understandable Select Date & Time
Comments/Issues/Complaints/Assumptions • Tools used: • Microsoft FrontPage • Microsoft Visio • Adobe Photoshop • Microsoft Word • Microsoft PowerPoint • Lessons learned: • Team dynamics • Team communication • Feedback from teaching staff • Plans for rest of the semester: • Complete the remaining project milestones • Improve project based on feedback