HCI IXlab Paper

7/29/2019 HCI IXlab Paper

1/8

UX Lab Scheduling & Information:A Multi-touch Browser Application

Nicholas Huba, Caris Hurd, Addison Martnez, Cary-Anne Olsen

The University of Texas at Austin School of Information1616 Guadalupe St.

Austin, TX 78701 USA[nicholas.huba, caris, addison.martinez, cary.anne]@utexas.edu

ABSTRACT

This project explores the design and development of a

public touchscreen application for the School of

Information at the University of Texas at Austin. Theinstallation of a touch screen computer in a public place

prompted inquiry into its use as a resource to efficiently

relate information about the adjacent usability lab. User

profiles identified key features and informed design

guidelines. The design and features were validated through

observation and usability testing with a developed

prototype. Results showed that the touch-enabled webapplication met basic user requirements, but that there is an

opportunity to optimize the user experience. This paper

provides information on designing a public touchscreen

application and suggests areas for future development.

Author Keywords

Public kiosk; user interface design; information display;touch screen; scheduling system; study fliers; advertising;

iSchool; interaction design

ACM Classification Keywords

H.5.m. Information interfaces and presentation:Miscellaneous; H.3.5. Online Information Services: Web-

based services

General Terms

Human Factors; Design.

INTRODUCTION

The School of Information (iSchool) at the University ofTexas at Austin had installed a touchscreen monitor on a

wall outside the Interaction eXperience Lab (IX Lab) (see

figure 1). The touchscreen was meant for use by the staff

and students at the iSchool in their interactions with the IX

Lab.

This project of constructing a browser-based application for

the touchscreen was conceived as a means to utilize this

touch-enabled hardware to reach the following goals:1. Convey information about ongoing user studies to

passersby in the iSchool for the purpose of general

awareness and recruitment2. Allow researchers at the iSchool another means

for requesting reservations of the lab

3. Convey general information about usability andthe lab to interested parties

Figure 1. Touchscreen display mounted on hallway wall

outside IX LabThe plan put in place to reach these goals involved

developing a web application that had frequently asked

questions, advertisements for studies, and the ability to

request a time to reserve the lab. This paper describes the

literature on kiosks, digital poster systems, touch interfaces

and other relevant topics; then it describes the design

process, implementation, and user testing of the prototype.

BACKGROUND

Public Information Displays

It has been shown that when using interactive displays in a

public or social space, it is important for users to feelcompetent and able to engage with the display without

needing help or feeling self-conscious when in a socialspace [3,7,8]. When interacting with a screen in front of

colleagues or in public, the physical and social setting

become a large part of the interface to the consumption of

content and make reading a social activity. An iterativedesign process to refine the usability and user experience of

the system becomes an important way to ensure that users

are comfortable and confident using the system.

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copies

ear this notice and the full citation on the first page. To copy otherwise,

or republish, to post on servers or to redistribute to lists, requires priorspecific permission and/or a fee.CHI

Copyright 20XXxACM xxx-x-xxxx-xxxx-x/xx/xx...$x.xx.


2/8

Another aspect of reading on a public display is thatinteractions with the screen can become driven by who is

watching as much as the usability of the interface [3].

Giving users the opportunity to send content or information

from the screen to their private e-mail for consumption at a

later time becomes important for facilitating contentconsumption in a more private space.

For a system on display in a public area in an office, it has

been found that users want more information about the

office available on screen and for there to be more action

on the front page with dynamic display of text and

information [6]. Having a graphic-heavy default mode as

well as organizational information available is important.

Similar touch displays have been deployed at the School of

Information Sciences at the University of Pittsburgh that

facilitated information sharing among their users as well as

recommendation functionality [18].

Informative Kiosks

Borchers et al. suggest several functions for which kioskscan be used including as an information kiosk, providing

information in a limited subject field; a service kiosk,

where users input information into the system; and an

advertising kiosk, presenting information to the public in a

compelling way [1].

Borchers et al. found that information kiosks should have

pages laid out clearly, so that customers do not have to use

the system longer than necessary [1]. For advertisingkiosks, they recommended that the content should be

interesting and entertaining to compel the user to explore

the content further. Graphical elements should dominate the

layout with only as much text as necessary. For service

kiosks, the authors acknowledge that a virtual input device

like an onscreen keyboard is less than ideal, and theysuggest that designers need to make clear what information

