system prototype and evaluation plan

System Prototype & Evaluation Plan Electronic Attendance System

Joseph Ng Chow [email protected]

Victoria Mui [email protected]

Brian Shim [email protected]

Veronica Wong [email protected]

DAVE DEARMAN

CSC318 – THE DESIGN OF INTERACTIVE COMPUTATIONAL MEDIA

NOVEMBER 10, 2008

Table of Contents

PROJECT DESCRIPTION #

REQUIREMENT SUMMARY #

FUNCTIONAL #

USER #

USABILITY #

ENVIRONMENTAL #

TECHNICAL #

ADDITIONAL USABILITY REQUIREMENTS #

DESIGN SUMMARY #

STORYBOARD PROTOTYPE #

DESCRIPTION #

STORYBOARD #

SCENARIO #

RATIONALE #

PHYSICAL PROTOTYPE #

DESCRIPTION #

VISUALS #

SCENARIO #

RATIONALE #

FUNCTIONAL PROTOTYPE #

DESCRIPTION #

VISUALS #

SCENARIO #

RATIONALE #

EVALUATION PLAN #

SUMMARY #

WHO DID WHAT? #

Note: Although the system has two user groups, administrations and teachers, we will only be

focusing on the teachers‟ perspective in this report.

Project Description After our research in G2 and G3, we have solidified our vision for the Electronic Attendance

System (EAS). Our studies have shown that the current Trillium system that is used throughout

the Toronto District School Board comes with three shortcomings that undermine the integrity

of the student attendance system. (1) The machine-readable paper that is scanned into the

system is designed in a way that makes it easy for the user to make mistakes resulting

inaccurate records. (2) It requires student couriers to deliver class attendance to the

administration office, causing them to miss class and burdening them with responsibilities that

are irrelevant to their studies. (3) Attendance forms are taken down to the office specific

times in the day. Consequently, only the teacher or the office is aware of a student‟s presence

at a given time making it difficult to determine a student's whereabouts in an emergency

situation.

The general application of EAS is to facilitate school attendance systems by addressing all of

these issues. By designing a simple device that transmits student records electronically in real-

time, we eliminate the need for a student courier, and all concerned parties will have up-to-

date student records. Teachers will take attendance through an electronic panel that is

populated with students from the class list. If a student arrives late, the teacher will correct

the student's attendance record as opposed to sending them down to the office to update their

status. The attendance record and any status updates will be transmitted to the administration

office immediately, where it is processed. Administration staff can then identify the students

that are late or absent without a note, and address these cases. Teachers and administration

staff are our target users, but students and parents will also benefit from EAS. In particular,

through this proposed attendance system, students will lose less class time and parents will

know where their children are at all times.

Requirements Summary

Type of Requirement Key Requirements

Functional Requirements

Provide an up-to-date record of student attendance to school staff at all times.

Offer teachers an intuitive and fast way of taking student attendance.

Offer administration staff a way of quickly and accurately performing their tasks regarding late and absent students.

Act as a means of communication during emergency situations (e.g., lockdowns).

Target User

Requirements

Primary and Secondary school staff who are responsible for maintaining student attendance records are required to have the following traits:

Have basic knowledge and experience with using technological devices like Automated Teller Machines (ATM), cell phones, and/or computers …etc.

Do not have severe disabilities and/or impairments that will affect their ability to use technology.

Usability Requirements

Product design and interface must be intuitive so users can use the system with little or no special training.

Allows users to access features and menus through minimal system interactions; these include: screen touches, mouse clicks, button presses…etc.

Visual feedback of system activities; the use of colour was especially well-received

Environmental

Requirements

The school environment must have an encrypted wireless connection.

Classrooms and facilities have power via dedicated power lines at the location where the device is to be installed.

Make use of existing equipment

Technical

Requirements

Product needs to be portable in order to meet the needs of users in cases of emergencies (e.g., school fires), allowing staff to carry around an up-to-date copy of student attendance for the entire student body.

Product must be of a reasonable weight in order to support the portability requirement.

Product needs to be durable enough to withstand everyday usage.

Product needs fast and intuitive means of acquiring input data from the users.

Product needs to have a clear way of representing results and output to the users.

Support text-based messaging communication between system outlets within the school system (emergency situations).

