Evaluating the usability of our user interface using

heuristic methods
We validated the usability of our prototype by comparing our system with Nielsens 10
general principles of user interface design.
1.Visibility of the System Status
Our system performs quite well with this heuristic. When a button is pressed
or an item from a drop down list is selected, the system clearly indicates it. In the case of a
button, the button is indented. In the case of a list, the selected item is clearly indicated in
the text field.
2. Match between systems and the real world
Our system does not use any system-oriented terms, it uses real world
language in a logical order throughout and would be easy to follow for any English speaker.
3.User Control and Freedom
Every function in our system is easy to undo and redo. If a button or list item
is selected, it can easily be unselected in the same manor in which it was selected. The only
other case is if the user goes through with a booking and then realizes after that he/she has
made a mistake. In this case a booking can be easily cancelled by selecting the booking and
hitting cancel. The user can then proceed to make a new booking.
4. Consistency and Standards
The groups of buttons and actions are clearly segregated and it is easy to tell
actions and related buttons apart. The only inconsistency we have is that in some situations
where it is unpractical to use buttons, we use lists instead.
5. Error Prevention
Our system makes it very difficult for a user to make a system error. All
actions are clearly marked at each step and users are well aware of the status of the system
at every point. The only error we found that we could not prevent is if the user mistakenly
enters another users library number. Resulting in a user making a booking for someone
else.
6.Recognition rather than recall
When using our system at each step it is clear to the user the progress that
he/she has made. They do not need to recall any information as they can clearly see all of
the progress they have made.

7.Flexibility and efficiency of use

Though not present in our prototype, if the system was put to use we would
plan to implement a feature that lets users rebook frequent bookings without having to go
through the entire booking process again. Even without this feature there should be minimal
frustration to frequent users, as the booking process is very fast and easy to get through.
8. Aesthetic and minimalist design
We have tried to keep the design as minimalistic and simple as possible,
making sure it is easy to use and understand by all. We also made sure to try and keep out
anything irrelevant to the task at hand. We also feel the aesthetic could have been a lot more
pleasing, but not without deferring from the theme of the DCU website.
9.Help users recognize, diagnose and recover from errors
During the booking process there are two errors that the user can make. The first
being that the user enters the wrong library number and the second being that the room they
are trying to request is already booked. In both scenarios the user is presented with an error
message in plain language, making it very easy for the user to fix the problem.
10. Help and Documentation
Though the system is very self explanatory, if implemented we would still
insist that there be documentation on how to use the system on the librarys website. The
documentation would include a detailed walkthrough of the system, showing users what to
do in each stage of the booking process. It would show users how to handle an error should
one occur.
On conclusion, we found our system to be very usable when comparing it against Nielsens
10 general principles of user interface design. The only major flaw being that we used
buttons and drop down lists rather than using just one of these to keep consistency. Though
we do feel that this was necessary, as too many buttons would have resulted in a cluttered
page and too many lists would have resulted in tedious scrolling. Otherwise we are very
happy with the usability of the system.

Initial user testing

To test our prototype with users we tasked six people with booking a room, check its details
after booking and then finally deleting the booking. We ordered the six people into the
following groups:

2 who are knowledgeable in computers.

2 who are new to computers.

1 with visual impairments.

1 with motor impairments.

This allowed us to test our prototype the same way the old study room booking system was
tested. Since we have already tested it with users who provided feedback on the usability of
our website we instead observed how quickly the new group of users completed the tasks as
well as noting any mistakes they might have made during the tests. The users were given
what information they needed to provide, such as what date they are to book the rooms and
what for what times. This is meant to ensure that none of our participants waste any time in
deciding which date and time to choose nor that they simply select the dates and times that
are the quickest to click on. This way all of our tests are fair and the time it takes for a user to
make a decision is eliminated entirely, as to not impact the results.

The first of the two participants who had previous experience in using computers and
navigating websites had no issues with completing the tasks and did so in very little time.
The second participant of this category was almost identical except for them taking their time
to read in instructions as not to make any mistakes.

The two participants who were relatively new to computers completed the tasks provided
with no issues. While both took their time to read over instructions and what information they
are to provide in which field, neither of them made any mistakes and they still completed the
tasks in a short time.

The participant with visual impairments had long sightedness and while they would normally
use glasses to correct this they removed them for the sake of testing the program. This test
was taken twice, once with them using the booking website without a screen reader and then
again with a screen reader. For the first test they completed the tasks given yet it took
considerably more time to do so as they mistakenly inputted incorrect information into certain
fields, such as inputting their DCU student username instead of their student number and
selecting incorrect dates. When a screen reader was introduced they completed the tasks in
less time though with no mistakes. While their time did not improve by much we suspected it
to be due to them having no past experience with using a screen reader. By doing this test
twice weve been provided with information on how easily and quickly a visually impaired
user could use the prototype whether or not they had help from a screen reader.