the user is supposed to enter in a dialog to minimize

frustration.

Ju and Sirkin show that getting users to touch a public

kiosk or touchscreen is a design challenge. One optionshown to work is using motion and physical signage to

catch the users eye and prompt them to interact with the

system [9].

Resource Reservation Systems

There are quite a few web-based room or resource

reservation systems that have been created independent of

touch functionality. One example is the resourcereservation system used by the Texas Advanced ComputingCenter (TACC) to reserve rooms and computing resourcesassociated with their Visualization Laboratory [19]. Thissystem uses the Google Calendar API and a web form for

users to request resources. Another example of a web-based

scheduling system is the University of Texas at Austin

Libraries system scheduler, which allows users to reserve

space at the library using a web interface [20]. Fewer

examples exist of touchscreen interfaces for scheduling

software, but Asure Software has designed a system to bedeployed on LCD touchscreens located throughout an

office [21].

All of these systems featured a monthly, weekly, and daily

view of the calendar, allowing the user the ability to choose

which visual interface they are most comfortable using.Additionally, the daily view of the calendar on each system

had each day divided into 30-minute increments, to

facilitate easy room reservation.

Each reservation system showed how to handle multiple

events on the same day: as long as the events did not

overlap in the reservation times, there would be no issue

with multiple requests. The visual nature of the interface

simplified this process, clearly demonstrating when

reservations would overlap.

User Interface Elements

Several previous studies informed the design of the

application we built. We identified several interface areas

that needed attention: buttons, scrolling, text animation, andonscreen keyboards.

Fitts Law predicts that the speed and accuracy of users isdirectly correlated with the distance to and size of the target

that they are trying to reach with the cursor [4]. Examples

of this are elements such as a button or scroll bar.

MacKenzie found that, when testing Fitts Law on a

touchpad, users need buttons to be larger in order to

minimize selection errors [11]. Without the advantage of

the mouse cursor, which is much smaller than the average

size of an index finger, it is much easier for users to

accidentally select the wrong item when using atouchscreen system. Team members who had experience

with Web design in the past were surprised by how muchlarger buttons needed to be for touch applications than they

do for the Web.

Fitts Law also affects scroll bars on a touchscreen

interface. Norman discusses the history and change in

scroll behavior in light of the advent of touchscreen

interfaces [12]. Up until touchscreens, when a user gestured

downward for scroll with the mouse, it moved the content

on the screen upward. Now, with the physical interaction of

a touchscreen, this model no longer works and users expect

the downward scroll to move content down.

Zellweger et al. state that smooth animations for hiding and

showing text help the reader[s] distinguish those parts that

are changing, and must thus be read anew, from parts that

have not changed [17]. Smooth open and close animationshelp with readability and prevent disorientation. We

worked to make the application interface as smooth aspossible with the jQuery Mobile JavaScript libraries.

The final important UI element was for users to be able totype on the screen, since there would not be any physical

keyboards available for this kiosk. Sears found that

novices can type approximately 10 word per minute(WPM) on the smallest [touchscreen] keyboard and 20


3/8

WPM on the largest [15]. Thus, the larger we could makethe onscreen keyboard, the faster users can type in their

information.

DESIGN PROCESS

User Perspectives

We developed three primary roles, or types of people, that

would likely interact with the interface: researchers,

possible participants, and curious passersby. Each role

brought with it a unique set of perspectives and needs thatinformed what features, constraints and visual elements

were considered in designing the application.

Researcher

We hypothesized that researchers would be the ones most

likely interested in interacting with information about thephysical lab. Information regarding the current availability

of the lab would help researchers determine if the labs

facilities were available to deal with an unexpected need or

problem. The ability to view future availability of the lab

could reduce scheduling conflicts among researchers. Uponconfirming the availability of a particular time, researchers

would want the convenience of reserving the labimmediately through the application, instead of requiring

them to use the existing alternate means such as e-mail or

phone.

Having the option to advertise currently running studieswould also be of interest for researchers. Displaying digital

fliers could assist with participant recruitment and also

promote general awareness and interest of the researchers

work.

Possible Participants

A person interested in participating in a research study was

another role that was considered. Possible participantswould want to easily view and evaluate the many studies

available for participation. These users would need to

quickly and easily view detailed information about each

study. Specific information should be available to assist