Device must be able to run on both battery and AC power.

School must have a database in which the product can send the attendance data to. This database must be secure, reliable, and backed up on a regular basis.

Additional Usability Requirements

Flexibility

The device needs to be able to support different levels of user skill. The tool should be simple

enough to accommodate for a new user as well as fast for a very experienced user. For

example, a new user may want to physically click through menus, while an experienced user

may use quick key shortcuts.

Predictability

Generally the system should be predictable when it is interacted with. For example, it would

be quite awkward and counter intuitive if pressing the “message button” resulted in the device

pouring you a cup of coffee.

Design Summary After assessing the different designs in the previous report, we will extract the best features

from each alternative and implement them in the final design.

We will go forward with a custom electronic attendance panel (herein referred to as the EAP)

which was introduced as Design 1. It will be 11” by 11.2” by 0.75” (length, width, depth,

excluding the keyboard), where the display screen is similar in dimensions to the standard

machine-readable paper that is 8.5 x 11 inches. Since the panel needs to be portable, the

width of the panel is designed such that it can rest comfortably between the elbow and the

palm when held. From Design 2 and Design 3, we will integrate the stylus and keyboard

hardware, respectively. The display screen will be sensitive to the stylus. We want to re-create

the current system interaction as much as possible to minimize the learning curve and

adjustment. Replicating the current attendance sheets on the panel and receiving user input

via stylus mimics how teachers currently take attendance. We acknowledge the difference in

legibility between a traditional and digital pen, both from our own experiences and from the

feedback we received in G2. Although writing is not required on a daily basis, based on our

research in G1, silent communication during emergencies is a key requirement. The

implementation of the keyboard is to offset this critical shortcoming of the stylus.

Aside from the class list, the screen will also display a tool bar and a notifications bar that will

be present at all times while the system is in use. Included in this static interface are the

“Back”, “Forward”, “Contact the Office”, “Class information”, “Date and Time”, “Logout”,

and “Period” buttons and labels. This will give teachers one-click access to all their attendance

related duties. The convenience of the toolbar was a major advantage of the 3rd design.

To help teachers keep track of their activities and the status of the school, the interface will

also support visual feedback through the use of colours, pop-up messages, and the notifications

toolbar. For example, while the teacher is taking attendance, the system will automatically

highlight the student to be marked so the teacher will not miss a student accidentally as

he/she traverses the class list. Once the attendance has been submitted, a log entry will

appear on the notification bar to indicate a successful submission. If the school goes into lock-

down mode, the buttons will change colours to reflect the situation. All of these features will

be discussed in detail in the following prototype representations.

Prototypes

Storyboard Prototype

Description:

The storyboard representation of the system will demonstrate EAS‟s functionality, and the

circumstances under which target users will utilize EAS. As you may recall, there are two main

functionalities of EAS: (1) to allow teachers to take their daily attendance and update student

attendance records as needed; (2) to provide a means of silent communication and a means of

keeping track of safe and missing students in emergency situations.

Function 1: Daily Attendance Taking

Illustrated in the first storyboard, the steps that teacher make in order to take and update

attendance records can be summarized as follows:

1. The teacher takes the attendance using EAP.

2. He/She submit the attendance record.

3. The teacher begins teaching that day‟s lesson.

4. A student arrives later on that class:

i. The teacher corrects the student‟s status on the attendance records via EAP.

ii. The teacher updates the attendance records.

Function 2: Emergency Lockdown

In the case of school lockdowns, the EAS help facilitate emergency procedures. The

responsibilities of the EAS include: receiving notifications from the administration office for

further instructions; indicating which students are currently under their supervision include

students who have been adopted; contacting the office when they are in need. These

operations are demonstrated in the second storyboard where:

1. An intruder has been spotted within the school building.

2. The school immediately carries out their lockdown procedures.

3. A global message is sent to all electronic attendance panels (EAPs) announcing the

school is going to have a lockdown.

4. Students that are in the hallways go to the closest available classroom.

5. Teachers use EAS to take the attendance of students they have in their classroom.

i. Teachers adopt any students that belong to other teachers.

6. A student suddenly needs medical assistance:

i. The teacher uses their EAP to contact the administration office and request for

EMS.