The final participant had motor impairments, primarily they had essential tremors and thus
shaky hands. Since they used a keyboard with slightly larger keys at home they were asked
to test with it. They managed to complete the tasks and while their shaky hands made using
the mouse slightly more difficult for them they completed the tasks slightly faster than the
two participants who were new to computers

From these tests weve concluded that not only is our website easy to navigate by both
students with experience and without, but that the room booking prototype is suitably catered
for users with impairments, be they visual or motor.

We did not test for combinations of these factors (e.g. a user who is both inexperienced in
computers and visually impaired) as we found that any results from said tests would easily
be predicted though combining the results of the tests we already have.

Another test we could not do due to difficulty in finding such a user is the prototypes
usability toward a colorblind user. Such a test would be greatly beneficial for the report as it
provides another possible perspective and could potentially find flaws in the prototype.
Although another reason for us not testing was the fact that any issues a user with colour
blindness might have could easily be prevented through the careful selection of button
colours and hues.

Final testing of our user interface

To test our website, we need to first of all state the objective of our website and then make
sure our website meets all the expectations of our users. First things first, we have to
authenticate the student using his or her student number. For something as simple as
entering the student number there is a lot of different scenarios that we have to cover. For
instance, in the scenario where student enters the wrong student number, we need to make
sure our website recognises that and notifies the student. Also, what if the user does not
provide the student number all together. Once again we need to make sure our website
recognises that and notifies the user. Now that we identified all the possible scenarios we
performed a Unit testing on this particular component. We used QUnit, which is a JavaScript
Unit testing framework. Following the setup, we wrote the test functions and after the
execution of these test function we received the following results:

Result

Test Name

Project

Passed

WrongNumber

system.test

Passed

NoNumber

system.test

Passed

CorrectNumber

system.test

Error Message

After we performed our usability test, which is intended to determine the extent to which the
user can complete the routine tasks we have some shocking findings that could not be
ignored. First of all out original design had one major flaw, when we initially were designing
our system we did not consider the users with restricted visual abilities and users completely
reliable on screen readers. Our original design would prompt a mini calendar which would be
used to select the date. However, it had to be changed as it was not accessible to screen
readers, therefore we changed to simple drop down menus. In the end, to make things
easier for the end user we ended up using two drop down menus, one for selecting the date
and one for selecting the time. Then we performed a follow up usability test and these were
the results.

Participant

Task 1
completion rate

Task 2
completion rate

Task 3
completion rate

Task 4
completion rate

100%

100%

100%

100%

100%

100%

100%

100%

100%

100%

100%

100%

100%

100%

100%

100%

Task 1 = Entering the student number

Task 2 = Choose a study room type
Task 3 = Select a date
Task 4 = Selecting the time

After the completion of each task, we asked the participants to rated the ease or difficulty of
completing the task for three factors:
The ease of navigation.
Ability to keep the track of where you are on the website.
Ability to accurately predict the next step of booking the room.
The 5-point rating scale ranged from 1 (Strongly disagree) to 5 (Strongly agree). Agree
ratings are the agree and strongly agree ratings combined with a mean agreement ratings of
> 4.0 considered as the user agrees that the website is easy to navigate, easy to keep track
and easy to predict.

Task

easy to
navigate

easy to keep
track

easy to predict

Overall

Entering the
student number

5.0

5.0

5.0

5.0

Choose the
study room type

5.0

5.0

5.0

5.0

Select the date

4.5

4.6

4.0

4.4

Selecting the
time

3.0

2.8

3.1

3.0

All participants agreed that entering the student number section was designed well (mean
agreement rating = 5.0) and 100% found that choose the study room type section was
designed well (mean agreement rating = 5.0). Only 65% of participants found that selecting
the time section was designed well(mean agreement rating = 3.0) and 90% found that
selecting the date section was designed well (mean agreement rating = 4.4).

Afterwards we asked the same 4 participants to rate the site for 6 overall measures such as:
Ease of use
Frequency of use
Difficulty to keep track of where they are
How quickly most people would learn to use the site
The speed of which the task is completed
Site organization

Strongly
Disagree

Disagree

Neutral

Agree

Ease of use
Frequency of use

Difficulty to keep track

Strongly
Agree

Percent
Agree

100%

3
3

88%
1

95%

The learning curve is easy

81%

Objective is completed fast

88%

Site is well organization

All of the participants (100%) agreed (i.e. strongly agree) that the website was easy to use.
The majority of participants (88%) agreed they would use the site frequently and that the
sites content would keep them coming back. 95% agree that it is easy to keep track of
where you are at all times and 81% agree that the site is easy to learn how to use. Our
findings also show that 88% agree that the whole process of booking the room is done very
fast and effortlessly and 100% of people think that our website is very well organised.

100%