people in determining whether or not they wish to

participate in the study at all. Information regarding thestudys purpose, what participants will be asked to do,

requirements for participation (like a specific age range or

experience with a particular product), and whether there is

compensation, are all important considerations for selecting

a study to participate in. Logistical information, such as the

name and contact information for the studys researcher arenecessary to allow possible participants to find out how to

contact the person running the study.

Curious Passersby

This role is comprised of people that currently have had no

prior experience or interaction with the application or the

IX Lab. The primary goal of users in this group would be to

gain an understanding of what the touchscreen was andwhat it was used for.

Providing easily accessible answers to questions users

might have, such as a brief introduction to the concept of

usability and the capabilities of the IX Lab, would beneeded. Describing the features available in the application

and how they are used would also be needed.

Users in this group posed a unique obstacle with regard to

design. The other two roles presented already had a prior

set of needs that motivated them to interact with theapplication. This group has no clearly defined reason for

needing to interact with the application at all. This requires

the design to include methods to not only attract attention,

but also to provide reasons for why an individual would

want to explore the application. This role was the most

mutable of the three created. It is quite possible that

someone completely unaware of the application could

quickly become a possible participant or even a researcher.

Goals

General Interface

Certain constraints were imposed by the size and placement

of the input device as well as limitations with the

interfaces hardware, that dictated a few decisions that

affected the overall approach to design.

With the touchscreen mounted vertically on a wall,traditional mechanisms of inputting data would be

cumbersome at best (see figure 1 for photo of vertical

mounting in hallway). This is particularly true for any taskthat involved free text entry. Interacting with a touchscreen

keyboard can already be difficult for many reasons. Itsinability to allow users to rest their fingers on the home

row keys (since any contact is interpreted as a keystroke)

means that users must constantly hold their fingers above

the keyboard increasing wrist and hand fatigue. A touch

keyboards limited capability for tactile feedback can slow

users typing speed as well as increase typos as they cannot

feel when a fingertip is on the border between two keys. All

of these issues are compounded by the fact that theinterface is not in the more common, horizontal position.

The touchscreens sensitivity and input interpretation wasalso a concern. The touchscreen would sometimes not

respond to an initial screen tap and required a second, or

even third, attempt before responding. The touchscreen also

had trouble with precision, sometimes sensing a touch aquarter to half an inch away from where the user perceived

the touch was placed.

In an attempt to address these issues (which would be

omnipresent, regardless of what aspect of the application

was being used), strict guidelines were placed on the design

of any element in the system. Text entry through akeyboard would be allowed only if no other method couldbe used to achieve the same result. This limits the amount

of time a user needs to spend interacting with the

application using an uncomfortable and frustrating input

method. Large swipe commands, such as using a finger to

swipe left and right to navigate between screens, would be

the primary method of interacting with the interface. This


4/8

Figure 2. A wireframe of what the system would display when a user clicks on the Request a Room button

would help compensate for the unpredictable precision

issues inherent in the systems hardware. Broader,

movement-based commands reduce the need for the users

finger to hit a specific target such as a button or scrollbar.

Reserving the Lab

The process of reserving the lab was broken down intosmaller elements to better understand what was required to

achieve the desired goal.

Since the primary aspect of scheduling involves the use of

time, a calendar view was an obvious choice for the

Reservation page of the application. This view provides anefficient method of presenting the user with the informationneeded to inform the next step in the reservation process

(see Figure 2). With the IX Labs reservations already

being tracked in a Google Calendar system, it seemed

appropriate to integrate Googles system instead of

unnecessarily developing a completely new calendar

system.

Being able to determine on what dates and times the lab is

available in the near, as well as further in the future, allows

the user to plan accordingly. The option to change thecalendars view to display reservations that are weeks, or

possibly months, in advance, is needed. This is not only

valuable for planned events but also for opportunistic needsas well. Swiping left or right on the calendar would

advance the view backwards and forwards in time based on

the currently selected time increment (day, week, month).

Should a researcher have a need to use the labs facilities

for an unexpected or impromptu reason, knowing the

detailed timetable for the lab would be useful. It might be

possible that the lab is currently unoccupied and, therefore,

available. However, the lab may be scheduled for use by

another researcher in the next 10 or 15 minutes, making it

impractical to reserve the lab at that moment.

After confirming that the desired times are not in conflict