Storyboard:

Scenarios:

Scenario 1

It is a lovely day at Morningwood High School. All the school children are heading to class. The

clock strikes 8:45 a.m. and the students in Mr. Tao's computer science class scurry to their

seats. “All right class settle down, I don't smell that bad,” says Mr. Tao. He grabs the Electronic

Attendance Panel (EAP) and holds it in his arm as if he were holding a clipboard. Mr. Tao begins

to call out the names of his students. “Here,” calls a student. Mr. Tao nods his head in

acknowledgement and pokes the “present” button on the screen next to the student's name.

Mr. Tao asks, “Is Joseph Yeung here?” Silence fills the room. It appears that Joseph Yeung is

absent so Mr. Tao presses the “absent” button next to Joseph's name and continues. After he

finishes calling out names, Mr. Tao submits his attendance and begins his lecture on binary

search trees. All the smiling faces dissolves into frowns. Suddenly, Joseph stumbles in late.

Joseph looks at Mr. Tao and sees him shake his head. Mr. Tao stops his lesson, picks up the EAP

again and scrolls over to Joseph's name. Mr. Tao taps on the “late” button and updates the

records. Joseph takes his seat. The attendance has gone through smoothly.

Scenario 2

It is a Monday afternoon at Greenwood Public School. A storm looms in the distance while all

the students are busy learning. Joanne, the vice-principal, is one such individual and is

currently dealing with the issue regarding a boy who choked on a grape at last week's student

potluck. She takes a second to look at the surveillance video of the school's exits, and notices

something out of the ordinary. She sees an unidentifiable man enter the school concealing

something in his jacket. With the possibility of it being a weapon, she sends a global message

to each teacher‟s EAP and begins to take lockdown precautions.

In Mrs. Reynolds classroom, she glances over at the EAP on her desk and sees a flashing

lockdown warning message. She begins standard lockdown procedures. As she attempts to

close the door, a student, Veronica Wong, runs in. Mrs. Reynolds locks the door, closes the

blinds and urges Veronica and her class to sit quietly in a corner of the room. Mrs. Reynolds

grabs the EAP and begins to retake the attendance. Before she finishes, she remembers that

Veronica had entered her class. Using the EAP, Mrs. Reynolds uses the “Adopt Missing Student”

command to sign Veronica in. Once she finishes with this and finalizes her attendance, she

realizes that one of her students is holding their ankle in pain. Mrs. Reynolds immediately uses

the EAP to send a message to the main office to request medical assistance. 15 minutes later,

the lockdown situation ends and an ambulance arrives. All is well.

Rationale:

The advantage of using a storyboard to represent our system Is that it allows us to step back

and see the product from a third-persons perspective. The thought process of the exercise

enables us to guage the stakeholders‟ understanding of system operations and usage. It also

gives our participants an overview of the system procedures.

Moreover, storyboards are cheaper and easier to create than physical or functional prototypes.

Because storyboards do not depend on external factors, scenarios can simulate situations that

cannot be easily created in real life. For example, in demonstrating the role in which EAS

plays during lockdown situations, it is easier and more practical to represent that scenario by

storyboarding than simulating a real armed intruder.

Physical Prototype

Description

The Electronic Attendance Panel (EAP) will be approximately 11” in length, 11.2” in width and

0.75” in depth and will be comprised of the following components:

Display

The display for device will be composed of a 15” LCD screen separated into two parts:

1. Notifications Bar

The Notifications Bar will take up approximately 20% of the devices total length as

well as span the entire height of the device. The length is the distance along the

users forearm when they hold it. It will be insensitive to pressure, and be softer to

the touch.

2. General Display Pane

The General Display Pane will take of the remainder of the devices length as well

as span the entire height like the Notifications Bar. The pane will be shielded with

a protective screen guard, and be sensitive to the stylus.

Stylus

The stylus will be approximately 6” in length with the diameter of an everyday pen. The stylus

will be docked along the side of the Notifications Bar.

Keyboard

The device will have a 10.7 x 4.2 x 0.75 inch wireless QWERTY keyboard. The keyboard will be

attached onto the back and can be removed to be used in an emergency for user input.

Battery

The device will have a standard lithium-ion battery located within the casing. It can be

