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

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: nicolas.net@gmail.com zwyip1@student.monash.edu
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 -