with the reservations already in the system, the user can

then move on to requesting their own reservation. Specific

pieces of information are needed to make this step in the

reservation process successful. There are several data

requirements such as the date and how long the lab is going

to be reserved (start and end time). The method forselecting the date and time will be through the use of

flipboxes (see Figure 3). These input elements onlyrequire the user to swipe up or down in distinct lists to

create a complete date or time (month, day, year and hour,

minutes, AM/PM). These inputs do not require multiple

precise taps to enter information, reducing errors from

either awkwardly positioned hands or unreliable hardware.

In order to prevent users from abusing the system, such as

reserving entire weeks in the lab, a human moderator needs

to be involved in the reservation approval process. This

communication exchange dictates that requesters must

identify themselves and provide a way for the lab

moderator to contact them (email address). These two textinputs are the only ones in the system that use the touch

keyboard. Due to the unique nature of names and emailaddresses, a complete range of letters and characters needsto be accessible.

To inform the researcher that their reservation wassubmitted correctly, the system provides two forms of

feedback. The first is a simple dialog window that appears

after the submit button has been pressed that lets the user

know that the form was filled out correctly and that the

information was sent on. The second form of feedback is


5/8

that the requested reservation appears on the calendardisplayed in the application. The reservation is placed in

the exact date and time requested along with the requesters

name. The text - Under Review appended to the

reservation to distinguish it from other calendar entries that

have been approved by the lab moderator.

Figure 3. The user sees a flipbox with the months, days, and

years available.

Reviewing Studies for Participation

Only a small number of tasks and elements were required

to best facilitate the process of searching for and selecting a

study to participate in. Users would need to be able to

quickly browse through the available studies and view

important information on each study with ease.

All of the studies advertised in the application are capable

of being viewed on the Studies page. A vertical list

contains images of the fliers submitted by researchers.Users can browse through these fliers by swiping up and

down in the list. A larger image of the flier is displayed in

the middle section of the screen when it is selected in the

list. Since there are many uncontrollable factors involved indisplaying an image (size, resolution, contrast, color,

format, etc.), important information can be difficult to find

using the flier alone. Metadata for the study, provided by

the researcher when the flier is submitted for posting, is

displayed on the right side of the screen. This insures that

data, such as the researchers name and contact

information, is easily seen and not lost in a poor qualityflier. This data could also include other points-of-interest

for possible participants like study requirements or if

compensation is offered.

Learning About Usability and the Touchscreen Application

The approach to this screen, the FAQ page, focused on

providing answers as quickly and easily as possible. All theinformation and answers provided by the application

needed to be concise to avoid the need to scroll. Long,

detailed descriptions or instructions take time to read.

During this time, users might become tired or restlessbecause of the need to stand or reach their arm up and

touch the screen to navigate through the text. Smaller,clearly understandable categories allow users to locate the

information they are looking for without having to scan

through long blocks of text.

Collapsible stretch text or an accordion-style menu

system seemed the most appropriate choice for this screen.This accordion menu contained a list of possible questions

first-time users might have. Tapping on the question

expands the menu, revealing a short answer. Selecting

another question causes the previously opened section to

close, allowing only one answer to be displayed at a time.

This clearly distinguishes which answer is associated with

which question. This functionality also keeps the interface

from becoming cluttered and growing longer. If the menu

were not constrained, it is possible that it could becomelarge enough to start displaying content outside of the space

provided, causing the user to have to scroll to see all of the

content.

Attracting Attention

The need to attract the attention of those individuals that

have no prior experience with the application was a highpriority. An effort was made to design a system that was

easy enough to use without the need of any training or

demonstration. It should also be able to communicate its

touch capabilities autonomously.

Another major challenge was distinguishing the interface

from other digital signage located in the building, which

does not have touchscreen capability. Leaving the interfaceon the calendar display would give a clear and obvious

indication that it was not simply a sign. However, thiswould reveal only one part of its functionality and people

not interested in reserving the lab could interpret it as only

a room management application. Similar assumptions could

be made if any of the other screens were the defaultdisplay.

Another problem stemmed from using a single, static

display. A user must know that studies are advertised in the

system and must actively browse through them to

familiarize themselves with all of the ones available.

We decided that a horizontal, scrolling screensaver mode

where the different study fliers would slide in and out of

view when the application was not currently in use. Thiswould provide motion to the interface that would help