charged through any common wall outlet.

Visuals

Scenarios

Scenario 1

It is a lovely day at Morningwood Elementary School. All the school children are heading to

morning classes. The clock strikes 9:00 a.m. and the students in Mr. Tao's computer science

class scurry to their seats. Victoria is one such student and leaps over a fallen book titled “The

Grapes of Wrath”. Unfortunately, she does not notice that she knocked over an open bottle of

juice. One might say that it is just asking to be slipped on. “All right class settle down, I'm not

that good looking,” says Mr. Tao. He moves the Electronic Attendance Panel (EAP) and orients

it on his desk at the front of the class. He reaches to the side of the EAP, removes the stylus

from its clasp and grasps it as if it was an ordinary pen. With a few quick passes of the stylus

on the screen, he awakens the panel from its sleep. Using the stylus, Mr. Tao enters his

information into the system and logs in. “Tap, tap, tap,” goes the stylus to the screen as he

enters his employee number and PIN. After logging in, Mr. Tao begins to call out the names of

his students. “Here,” calls a student. Mr. Tao nods his head in acknowledgement and pokes

the “present” button on the screen next to the student's name. Mr. Tao asks, “Is Joseph Yeung

here?” Silence fills the room. It appears that Joseph Yeung is absent. Mr. Tao presses the

“absent” button next to Joseph's name and continues. After a few minutes, the attendance is

complete and Mr. Tao begins his lecture on amortized analysis. As cheers of eagerness fill the

room, Joseph stumbles in. Unfortunately, Joseph is late. Joseph looks at Mr. Tao and sees a

glare of disapproval. Mr. Tao stops his lesson, picks up the EAP as if he were holding a

clipboard and grips it. He approaches Joseph to ask him for his reason for lateness. As Mr. Tao

walks around his large teacher's desk, he slips on a well placed puddle of grape juice and

momentarily loses his balance. The EAP on his arm wobbles a bit, but he manages to hang onto

it because of the grip on its side. After having his life flash before his eyes, Mr. Tao taps on

the “late” button next to Joseph Yeung's name. Joseph wipes up the mess and takes his seat.

Scenario 2

It is a Monday afternoon at Greenwood Public School. A storm looms in the distance while all

the students are busy learning. Joanne, the vice-principal, is one such individual and is

currently dealing with the issue regarding soured grapes being served at last week's staff

picnic. She takes a second to look at the surveillance video of the school's exits, and notices

something out of the ordinary. She sees an unidentifiable man enter the school concealing

something in his jacket. With the possibility of it being a weapon, she announces over the

intercom, “Attention, code red lock down. I repeat, code red lock down. This is not a drill.”

Mrs. Reynolds, hearing the announcement, glances at her EAP and sees a flashing lockdown

warning message. She immediately locks the door, closes the blinds and urges her class to sit

quietly in a corner of the room. She then unplugs the EAP from its charging position on her

desk, fits the 15 inch display snugly in her left arm and quietly joins the rest of her class. Mrs.

Reynolds takes out the stylus and begins to retake the attendance. Once she finishes, she

realizes that one of her students, Veronica, is scratching her skin a lot and having trouble

breathing. Apparently she had had an allergic reaction to something she ate. It later turned

out to be concord grapes. Mrs. Reynolds immediately taps the EAP and attempts to send a

message to the office to request assistance. She slides the wireless keyboard out from the

back of the panel and brings it around to type. After requesting aid for Veronica, Mrs.

Reynolds reattaches the keyboard to the back of the panel and waits for a response. 10

minutes later, the lockdown situation ends and an ambulance arrives.

Rationale A physical prototype is necessary in the evaluation process to give participants an idea of how

the system would feel like if it were real. We recalled how difficult it was to explain our vision

of the system to our participants during the field studies. While we were able to communicate

what our system was supposed to do, it was hard for the participants to visualize what the

system would look like even with the pictures we fabricated. Even if they were able to imagine

it, the ability to hold it and assess the weight, the feel of the screen, the comfort of the grip,

and other such factors is a very difficult exercise.

To understand the design decisions in developing the hardware, one needs to look at the

reasoning for some of our individual components.

Notifications Bar

The Notifications Bar is insensitive to the stylus, or any other pressure so that the users have a

