CSE 5930 Assignment 2 Documentation
0 likes390 views
This document is a submission for Assignment Two of a GUI design and programming course. It includes a table of contents and sections summarizing system requirements, describing the design evolution process including prototypes and user testing, outlining low-level design guidelines, evaluating the design using usability guidelines, and concluding remarks. Instructions are also provided for running the project files stored on an accompanying CD.
CSE 5930 Assignment 2 Documentation
- 1. CSE 5930 Graphical User Interface Design and Programming Second Semester, 2005 Assignment Two – High Level Prototype Student ID: 19253419 Name: YIP ZHEN-WEI (NICOLAS) eMail Address: [email protected] [email protected] Topic: High Level Prototype Development Design Documentation Tutor's Name: Mike Smith Tute Day &Time: Wednesdays, 8:00 p.m. To 10:00 p.m. Due Date: Week Thirteen (13) Semester Two Date Submitted: Tuesday, 18th October 2005. (Apologies for the ink quality, my printer is stressed out!) - Page 1 -
- 2. Table of Contents Summary of System Requirement......................................................................................... 3 Design Evolution................................................................................................................... 3 Low Level Design Guidelines................................................................................................4 Evaluation Using Shneiderman's Design Guidelines............................................................ 5 Conclusion............................................................................................................................. 6 How to run the project from the CD..................................................................................... 6 - Page 2 -
- 3. Summary of System Requirement Basically, the system requirement for this project would normally be a networked environment. The three types of users who are due to use the system should be able to log on from anywhere on the network and do the necessary maintenance. Interfaces for the three different types of users had to mirror the differing access levels for each user. Therefore, the login mechanism had to determine which type of user is logging in, and hence, display or generate the appropriate interface. The users will have to know some basic computer knowledge as a prerequisite (except the administrators of course). The system will have to perform as efficiently as possible, and yet remain robust because it is still operated by human beings who can and would make mistakes. Instructions within the system have to be clear and concise without the need for the user to refer to some kind of manual. On that note, the software has to literally work “right out of the box”. Design Evolution Initial testing techniques were mainly based on user input and logical design guidelines based on Web design experience. Storyboard sketches of the interface design itself were drawn to assist in the design and initial evaluation. These are inserted as part of this section on the following few pages. Due to technicalities, screenshots of initial designs could not be obtained. The evaluation was conducted in the form of user acceptance tests involving randomly selected individuals who gave verbal feedback on the interface and recommendations on the items to improve upon. A major change was the switch from a multiple document interface (MDI) to a simpler and more efficient design that mirrors a kiosk. It was found that users consistently had trouble navigating drop down menus and toolbars, so simple buttons replaced all the drop down menus. - Page 3 -
- 4. Low Level Design Guidelines • Fonts & styles – Easy to read and see. Easy for the eye to flow. Preferably the Sans Serif fonts are used as they do not have the serifs that appear to “smudge” the screen. • Icons – Has to clearly define and present its purpose. • Colours, highlighting – Pleasant tone of colours from a narrow band. Pastel recommended. • Menus – Clear and concise, indicating the meaning directly to the end user. • Dialog boxes – Indicate at once what has gone wrong or the type of confirmation from the user that is needed. • Screen layouts – To follow the logical path of the human eye, which, according to a lecturer at the Malaysia Multimedia University, is from the top left of the screen to the bottom right. Should be familiar with users who have very basic computer experience (i.e., can use a mouse and keyboard usefully). • Headers & footers – Footer should be status indicators and on the right hand side, a clock showing the current time. The header should be the title of the section the user is currently in, preceeded by the name of the software. If the section title and software name are on the same line, they have to be split with an emdash (i.e. “--” ). - Page 4 -
- 5. Evaluation Using Shneiderman's Design Guidelines 1. Consistency and predictability – The software exhibited consistency from screen to screen in terms of colour scheme and font. The various functions did as predicted by the user. 2. Cater for needs of diverse users – This software at the moment is a prototype, so this feature would be implemented in the final version. For now, there is no provision for diverse users, such as, font enlargement, high contrast colour schemes, and screen reader support. 3. Provide helpful feedback – The majority of the system provides clear and easy to understand feedback in the form of appropriate confirmation dialog boxes. Thus, the user is able to know exactly what the software or system is doing. 4. Completions and exits clearly indicated – Exits are clearly indicated by confirmation dialog boxes asking the user whether it is okay to exit or not. 5. Prevent errors – At the moment, this feature is not fully implemented, but some parts of the system already exhibit it, such as the registration section, where there is a check for empty fields. 6. Allow reversal of actions – Automatic reversal of actions are implemented in the system for erroneous input. However, since this system is a prototype, undo functions are not implemented. 7. Give user a sense of control – Clear and friendly-looking interfaces are the main highlight of this system. The user is given a sense of control by being able to journey anywhere in the system. 8. Minimize memory/cognitive load – Clear and concise instructions are given throughout the system so as to minimize the memory and cognitive load of the end user. The layout and position of several buttons also mean that the user does not have the primary function of remembering where the buttons are and which button does what. - Page 5 -
- 6. Conclusion When this system was designed, several considerations had to be made. Initially, a multiple document interface was proposed, but eventually, to make the system more efficient and less of a hassle to use, an interface which constantly fills the entire screen with fixed buttons meant that the user no longer has to grapple with windows and buttons that constantly had to be repositioned. Colour was another issue, as judging by the user-task matrix, the administrator often uses the system, so there had to be more gentle pastel colours instead of the standard grey Windows default colours that look very impersonal. The good point of the system is that it is robust and stable, because it does not use a multiple document interface (MDI), it does not have to worry about refreshing itself, resulting in very irritating flicker or slowness in repositioning the child windows. A second good point to note is that the interface is mostly screen resolution independent, in that all elements in the interface dynamically position themselves in the centre part, and the entire background occupies the entire screen, regardless of the screen's or monitor's resolution. How to run the project from the CD... Run the executable file named “Project1.exe” from the “bin” folder inside the folder titled “The Project Itself”. Please DO NOT run the executables in the Debug or Release folders. They are filled with bugs! - Page 6 -