attract the eye. All of the available studies would have the

opportunity to be passively introduced to anyone walking

by.To set it apart from the non-interactive, digital signage and

to encourage users to explore the application, we created atranslucent box in a fixed location on the screen with the

text Touch Screen to Begin that displays when the screen

is in the screensaver mode.

Visual Design

Much of the visual design inspiration was drawn from the

Mac iOS touch devices, which rely on bottom navigation


6/8

and swipe events to navigate the system. The mainchallenge in building on that set of ideals is that this

touchscreens resolution is much higher than the iOS

devices, and the widescreen aspect ratio is wider than most

iOS touch devices. Thus, the balance of filling the screen

with relevant information and leaving enough white spaceto maintain legibility was a challenge of the design process.

DEVELOPMENT PROCESS

Technology Environment

The touchscreen has a resolution of 1920x1080 pixels. The

web application was designed and coded to fit this size.

The goal for each section, except the Studies page, was that

the content would fit the screen without the need to scrollto see all content. On the Studies page, we built a vertical

carousel for users to get to the relevant content without

having to scroll on the rest of the page.

The computer that drives the touchscreen runs a Windows

7 operating system with several browsers installed (Internet

Explorer, Firefox, Google Chrome).

We initially tried the application using Chrome, but it

performed the worst of the three installed browsers. Thetouch sensitivity was low, and if a user tapped on a form

field to enter data, the onscreen keyboard would not

display.

Next we tried using Firefox, and the touch sensitivity was

higher, but we had the same onscreen keyboard issues as

Chrome.

Internet Explorer 9 integrates touch events most smoothly

of all browsers installed, so this was initially selected as the

primary browser for the system. However, after integrating

functionality into the code, we found Internet Explorer didnot pass all of the variables needed in the timeOut function

for the screensaver mode. The screensaver mode advertisedcurrently running studies to passersby, and was a key

component of the end product.

At that point, we reverted to using Firefox because thescreensaver mode worked well and the on-screen keyboard

issues we encountered initially had been resolved.

Because our application is similar to a kiosk, which is

oriented toward one person interacting with the screen at a

time, and has simple interaction requirements, we agreed

that creating a multitouch interface would be beyond the

needs of any individual user.

During our early system testing phases, we found we were

accidentally zooming in or out on the page by usingdragging gestures, and were unable to return to the desired

state. If a user unintentionally zoomed, it could interferewith subsequent users if those settings were not

automatically reset. Thus, we disabled the browsers

zooming functionality.

Because the IX Lab managers were already using Google

Calendar to keep track of who was on the schedule for

using the room, we chose to develop that portion of theapplication using Google Calendar.

Code Implementation

While none of the team members had experience

developing native apps, there is increasingly less reason to

do so, as JavaScript libraries are getting faster and

matching functionality [2]. Our team chose jQuery

specifically because it is, as stated on their website, ... afast and concise JavaScript Library that simplifies HTML

document traversing, event handling, animating, and Ajax

interactions for rapid web development [13].

We also chose to code this as a web application for easier

integration with the IX Labs existing web presence, and

because all team members had experience with HTML. Wewrote the app using HTML5, CSS3, jQuery Mobile 1.1.0,

the Google Calendar APIs and PHP [10,13,22].

We specifically chose jQuery Mobile [14] because it is a

framework specifically created for touchscreen interactions,

and one of the team members had prior experiencedevelopting with jQuery Mobile. It also leverages the use

of HTML5, which assured that our application would becreated with the most advanced technology currently

available.

Once the jQuery library was installed, we added in

JavaScript libraries to create the draggable vertical carousel

of study posters [16] and the screensaver mode [5].

The process of integrating Google Calendar with the

application presented several problems. The primary

problem was that the functionality offered by the Google

Calendar API was very limited. Only simple additions anddeletions to a single calendar and retrieving all events

stored in a calendar as a single XML file were possible.

With no other way to display the calendar, an HTML

iframe was used to link the application with the labs

Google calendar. This concession severely restricted the

functionality of the calendar. The displayed calendar onlyworked with tools and commands native to Google

Calendar and no custom actions were allowed. This meant

that touch events could not be mapped to the calendar

(swiping left or right to change months or tapping on a day

to submit a reservation).

The API did permit changes to be sent to the calendar fromoutside source via custom PHP commands. Data collected