place to rest their hands when the EAP is held without having to worry about activating

features on the touch screen. Softening the feel of Notifications Bar was an ergonomic design

decision for teachers who prefer to take the attendance while standing.

Display

After looking at other interactive handheld devices such as cell phones and the Nintendo DS®,

we considered a protective screen guard. We focussed more on the Nintendo DS® as it was the

most similar to our device. Seeing all the rigors a touch sensitive screen is put through with

the stylus, we realized that it is necessary to protect the device for the long run. It was agreed

that the cheapest and most effective method of protecting the device would be a screen

protector. This is in line with one of our technical requirements.

Stylus

The idea of the stylus was undoubtedly the feature that was the most popular in our early

research stages.1 The stylus was chosen as it provided the most precise interaction with the

device and resembled a common stationery pen. A mouse requires the user to follow the

cursor with their eyes and slow down when approaching their target. With the stylus, the user

can just touch the screen to interact with the features at the target points.

Keyboard

The keyboard was included in the design as it seemed to be the most intuitive way to

communicate silently in an emergency situation when we noticed that 11/12 were familiar with

a computer. The actual physical keyboard was scaled down in size so that it could fit the

dimensions of the device and be out of the way when not in use.

Battery

We chose to use a lithium-ion battery as it has one of the best energy-to-weight ratios and its

slow loss in charge when not in use. As well, since it is common in consumer electronics, we

would not have to “re-invent the wheel” to power our device. The battery is located within

the casing so that cumbersome appendages would not stick out.

Size

Choice of the dimensions and weight was made with user comfort in mind. The details and

reasoning behind this will be discussed in The Design and Implementation Process section.

Functional Prototype Our functional prototype demonstrates the task of teachers taking attendance via the

Electronic Attendance Panel (abbreviated EAP). The two scenarios that we will consider are

daily class attendance and emergency class attendance. We have used paper a prototype to

illustrate the functionality of our system under these situations.

1 See Appendix for earlier research

Description

When the teacher first interacts with the system, they are presented with a login screen that

takes in the teacher‟s employee number and PIN. This is done with the stylus and an onscreen

number pad.

After user authentication, the system displays a digital attendance sheet of the class that

teacher should be teaching based on the login timestamp. A “Successful Login” notification

appears in the Notifications Bar. Framing the attendance is a GUI panel with buttons, labels

and tabs; the supported features are: „Back‟, „Forward‟, „Contact‟, „Class Label‟, „Date and

Time‟, „Logout‟, and four „Period‟ tabs.

The digital attendance sheet is a replica of the existing attendance sheet used by the Toronto

District School Board with some modifications. Instead of 15 bubbles (a set of 3 for „present‟,

„late‟, and „absent‟ for each school day of the week) for each student, there are 3 radio

buttons for „present‟, „late‟ and „absent‟. Beside each student‟s name, there is a picture of

the student.

The teacher will mark each student as „present‟, „late‟, or „absent‟, by tapping on the

corresponding radio button next to each student‟s name. Submission is done electronically on

the panel via the „Submit Attendance‟ button at the end of the class list. The teacher is then

brought to an attendance summary screen where they are able to make changes if a mistake

was made, or if a student arrives late. “Successful Submission/Modification” notifications are

sent to the Notifications Bar as well.

After the teacher submits the attendance, it is received instantaneously by the administrative

staff. When the teacher modifies the attendance, results from the administrative side are

updated in real time.

After 10 minutes of idleness, the teacher will be logged out of the system automatically if they

haven‟t already done so. Notifications are cleared upon logging out.

In emergency situations, all security measures are dropped, and the GUI takes on a special red

colour scheme. A global announcement is sent to all EAPs from administration. Once the

teacher acknowledges the message, the EAP will be populated with all students that were

marked present during that period. Only two bubbles will appear beside each student‟s name:

„Present‟ and „Missing‟.

Along with the „Submit Attendance‟ button, there will also be an „Adopt a Missing Student‟

button that will allow teachers to adopt another teacher‟s student into their classrooms. By

inputting the student‟s student number, the student‟s location is transmitted electronically to

the administration as well as to the EAP of the original responsible teacher.

Should a teacher require assistance, he/she may contact the administrations office via the

