HCI IXlab Paper
Content
UX Lab Scheduling & Information: A Multi-touch Browser Application
Nicholas Huba, Caris Hurd, Addison Martínez, Cary-Anne Olsen The University of Texas at Austin School of Information 1616 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. The installation 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 web application 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
2. 3.
passersby in the iSchool for the purpose of general awareness and recruitment Allow researchers at the iSchool another means for requesting reservations of the lab Convey general information about usability and the lab to interested parties
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: Webbased services
General Terms
Figure 1. Touchscreen display mounted on hallway wall outside IX Lab
Human Factors; Design.
INTRODUCTION
The School of Information (iSchool) at the University of Texas 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
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 are not made or distributed for profit or commercial advantage and that copies bear 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 prior specific permission and/or a fee. CHI Copyright 20XXxACM xxx-x-xxxx-xxxx-x/xx/xx...$x.xx.
The 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 feel competent and able to engage with the display without needing help or feeling self-conscious when in a social space [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 iterative design 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.
Another aspect of reading on a public display is that interactions 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 content consumption 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
software, but Asure Software has designed a system to be deployed 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
Borchers et al. suggest several functions for which kiosks can 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 advertising kiosks, 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 they suggest 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 option shown to work is using motion and physical signage to catch the user’s eye and prompt them to interact with the system [9].
Resource Reservation Systems
Several previous studies informed the design of the application we built. We identified several interface areas that needed attention: buttons, scrolling, text animation, and onscreen keyboards. Fitts’ Law predicts that the speed and accuracy of users is directly 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 a touchscreen system. Team members who had experience with Web design in the past were surprised by how much larger 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 animations help with readability and prevent disorientation. We worked to make the application interface as smooth as possible with the jQuery Mobile JavaScript libraries. The final important UI element was for users to be able to type 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
There are quite a few web-based room or resource reservation systems that have been created independent of touch functionality. One example is the resource reservation system used by the Texas Advanced Computing Center (TACC) to reserve rooms and computing resources associated with their Visualization Laboratory [19]. This system 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
WPM on the largest” [15]. Thus, the larger we could make the onscreen keyboard, the faster users can type in their information.
DESIGN PROCESS User Perspectives
usability and the capabilities of the IX Lab, would be needed. 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 the application. 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
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 that informed 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 the physical lab. Information regarding the current availability of the lab would help researchers determine if the lab’s 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. Upon confirming the availability of a particular time, researchers would want the convenience of reserving the lab immediately 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 studies would 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
Certain constraints were imposed by the size and placement of the input device as well as limitations with the interface’s 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 task that involved free text entry. Interacting with a touchscreen keyboard can already be difficult for many reasons. Its inability 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 keyboard’s 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 the interface is not in the more common, horizontal position. The touchscreen’s sensitivity and input interpretation was also 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 a quarter 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 a keyboard would be allowed only if no other method could be 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
A person interested in participating in a research study was another role that was considered. Possible participants would 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 the study’s 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 study’s researcher are necessary 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 and what it was used for. Providing easily accessible answers to questions users might have, such as a brief introduction to the concept of
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 system’s hardware. Broader, movement-based commands reduce the need for the user’s finger to hit a specific target such as a button or scrollbar.
Reserving the Lab
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 for selecting the date and time will be through the use of “flipboxes” (see Figure 3). These input elements only require 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 text inputs are the only ones in the system that use the touch keyboard. Due to the unique nature of names and email addresses, a complete range of letters and characters needs to be accessible. To inform the researcher that their reservation was submitted 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
The process of reserving the lab was broken down into smaller 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 an efficient method of presenting the user with the information needed to inform the next step in the reservation process (see Figure 2). With the IX Lab’s reservations already being tracked in a Google Calendar system, it seemed appropriate to integrate Google’s 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 the calendar’s 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 needs as 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 lab’s 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
that the requested reservation appears on the calendar displayed in the application. The reservation is placed in the exact date and time requested along with the requester’s name. The text “ - Under Review” appended to the reservation to distinguish it from other calendar entries that have been approved by the lab moderator.
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 become large 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
Figure 3. The user sees a “flipbox” with the months, days, and years available. Reviewing Studies for Participation
The need to attract the attention of those individuals that have no prior experience with the application was a high priority. 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 interface on the calendar display would give a clear and obvious indication that it was not simply a sign. However, this would 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 default display. 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. This would 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 a translucent 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
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 in displaying 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 researcher’s name and contact information, is easily seen and not lost in a poor quality flier. 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 the information 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 restless because of the need to stand or reach their arm up and
Much of the visual design inspiration was drawn from the Mac iOS touch devices, which rely on bottom navigation
and swipe events to navigate the system. The main challenge in building on that set of ideals is that this touchscreen’s 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 space to maintain legibility was a challenge of the design process.
DEVELOPMENT PROCESS Technology Environment
using the room, we chose to develop that portion of the application using Google Calendar.
Code Implementation
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 scroll to 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. The touch 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 did not pass all of the variables needed in the timeOut function for the screensaver mode. The screensaver mode advertised currently running studies to passersby, and was a key component of the end product. At that point, we reverted to using Firefox because the screensaver 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 using dragging gestures, and were unable to return to the desired state. If a user unintentionally zoomed, it could interfere with subsequent users if those settings were not automatically reset. Thus, we disabled the browser’s zooming functionality. Because the IX Lab managers were already using Google Calendar to keep track of who was on the schedule for
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, “... a fast 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 Lab’s existing web presence, and because all team members had experience with HTML. We wrote 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 experience developting with jQuery Mobile. It also leverages the use of HTML5, which assured that our application would be created 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 and deletions 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 lab’s Google calendar. This concession severely restricted the functionality of the calendar. The displayed calendar only worked 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 from outside source via custom PHP commands. Data collected in the “Request a Reservation” form was captured, formatted and sent to the lab calendar. During this process the text “ - Under Review” was appended to the request and displayed next to the requester’s name in the created calendar event. As another function of the form’s 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 an email that is sent to the lab manager. This alerts the lab
manager to review the reservation and determine if it is appropriate 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 metadata associated 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
result was to add a translucent box on the bottom right of the 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 was currently selected in each field. Two users (40%) asked for the ability to see the calendar so that they could judge availability 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
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 short usability tasks, and a post-test interview. For the pre-test interview, we asked users if they were students, 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 a touchscreen would be intuitive for passersby. The tasks we asked participants to complete were: Find a time to conduct a user test in the lab on May 10th and request a reservation at that time. 2. Find a study that you might want to participate in and find the contact information for the researcher conducting the study. 3. Find out which classes you could take to learn more 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
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 the interface. 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
1.
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 were larger 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 exceedingly difficult to use and requested that this interface be improved.
CONCLUSIONS: IMPLICATIONS AND FUTURE WORK
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 sure that it was a touchscreen. An optimization we made as a
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 and participants through the context of the IX Lab, supporting more efficient use of the lab and its resources. This paper explains 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
and time that they want to reserve, rather than making them use 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 posting functionality 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. Extending functionality to allow information to be shared via email or pushed to a mobile device would further refine user experience.
REFERENCES
8.
9.
10. 11. 12.
1. 2. 3.
4.
5. 6.
7.
Borchers, J., Deussen, O., and Knörzer, C. Getting it across: layout issues for kiosk systems. SIGCHI Bull. 27, 4 (1995), 68–74. Charland, A. and Leroux, B. Mobile application development: web vs. native. Commun. ACM 54, 5 (2011), 49–53. Churchill, E.F., Nelson, L., Denoue, L., Helfman, J., and Murphy, P. Sharing multimedia content with interactive public displays: a case study. Proceedings of the 5th conference on Designing interactive systems: processes, practices, methods, and techniques, ACM (2004), 7–16. Fitts, P.M. The information capacity of the human motor system in controlling the amplitude of movement. Journal of Experimental Psychology: General 121, 3 (1992), 262–269. Grakalic, A. Easy Slider 1.7. . Houde, S., Bellamy, R., and Leahy, L. In search of design principles for tools and practices to support communication within a learning community. SIGCHI Bull. 30, 2 (1998), 113–118. 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
13. 14. 15.
16. 17.
18.
19. 20. 21. 22.
symposium on User interface software and technology, ACM (2003), 159–168. 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. Ju, W. and Sirkin, D. Animate objects: how physical motion encourages public interaction. Proceedings of the 5th international conference on Persuasive Technology, Springer-Verlag (2010), 40–51. Lerdorf, R. PHP: Hypertext Preprocessor. . MacKenzie, I.S. Fitts’ law as a research and design tool in human-computer interaction. Hum.-Comput. Interact. 7, 1 (1992), 91–139. Norman, D. Gesture Wars. Core77 / industrial design magazine + resource / home, 2011. http://www.core77.com/blog/columns/gesture_wars_2 0272.asp. Resig, J. jQuery. 2012. Resig, J. jQuery Mobile Framework. jQuery. Sears, A. Investigating touchscreen typing : the effect of keyboard size on typing speed. University of Maryland Center for Automation Research Computer Vision Laboratory, College Park Md., 1992. Sorgalla, J. jCarousel. . 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), 45–54. Zhang, S. and Jeng, W. Designing a public touchscreen display system for iSchool community. Proceedings of the 2011 iConference, ACM (2011), 808–810. Home - TACC User Portal. https://portal.tacc.utexas.edu/home. Exchange Resource Scheduler. http://www.austin.utexas.edu/exrs/utl/Default.aspx?rm =dfa.4.112&vw=1. Meeting Room Manager. http://www.asuresoftware.com/lcd-panel-scheduling. Google Calendar API - Google Apps Platform -Google Developers. Google Developers. https://developers.google.com/google-apps/calendar/.
Nicholas Huba, Caris Hurd, Addison Martínez, Cary-Anne Olsen The University of Texas at Austin School of Information 1616 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. The installation 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 web application 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
2. 3.
passersby in the iSchool for the purpose of general awareness and recruitment Allow researchers at the iSchool another means for requesting reservations of the lab Convey general information about usability and the lab to interested parties
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: Webbased services
General Terms
Figure 1. Touchscreen display mounted on hallway wall outside IX Lab
Human Factors; Design.
INTRODUCTION
The School of Information (iSchool) at the University of Texas 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
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 are not made or distributed for profit or commercial advantage and that copies bear 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 prior specific permission and/or a fee. CHI Copyright 20XXxACM xxx-x-xxxx-xxxx-x/xx/xx...$x.xx.
The 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 feel competent and able to engage with the display without needing help or feeling self-conscious when in a social space [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 iterative design 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.
Another aspect of reading on a public display is that interactions 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 content consumption 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
software, but Asure Software has designed a system to be deployed 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
Borchers et al. suggest several functions for which kiosks can 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 advertising kiosks, 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 they suggest 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 option shown to work is using motion and physical signage to catch the user’s eye and prompt them to interact with the system [9].
Resource Reservation Systems
Several previous studies informed the design of the application we built. We identified several interface areas that needed attention: buttons, scrolling, text animation, and onscreen keyboards. Fitts’ Law predicts that the speed and accuracy of users is directly 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 a touchscreen system. Team members who had experience with Web design in the past were surprised by how much larger 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 animations help with readability and prevent disorientation. We worked to make the application interface as smooth as possible with the jQuery Mobile JavaScript libraries. The final important UI element was for users to be able to type 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
There are quite a few web-based room or resource reservation systems that have been created independent of touch functionality. One example is the resource reservation system used by the Texas Advanced Computing Center (TACC) to reserve rooms and computing resources associated with their Visualization Laboratory [19]. This system 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
WPM on the largest” [15]. Thus, the larger we could make the onscreen keyboard, the faster users can type in their information.
DESIGN PROCESS User Perspectives
usability and the capabilities of the IX Lab, would be needed. 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 the application. 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
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 that informed 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 the physical lab. Information regarding the current availability of the lab would help researchers determine if the lab’s 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. Upon confirming the availability of a particular time, researchers would want the convenience of reserving the lab immediately 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 studies would 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
Certain constraints were imposed by the size and placement of the input device as well as limitations with the interface’s 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 task that involved free text entry. Interacting with a touchscreen keyboard can already be difficult for many reasons. Its inability 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 keyboard’s 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 the interface is not in the more common, horizontal position. The touchscreen’s sensitivity and input interpretation was also 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 a quarter 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 a keyboard would be allowed only if no other method could be 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
A person interested in participating in a research study was another role that was considered. Possible participants would 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 the study’s 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 study’s researcher are necessary 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 and what it was used for. Providing easily accessible answers to questions users might have, such as a brief introduction to the concept of
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 system’s hardware. Broader, movement-based commands reduce the need for the user’s finger to hit a specific target such as a button or scrollbar.
Reserving the Lab
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 for selecting the date and time will be through the use of “flipboxes” (see Figure 3). These input elements only require 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 text inputs are the only ones in the system that use the touch keyboard. Due to the unique nature of names and email addresses, a complete range of letters and characters needs to be accessible. To inform the researcher that their reservation was submitted 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
The process of reserving the lab was broken down into smaller 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 an efficient method of presenting the user with the information needed to inform the next step in the reservation process (see Figure 2). With the IX Lab’s reservations already being tracked in a Google Calendar system, it seemed appropriate to integrate Google’s 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 the calendar’s 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 needs as 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 lab’s 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
that the requested reservation appears on the calendar displayed in the application. The reservation is placed in the exact date and time requested along with the requester’s name. The text “ - Under Review” appended to the reservation to distinguish it from other calendar entries that have been approved by the lab moderator.
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 become large 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
Figure 3. The user sees a “flipbox” with the months, days, and years available. Reviewing Studies for Participation
The need to attract the attention of those individuals that have no prior experience with the application was a high priority. 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 interface on the calendar display would give a clear and obvious indication that it was not simply a sign. However, this would 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 default display. 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. This would 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 a translucent 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
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 in displaying 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 researcher’s name and contact information, is easily seen and not lost in a poor quality flier. 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 the information 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 restless because of the need to stand or reach their arm up and
Much of the visual design inspiration was drawn from the Mac iOS touch devices, which rely on bottom navigation
and swipe events to navigate the system. The main challenge in building on that set of ideals is that this touchscreen’s 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 space to maintain legibility was a challenge of the design process.
DEVELOPMENT PROCESS Technology Environment
using the room, we chose to develop that portion of the application using Google Calendar.
Code Implementation
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 scroll to 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. The touch 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 did not pass all of the variables needed in the timeOut function for the screensaver mode. The screensaver mode advertised currently running studies to passersby, and was a key component of the end product. At that point, we reverted to using Firefox because the screensaver 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 using dragging gestures, and were unable to return to the desired state. If a user unintentionally zoomed, it could interfere with subsequent users if those settings were not automatically reset. Thus, we disabled the browser’s zooming functionality. Because the IX Lab managers were already using Google Calendar to keep track of who was on the schedule for
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, “... a fast 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 Lab’s existing web presence, and because all team members had experience with HTML. We wrote 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 experience developting with jQuery Mobile. It also leverages the use of HTML5, which assured that our application would be created 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 and deletions 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 lab’s Google calendar. This concession severely restricted the functionality of the calendar. The displayed calendar only worked 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 from outside source via custom PHP commands. Data collected in the “Request a Reservation” form was captured, formatted and sent to the lab calendar. During this process the text “ - Under Review” was appended to the request and displayed next to the requester’s name in the created calendar event. As another function of the form’s 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 an email that is sent to the lab manager. This alerts the lab
manager to review the reservation and determine if it is appropriate 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 metadata associated 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
result was to add a translucent box on the bottom right of the 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 was currently selected in each field. Two users (40%) asked for the ability to see the calendar so that they could judge availability 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
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 short usability tasks, and a post-test interview. For the pre-test interview, we asked users if they were students, 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 a touchscreen would be intuitive for passersby. The tasks we asked participants to complete were: Find a time to conduct a user test in the lab on May 10th and request a reservation at that time. 2. Find a study that you might want to participate in and find the contact information for the researcher conducting the study. 3. Find out which classes you could take to learn more 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
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 the interface. 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
1.
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 were larger 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 exceedingly difficult to use and requested that this interface be improved.
CONCLUSIONS: IMPLICATIONS AND FUTURE WORK
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 sure that it was a touchscreen. An optimization we made as a
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 and participants through the context of the IX Lab, supporting more efficient use of the lab and its resources. This paper explains 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
and time that they want to reserve, rather than making them use 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 posting functionality 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. Extending functionality to allow information to be shared via email or pushed to a mobile device would further refine user experience.
REFERENCES
8.
9.
10. 11. 12.
1. 2. 3.
4.
5. 6.
7.
Borchers, J., Deussen, O., and Knörzer, C. Getting it across: layout issues for kiosk systems. SIGCHI Bull. 27, 4 (1995), 68–74. Charland, A. and Leroux, B. Mobile application development: web vs. native. Commun. ACM 54, 5 (2011), 49–53. Churchill, E.F., Nelson, L., Denoue, L., Helfman, J., and Murphy, P. Sharing multimedia content with interactive public displays: a case study. Proceedings of the 5th conference on Designing interactive systems: processes, practices, methods, and techniques, ACM (2004), 7–16. Fitts, P.M. The information capacity of the human motor system in controlling the amplitude of movement. Journal of Experimental Psychology: General 121, 3 (1992), 262–269. Grakalic, A. Easy Slider 1.7. . Houde, S., Bellamy, R., and Leahy, L. In search of design principles for tools and practices to support communication within a learning community. SIGCHI Bull. 30, 2 (1998), 113–118. 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
13. 14. 15.
16. 17.
18.
19. 20. 21. 22.
symposium on User interface software and technology, ACM (2003), 159–168. 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. Ju, W. and Sirkin, D. Animate objects: how physical motion encourages public interaction. Proceedings of the 5th international conference on Persuasive Technology, Springer-Verlag (2010), 40–51. Lerdorf, R. PHP: Hypertext Preprocessor. . MacKenzie, I.S. Fitts’ law as a research and design tool in human-computer interaction. Hum.-Comput. Interact. 7, 1 (1992), 91–139. Norman, D. Gesture Wars. Core77 / industrial design magazine + resource / home, 2011. http://www.core77.com/blog/columns/gesture_wars_2 0272.asp. Resig, J. jQuery. 2012. Resig, J. jQuery Mobile Framework. jQuery. Sears, A. Investigating touchscreen typing : the effect of keyboard size on typing speed. University of Maryland Center for Automation Research Computer Vision Laboratory, College Park Md., 1992. Sorgalla, J. jCarousel. . 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), 45–54. Zhang, S. and Jeng, W. Designing a public touchscreen display system for iSchool community. Proceedings of the 2011 iConference, ACM (2011), 808–810. Home - TACC User Portal. https://portal.tacc.utexas.edu/home. Exchange Resource Scheduler. http://www.austin.utexas.edu/exrs/utl/Default.aspx?rm =dfa.4.112&vw=1. Meeting Room Manager. http://www.asuresoftware.com/lcd-panel-scheduling. Google Calendar API - Google Apps Platform -Google Developers. Google Developers. https://developers.google.com/google-apps/calendar/.