in the Request a Reservation form was captured,

formatted and sent to the lab calendar. During this processthe text - Under Review was appended to the request and

displayed next to the requesters name in the created

calendar event.

As another function of the forms submission, the lab

moderator is informed via email that a request has been

made. All of the data collected in the form (name, email,

date, start and end time) is entered into the body of anemail that is sent to the lab manager. This alerts the lab


7/8

manager to review the reservation and determine if it isappropriate or not. Should the request be approved, the

manager removes - Under Review from the event and

emails the requester of the approval.

Due to time constraints, we were unable to implement a

robust method of storing and managing the metadataassociated with the individual studies advertised in the

system. It was intended that each study submitted for

advertising would have its metadata entered into a database

or a third-party content management system. Time

constraints forced us to represent this feature as hard-coded

data in the HTML instead of dynamic variables retrieving

the data from elsewhere.

USABILITY EVALUATION

Recruiting

Participants were recruited from the population of students,

faculty, and staff at the iSchool. These users were recruited,as they would be potential users of the system as

participants, researchers, and passersby.

Usability Test Design

Each test consisted of a brief pre-test interview, three shortusability tasks, and a post-test interview.

For the pre-test interview, we asked users if they werestudents, faculty, or staff of the iSchool. We also asked

them what type of experience they have had with the IX lab

in the past as a researcher, participant, or if they had no

prior experience. We also asked them for their general

impressions of the system before they touched the screen to

try to understand if the fact that the system was atouchscreen would be intuitive for passersby.

The tasks we asked participants to complete were:

1. Find a time to conduct a user test in the lab onMay 10th and request a reservation at that time.

2. Find a study that you might want to participate inand find the contact information for the researcherconducting the study.

3. Find out which classes you could take to learnmore about usability.

The post-test interview served to ask the participants what

they liked, disliked, and what they would change about the

system.

Test Results

Pre-test Interview

Of the five participants we recruited, two had served as

participants in IX Lab research in the past, one had

conducted research in the lab previously, and two had no

experience with the lab either as a participant or a

researcher.

Before starting the test, users were asked their general

impressions of the system when it was in the screensaver

mode. Three out of five users said that they thought it was a

touchscreen. Two said that they would not have been surethat it was a touchscreen. An optimization we made as a

result was to add a translucent box on the bottom right ofthe screen that says Touch Screen to Begin. This box

only displays when screensaver mode is active.

Task 1: Find a time to conduct a user test

Starting from the main screen, all users were able to find

the reservations screen. Four out of five users (80%) then

touched the date on the calendar to try to reserve it, but the

system did not support this. All users were able to find the

button to request a reservation and pull up the form.

All users were able to fill out the form successfully.

However, all users had trouble with the date and time

selectors. The selectors did not respond very well to touch

input and did not have good indicators of which item wascurrently selected in each field. Two users (40%) asked for

the ability to see the calendar so that they could judgeavailability while filling out the request form.

Task 2: Find a study that looks interesting to participate in

and find the contact information for the researcher

All users were able to find a study and the contact

information for the researcher. Two users (40%) wanted the

ability to send this information to their own e-mail from theinterface. One (20%) wanted to send an e-mail from the

interface to the researcher to express their interest in

participating.

Task 3: Find out which classes to take to learn more about

usability

All users were able to complete this task successfully

without any trouble. One user (20%) said that the page

would be better with a larger font and a shorter line length.

Post-Test Interview

In the post-test interview, two of the users (40%)

mentioned that it might be helpful if the navigation links at

the bottom of the interface were in a larger font and werelarger buttons. One user (20%) suggested that we add icons

to the area to make it clearer what each page did. Two of

the users (40%) reiterated that the mechanism for selecting

date and time on the reservation form was exceedinglydifficult to use and requested that this interface be

improved.

CONCLUSIONS: IMPLICATIONS AND FUTURE WORK

As designed and coded, the application meets the basic user

requirements of students and faculty at the iSchool. It grabs

the attention of passersby, disseminates information about

the IX Lab, and encourages involvement with the lab as a

potential participant and researcher. The application

facilitates communication between researchers andparticipants through the context of the IX Lab, supporting

more efficient use of the lab and its resources. This paperexplains the development and design processes of a public

touchscreen application.

Opportunities to improve the immediate user experience