„Contact‟ button on the GUI.

Visuals

More detailed scans of the interface may be found in the appendix.

Daily Use

Emergency Use

Scenario

Scenario 1

It is a lovely day at Morningwood Elementary School. All the school children are heading to morning

classes. The clock strikes 9:00 a.m. and the students in Mr. Tao's computer science class scurry to their

seats. “All right class settle down, I know I'm handsome,” says Mr. Tao as he moves the Electronic

Attendance Panel (EAP) and places on his desk. Mr. Tao enters his employee number and PIN by tapping

the digits on an onscreen number pad using the stylus. After logging in, the screen is populated with

the current class list based on the time of day. Mr. Tao begins to call out the names of his students.

“Here,” calls a student. Mr. Tao nods his head in acknowledgment and pokes the “present” button on

the screen next to the student's name. Mr. Tao asks, “Is Joseph Yeung here?” Silence fills the room. It

appears that Joseph Yeung is absent. Mr. Tao pokes the “absent” button next to Joseph's name and

continues. After a few minutes, each student has been called. Mr. Tao taps the “Submit Attendance”

button on the screen and sees a summary page displaying each student's status grouped by “present”,

“absent” and “late”. Upon evaluating the page, he realizes that he had accidentally marked Brian as

absent. He presses the “Modify” button next to Brian's name and marks off “present” this time. Mr. Tao

presses the “Update Attendance” button at the bottom of the page and begins his lecture on binary

heaps. As jeers of disdain fill the room, Joseph stumbles in. Unfortunately, Joseph is late. He looks at

Mr. Tao and feels a set of eyes begin to burn into his soul. Mr. Tao stops his lesson, picks up the EAP

and asks him for his reason for lateness. Mr. Tao taps on the “Modify” button and then checks off

“late” next to Joseph Yeung's name. Joseph takes his seat and class continues.

Scenario 2

It is a Monday afternoon at Greenwood Public School. A storm looms in the distance while all the

students are busy learning. Joanne, the vice-principal, is one such individual and is currently dealing

with the issue regarding wine being served at last month's student dance. She takes a second to look at

the surveillance video of the school's exits, and notices something out of the ordinary. She sees an

unidentifiable man enter the school concealing something in his jacket. With the possibility of it being

a weapon, she announces over the intercom, “Attention, code red lock down. I repeat, code red lock

down. This is not a drill.”

Mrs. Reynolds, hearing the announcement glances at her EAP and sees that all the on screen buttons

had changed colour to red and also sees a flashing lockdown warning message. She immediately goes to

close the door, but as she does so, little Angus runs in. She then locks the door, closes the blinds and

urges Angus and her class to sit quietly in a corner of the room. She grabs the EAP and quietly joins the

rest of her class in the corner. Mrs. Reynolds takes out the stylus and begins to retake the attendance.

All but one of her students, Dave, is accounted for. For each of those present students, she taps the

button labelled “present” beside each name. For the missing student, she taps the “missing” button

next to their name. Before she finishes, she remembers that little Angus is in her room now and needs

to be signed in. Mrs. Reynolds presses the “Adopt a Missing Student” button, takes out the keyboard

and enters his student number. Angus' name appears immediately on her class list as “Adopted”. Once

finished, she confirms her choices and waits. Moments later, Mrs. Reynolds receives a notification that

her student, Dave, has been adopted by another teacher. This message appears as a log entry in the

Notifications Bar and as a large pop-up on the screen. She taps the “Okay” button. With her heart at

ease, she sits quietly with her class. 10 minutes later, the lockdown situation ends. All is well.

Rationale

Based on the feedback we received from our three designs in G3 as well as our initial field work in G1

and G2, we re-evaluated our requirements. Keeping what we‟ve learnt from our users in mind, we

made a number of decision designs.

All four testers responded positively to the static GUI frame and the unobtrusive notifications in the

third design. Given the GUI, all their controls were accessible in one click. The notifications gave

system feedback as a history log of what the users have been doing. We‟ve kept both of these features

in the final prototype design.

Since scrolling with the stylus is difficult, we use „next‟ and „previous‟ buttons to navigate between

attendance pages. If the system displays an unexpected class list (e.g. due to classes being switched

around), the user is provided with a GUI frame (taken from Design 3 in G3) that will enable them to

