CSE 5930   Graphical User Interface Design and Programming                         Second Semester, 2005 Assignment Two – ...
Table of Contents Summary of System Requirement..............................................................................
Summary of System Requirement      Basically, the system requirement for this project would normally be a networkedenviron...
Low Level Design Guidelines•   Fonts & styles – Easy to read and see. Easy for the eye to flow. Preferably the Sans Serif ...
Evaluation Using Shneidermans Design Guidelines1. Consistency and predictability – The software exhibited consistency from...
Conclusion        When this system was designed, several considerations had to be made. Initially, amultiple document inte...
Upcoming SlideShare
Loading in …5
×

CSE 5930 Assignment 2 Documentation

183 views

Published on

User interface design and programming with visual basic dot net. circa 2004.

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
183
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CSE 5930 Assignment 2 Documentation

  1. 1. CSE 5930 Graphical User Interface Design and Programming Second Semester, 2005 Assignment Two – High Level PrototypeStudent ID: 19253419Name: YIP ZHEN-WEI (NICOLAS)eMail Address: nicolas.net@gmail.com zwyip1@student.monash.eduTopic: High Level Prototype Development DesignDocumentationTutors Name: Mike SmithTute Day &Time: Wednesdays, 8:00 p.m. To 10:00 p.m.Due Date: Week Thirteen (13) Semester TwoDate Submitted: Tuesday, 18th October 2005.(Apologies for the ink quality, my printer is stressed out!) - Page 1 -
  2. 2. Table of Contents Summary of System Requirement......................................................................................... 3 Design Evolution................................................................................................................... 3 Low Level Design Guidelines................................................................................................4 Evaluation Using Shneidermans Design Guidelines............................................................ 5 Conclusion............................................................................................................................. 6 How to run the project from the CD..................................................................................... 6 - Page 2 -
  3. 3. Summary of System Requirement Basically, the system requirement for this project would normally be a networkedenvironment. The three types of users who are due to use the system should be able to log onfrom anywhere on the network and do the necessary maintenance. Interfaces for the three different types of users had to mirror the differing access levelsfor each user. Therefore, the login mechanism had to determine which type of user is loggingin, and hence, display or generate the appropriate interface. The users will have to know some basic computer knowledge as a prerequisite (exceptthe administrators of course). The system will have to perform as efficiently as possible, and yet remain robustbecause it is still operated by human beings who can and would make mistakes. Instructionswithin the system have to be clear and concise without the need for the user to refer to somekind 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 guidelinesbased on Web design experience. Storyboard sketches of the interface design itself were drawn to assist in the design andinitial evaluation. These are inserted as part of this section on the following few pages. Dueto technicalities, screenshots of initial designs could not be obtained. The evaluation was conducted in the form of user acceptance tests involving randomlyselected individuals who gave verbal feedback on the interface and recommendations on theitems to improve upon. A major change was the switch from a multiple document interface (MDI) to a simplerand more efficient design that mirrors a kiosk. It was found that users consistently hadtrouble navigating drop down menus and toolbars, so simple buttons replaced all the dropdown menus. - Page 3 -
  4. 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. 5. Evaluation Using Shneidermans Design Guidelines1. 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. 6. Conclusion When this system was designed, several considerations had to be made. Initially, amultiple document interface was proposed, but eventually, to make the system more efficientand less of a hassle to use, an interface which constantly fills the entire screen with fixedbuttons meant that the user no longer has to grapple with windows and buttons thatconstantly had to be repositioned. Colour was another issue, as judging by the user-taskmatrix, the administrator often uses the system, so there had to be more gentle pastel coloursinstead 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 amultiple 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 resolutionindependent, in that all elements in the interface dynamically position themselves in thecentre part, and the entire background occupies the entire screen, regardless of the screens ormonitors 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 withbugs! - Page 6 -

×