are based on our findings from usability testing. Future

iterations of the web application should include more touch

functionality to allow users to touch or drag across the date


8/8

and time that they want to reserve, rather than making themuse date and time selectors to fill out the request form.

Layout of the stretch text displayed on the FAQ page could

be optimized for readability by increasing font size and

decreasing line length.

Future work may include user-generated content postingfunctionality either through email or direct manipulation.

Modifications to the standard jQuery Mobile library could

be implemented to allow both the calendar and reservation

form to simultaneously remain in focus. Enhanced features

such as an ambient display informing current room usage

status might be added. The screen could also be moved to a

more prominent area of the building, or a second screen

could be added to create a network of screens to promote

this type of content sharing and functionality. Extendingfunctionality to allow information to be shared via email or

pushed to a mobile device would further refine user

experience.

REFERENCES

1. Borchers, J., Deussen, O., and Knrzer, C. Getting itacross: layout issues for kiosk systems. SIGCHI Bull.

27, 4 (1995), 6874.

2. Charland, A. and Leroux, B. Mobile applicationdevelopment: web vs. native. Commun. ACM 54, 5

(2011), 4953.

3. Churchill, E.F., Nelson, L., Denoue, L., Helfman, J.,

and Murphy, P. Sharing multimedia content withinteractive public displays: a case study.Proceedings

of the 5th conference on Designing interactive

systems: processes, practices, methods, and

techniques, ACM (2004), 716.

4. Fitts, P.M. The information capacity of the human

motor system in controlling the amplitude ofmovement.Journal of Experimental Psychology:

General 121, 3 (1992), 262269.

5. Grakalic, A.Easy Slider 1.7. .

6. Houde, S., Bellamy, R., and Leahy, L. In search of

design principles for tools and practices to supportcommunication within a learning community. SIGCHI

Bull. 30, 2 (1998), 113118.

7. Izadi, S., Brignull, H., Rodden, T., Rogers, Y., and

Underwood, M. Dynamo: a public interactive surface

supporting the cooperative sharing and exchange of

media.Proceedings of the 16th annual ACM

symposium on User interface software and technology,ACM (2003), 159168.

8. Izadi, S., Fitzpatrick, G., Rodden, T., Brignull, H.,

Rogers, Y., and Lindley, S. The iterative design and

study of a large display for shared and sociable spaces.

Proceedings of the 2005 conference on Designing for

User eXperience, AIGA: American Institute of

Graphic Arts (2005), 59.

9. Ju, W. and Sirkin, D. Animate objects: how physicalmotion encourages public interaction.Proceedings ofthe 5th international conference on Persuasive

Technology, Springer-Verlag (2010), 4051.

10. Lerdorf, R.PHP: Hypertext Preprocessor. .11. MacKenzie, I.S. Fitts law as a research and design

tool in human-computer interaction.Hum.-Comput.

Interact. 7, 1 (1992), 91139.

12. Norman, D. Gesture Wars. Core77 / industrial design

magazine + resource / home, 2011.http://www.core77.com/blog/columns/gesture_wars_2

0272.asp.

13. Resig, J.jQuery. 2012.

14. Resig, J.jQuery Mobile Framework. jQuery.15. Sears, A.Investigating touchscreen typing : the effect

of keyboard size on typing speed. University of

Maryland Center for Automation Research ComputerVision Laboratory, College Park Md., 1992.

16. Sorgalla, J.jCarousel. .

17. Zellweger, P.T., Mangen, A., and Newman, P.

Reading and writing fluid Hypertext Narratives.Proceedings of the thirteenth ACM conference on

Hypertext and hypermedia, ACM (2002), 4554.

18. Zhang, S. and Jeng, W. Designing a public

touchscreen display system for iSchool community.

Proceedings of the 2011 iConference , ACM (2011),

808810.

19. Home - TACC User Portal.https://portal.tacc.utexas.edu/home.

20. Exchange Resource Scheduler.

http://www.austin.utexas.edu/exrs/utl/Default.aspx?rm

=dfa.4.112&vw=1.

21. Meeting Room Manager.http://www.asuresoftware.com/lcd-panel-scheduling.

22. Google Calendar API - Google Apps Platform --

Google Developers. Google Developers.

https://developers.google.com/google-apps/calendar/.

HCI IXlab Paper

Documents

Transcript of HCI IXlab Paper