switch between periods in one click. „Back and „Forward‟ are addition navigational aids. „Class Label‟

gives the teacher more information than just „Period‟.

Although the current Trillium system provides a way for the teacher to access student photos, it is

detached from the attendance sheet, and can only be accessible on the computer. Combining it with

the class list will help teachers remember student names quicker. It is also a tool that will help supply

teachers identify students in the class for which they are substituting.

In G1, we saw that the machine-readable class list displayed a list of student names. Beside each

student were 5 sets of 3 bubbles—for each school day there were bubbles for „present‟, „late‟, and

„absent‟. By design, teachers were required to fill out the right bubble to indicate a student‟s

attendance for a specific day of the week. Sometimes, the bubbles were filled in incorrectly. Other

times, they were filled in under the wrong day. Both of these events cause inaccurate records.

Replacing bubbles with its electronic counterpart (i.e. radio buttons) simplifies the filling process.

Furthermore, the automated timestamp capability of a digital system enables us to remove the clutter

of having 5 sets of input for student attendance.

To assist teachers in taking accurate attendance even further, we colour coded the radio buttons. We

mapped „present‟ to green, „late‟ to orange, and „red‟ to absent. This allows the user to formulate a

visual model of the attendance.

As mentioned in G3, replicating the existing attendance sheet minimizes the learning curve of the

teachers by providing them with a familiar interface. By the same token, interacting with the EAP with

a stylus is analogous to interacting with paper attendance with a pen. All gestures and tasks are the

same. We are simply changing the instruments with which the tasks are performed.

Taking paper attendance does not require the user authentication. However, in order to ensure data

integrity in a digital system, we need to protect it against unauthorized manipulation. Unfortunately,

this introduces and inconvenience to the user. It will be a hassle to log in whenever a student staggers

in late. As a compromise, the system logs out automatically only after 10 minutes of inactivity.

A key requirement that was identified in our research is the need for silent communication during

emergency situations. To coordinate with emergency procedures, we allow the administration to send

global announcements to all teachers. With the goal of having a central hub of information, everything

goes through the administration office and is redistributed again if necessary.

For example, notifying the administration office and the responsible teacher of a student‟s adoption

keeps all concerned parties on the same page.

Teachers may contact the administration office, but not other teachers. The „Contact‟ button is static

on the GUI frame so that teachers are aware of this feature even under normal use. The GUI is

intentionally the same under normal and emergency use so that users would not have to refamiliarize

themselves with a new interface, especially under such stressful circumstances.

Evaluation Plan User testing is a critical phase in the design process. The purpose of our research is to gain user

feedback on our proposed Electronic Attendance System (EAS). We hope to understand what users like

or dislike about our system. From here we can see whether the design meets the requirements.

Through the use of paper prototyping combined with a physical mock up of the device we will give the

users a hands-on feel for our system. Our ideal testers will be teachers in elementary and high schools.

We will also use experts in the Human Computer Interaction (HCI) field. We will be visiting various

schools around the Greater Toronto Area to gather user feedback.

Using a script, we can perform a structured interview with the teachers. With a controlled test such as

this, we will be able to compare how different users carry out the same specific tasks.

After reading out the instructions we will observe how the user chooses to interact with the device in

order to carry out the actions. While the user is carrying out the tasks, he is encouraged to talk out

loud and voice his intentions, especially when he is having difficulties. This will allow us to better

understand their thought process and see the interaction from the user‟s perspective.

With their permission, we will run the users through two different scripted scenarios:

The Daily Attendance

This scenario will reflect the average school day in the teacher‟s life. The teacher will take attendance

while we play the part of the student. After inputting the attendance record, they will “realize” that

they have marked one of the students absent incorrectly. They then will navigate to the correct screen

and correct it. After they log out, another student will walk into the classroom late. According to the

attendance that student needs to be marked as “absent”. The teacher then updates the attendance

and logs out.

The Emergency Attendance

This scenario will reflect the attendance component of an emergency procedure. As the school goes

into lockdown mode, the teacher will take the EAP and direct the students to a location away from

doors and windows. A student that was previously wandering in the corridor will rush into the

classroom before the doors are locked. The student is then adopted by the teacher. As the teacher

takes the attendance, he will notice that one of his students, “Brian Shim,” is missing. Luckily, Brian is

accepted into another classroom. An alert will pop up to notify the teacher that Brian has been

adopted. Afterwards, one of the teacher‟s students will reveal that they have injured their leg. The

teacher uses the EAP to communicate silently to the main office for help.

After the scripted scenarios, the users will be asked to fill out a questionnaire and complete an

interview with more open ended questions.

Summary

Requirements Modification

The user feedback in previous steps of the design helped up to come up with a strong set of

requirements.

There are no additional requirements changes. To sum up the existing requirements: the main purpose

of our system is to provide a way of taking the attendance in both regular and emergency situations in

an efficient and effective manner. We measure efficiency with accuracy of student attendance

records. By designing the system so that mistakes are hard to make, we minimize the occurrence of

inaccurate records. A clear and easy-to-use method of communicating information is still a key

requirement. The system must be easy to use and require little or no training. In the event of an

emergency, the system must be lightweight and portable with adequate battery life.

The focus at this stage is to better our design and ensure that we fulfill all of the current

requirements.

The Design and Implementation Process

Initially we developed 3 different interface designs with varying hardware implementations. After

reviewing the different prototypes with user feedback, we were able to refine the product to include

the strongest aspects.

Using a series of paper prototypes and physical mock-ups we were able to make adjustments to the

physical feel of it. We tried our best to create our prototypes as close to what the real thing would be

like. Designing the panel was a meticulous procedure and we faced many implementation challenges

along in the process.

Some concerns were brought up about the weight of the panel. Since the weight that each person can

carry comfortably varies, we conducted several tests with varying weights to find a suitable weight.

The size of the panel had to be taken into concern as well. We needed to have a screen large enough

to display long class lists and not restrict portability. We started off with the standard letter size, and

envisioned it to be balanced on the forearm when held. Tests were conducted with participants

holding objects with similar shapes to our panel with varying lengths.

Finding an appropriately sized keyboard proved to be difficult as many were too big for the panel, and

those with smaller designs were difficult to type on.

With the paper prototypes, even though we tried to keep it as realistic as possible, there were a couple

features which we just could not show in the paper prototype. Features such as scrolling and onscreen

button press feedback (As the user presses a button, the button is virtually depressed) had to be left

out of the paper prototype.

Even with all the challenges along the way, we were still able to use the prototype to gain valuable

user feedback to polish our design.

By combining the powerful interface of the keyboard implementation, the familiarity of the stylus and

the simplicity of the touch screen, we believed we‟ve come up with the ideal design. However, we will

have to see how it holds up against user testing

Who Did What?

Name Tasks and Time Taken Total Estimated

Time Spent

Victoria Mui - Prototype Design and Creation (10 hours) - Data collection (interviews etc...) (3 hours) - Editing (3 hours) - Organizing appendices (1 hour) - Scheduled prototype testing with schools (1 hour) - Requirements Summary (1 hour) - Organizing Final Project (4 hours) - Taking Pictures (1 hour) - Storyboards and write-up (4 hours)

28 hours

Brian Shim - Prototype Design and Creation (5 hours) - Protocols (2 hours) - Data collection (interviews etc...) (1 hour) - Implementation Problems (2 hours) - Designed Scenarios (4 hours) - Physical Prototype (without scenario) (2 hours) - Editing (3 hours) - Taking Pictures (1 hour) - Responsibility Breakdown (1 hour)

21 hours

Veronica Wong

- Prototype Design and Creation (12 hours) - Data collection (interviews etc...) (3 hours) - Scheduled prototype testing with schools (1 hour) - Editing (3 hours) - Scheduled prototype testing with schools (1 hour) - Photo Editing ( 2 hours) - Project Description (1 hour) - Taking Pictures (1 hour) - Design Summary (2 hours)

26 hours

Joseph Ng Chow

- Prototype Design and Creation (5 hours) - Data collection (interviews etc...) (3 hours) - Editing (3 hours) - Implementation Problems (2 hours) - Minute taker at meetings (1 hour) - Taking Pictures (1 hour) - Evaluation Plan (3 hours)

18 hours

system prototype and evaluation plan

Documents