Headings: Online Reservations. Events Meet-ups. System Design. UI Design. Sports Game Reservation System. Usability Study

Transcription

1 Mingyu Li. The Implementation and Evaluation of a Simple Online Reservation System for Local Sports Game Meet-ups. A Master s Paper for the M.S. in I.S degree. May, pages. Advisor: Hemminger, Bradley M Scheduling and coordinating a sport game with multiple participants is increasingly complicated. It is particularly difficult to account for participant's travel schedules, and to accommodate those participants from different places to go to the same event. A simple online reservation system that allows people to sign up for recurring sports events is in demand. This project implemented a high-efficiency and user-friendly online reservation system for local sports game met-ups. The features included creating events, joining existing events, search events, cancelling events, and communicating between group members. We conducted a usability study to test the system and concluded that the system is helpful in improving user experience. Headings: Online Reservations Events Meet-ups System Design UI Design Sports Game Reservation System Usability Study

2 THE IMPLEMENTATION AND EVALUATION OF A SIMPLE ONLINE RESERVATION SYSTEM FOR LOCAL SPORTS GAME MEET-UPS by Mingyu Li A Master s paper submitted to the faculty of the School of Information and Library Science of the University of North Carolina at Chapel Hill in partial fulfillment of the requirements for the degree of Master of Science in Information Science. Chapel Hill, North Carolina May 2016 Approved by Hemminger, Bradley

3 1 TABLE OF CONTENTS 1 Introduction 2 2 Related Work 4 3 System Design Limitations of previous systems Hard to use Core features are ambiguous Design Requirements Features User Interface design Modules design 16 4 System Implementation and Coding Events services Location management User services Communications 26 5 Usability Study Overall objectives for the usability study Research questions Location and setup Recruiting participants Methodology Study Session design Session outline and timing Measures 33 6 Results Quantitative Analysis Qualitative Analysis Discussion on Obstacles and problems Whether the system is easy to use Discussion on usefulness and efficiency Users Satisfaction Wish to Change 40 7 Conclusions 42 8 Bibliography 43 9 Appendices Appendix 1: Tasks recording form Appendix 2: Consent Form 46

4 2 1 Introduction Scheduling and coordinating a sport game with multiple participants is complicated. Participants are often spread amongst many campuses or locations that may be separated geographically. It is particularly difficult to account for participant's travel schedules, and to accommodate those participants from different places to go to the same event. Suppose that there are five persons in local an area who want to play volleyball at the same court. How could they get the information like how many people are already there, when the court is available to use, and whether there are enough people to play a game? A simple online reservation system that allows people to sign up, like meet-ups for recurring sports events, could be beneficial. The main purpose of this online reservation system is to provide a meet-ups sign-up process that will maximize efficiency and use of space, track gym users in the facility, make it easy to add and approve new participants for certain games, and make sure the participants are notified of whether the signed-up game will be scheduled as normal or be cancelled. Generally, this paper will include two parts, system design (application development) part and evaluation (usability testing) part. For the design, I will create a web interface to implement the online reservation system. When users open that interface, they could see current upcoming events list including events name, location, time and participants. They could either choose to join one of the existing events or create a new one. To create a

5 3 new game event, users can choose game date and time period as well as preferred location, as well as crate an attractive game name to get more participants. Users are free to join or leave an event. Group discussion should be allowed within the event participants. In order to let the users locate the ideal game event quickly, filters and sorting methods should also be applied to the events details. In addition, the website design should be designed responsively and could function on a mobile screen. For the evaluation part, a usability study with the objective to assess the potential effectiveness and usefulness of new designed system will be conducted. The user feedback is quite important. Testing objects such like user interface and system functions will be taken into account. The system aims at facilitating the sign-up process. My expectation findings of the feedbacks should prove that the newly designed system is a high-efficiency and easy to use.

6 4 2 Related Work General study for meet-ups reservation systems mainly discusses the methods and the scope of its application8. The methods of the systems are various from different study fields like transportation, business, library, and so on. For example, in Bridget M. Mohler s[5] article, it provides a system and method for scheduling conference resources that monitors, tracks, and/or maintains information related to actual and projected locations of proposed participants, fixed conference resources, and/or moveable conference resources. The scope of its application, as we can see, could be a dinner meeting, a golf outing, or any other networking event. One aspect of the design is to provide a method and apparatus which enables a user to generate and then advertise or post an invitation to a proposed game meeting and directly or indirectly receive acceptances from prospective individual users8. Another aspect of the design provides a method and apparatus which enables a plurality of inviting users to advertise or publish invitations at a single location[4], which is readily updated, such as a pushed message, and accessible via a computer network, such as the Internet[6]. Other features of the design could include online group chat[2] to discuss or negotiate game rules and other issues before participants meet in person. Currently, the online reservation platforms designed just for local sports game meetups are quite few. However, there are many other online reservation platforms with the similar functions like group study system, study room booking system, dating system,

7 5 local parking system, etc. Some of them have developed a mature model for practical implementation, like room booking system[3], which has been put into real business use as hotels booking and pricing. An example is a volleyball online pickup play management system at local area ( This system is quite simple but provides the essential functions for the meet-ups events. Users could see current events details include time, location and participants listed on the webpage. When the user signs into the system, they could either choose to join one of the existing events or create a new one. To create a new game event, use can choose game date and time period as well as preferred locations. The locations here are four volleyball courts in local area. Although it could provides basic services for sign-up, some important features are missing. Firstly, it does not have a notification system for the users once they signed up. Users need to check the websites more than twice to see whether the game they signed up has added some new players (here we suppose that when the number of participants are less than the half of the legal number of players, the users are not willing to go to that game). Secondly, there is no function for cancelling a reservation. The biggest problem of this sign up system is its inability to prevent no shows. When an individual who signed up ahead of time don t show up for the time slot, it will annoy other participants who show up on the play court. Another example is Play Local ( this website is built by a startup company in Boston Area. The Play Local system aims at sorting out the frustrating parts of pickup tennis in and around the Boston area, allowing players to concentrate on the fun part of the sport. And the service is free (unlike many existing

8 6 tennis clubs and organizations). Play Local's vision is to create "a social platform that connects communities through technology with an emphasis on playing more games." In other words, they're innovating the usage of public tennis courts to maximize efficiency, and promote community wellness. Going beyond existing social networks, Play Local's goal is to not merely connect people online, but to connect them in real life as well (for the sake of playing tennis). The steps are as below: 1). Search for a time and place, and the website will provide you a list of courts and players at your own skill level. 2). Book your court ahead of time. 3). Show up on the court with your reservation on your mobile phone (or printed out). Besides the courts booking function, the website also provides services for finding a player in local area. It matches one user s skill with another player of equal skill (or whatever skill setting the user chooses) who is in the same area. As far as I can see, this system is much more complicated than the volleyball online pickup play management system we discussed earlier. Although it has additional functions like user center, game calendar, and finding a player, it seems harder to use when the player firstly clicks into this website. This system does not have a list of already registered game listed on the front page, which I think is very important for new users to join a game. If a user wants to search a game in the local area, he/she should firstly search for courts and then search for players. This process is time-consuming. However, the user interface of this system is better than the previous one. The above two systems are typically simple meet-ups for local residents, and those two are also designed for a certain kind of sports, i.e. volleyball, or tennis. One limitation

9 7 for the two is that the interfaces are neither designed as responsive. However, nowadays mobiles devices are widely used, that means this kind of application should be designed applicable to the mobile screen in order to facilitate more users[8]. There are also some websites that provides Meet-ups for general use. People can meet up with the local residents for any type of events. Meetup ( is the world's largest network of local groups. Anyone can use this platform to create a local group or find one. Meetup makes thousands of groups meet up face-to-face everyday. This website's mission is to revitalize local community and help people around the world self-organize. The interface could locate the user s accurate position and find the nearby groups information for the user. Currently, the application is one of the most welcomed meet-up social platforms in the word. This system also designed a mobile version with the same functions as the website. As a user of this system, I looked for the groups at my current location (Chapel Hill, NC), the type of groups is range from Horror movie club to Triangle JavaScript. The local people created all kinds events here, however it was not that easy for people just to look for one kind of event. For example, to find a tennis group, I should go from the start page, and clicked on the search button, then I had to look look for Sports & Recreation or Fitness. From the Sports & Recreation menu I could see some game groups but not so many, and I could hardly find a tennis group. From the Fitness group, however I could find nothing related to the tennis. It seems like this website is designed for those people who want to browser for anything nearby without a decision which type of group to go in mind. If a person is a basketball lover, and he just want to play basketball after work, the website is not probably not the most efficient way to go.

10 8 However, this web application is the most mature one in today s market. It provides various services for different groups needs. The users of this application is getting larger and larger, and people trends to trust this application. That means, the probability of success on face-to-face meet-ups should be higher than other unknown applications. Besides the above systems that are designed for the meet-up purpose, some social networking applications also provide the meet-up feature, like Facebook. The Facebook group events are popular among friends. However, the limitation is that, Facebook are social networking between friends (at least they acknowledged each other as friends ), people who are not addicted to social networks (who have relatively fewer friends on Facebook) might hardly find the interested sports games nearby. For the technical aspect of this kind of online meet-up reservation system, we firstly need to discuss the system design for those kinds of applications. Generally, the basic features of those systems are creating an event, joining an existing event, searching for an event, news feed of upcoming events, and user login/registration. All those functions are implemented in the previous discussed systems. The implementation of those systems are based on systems needs, specifically the larger user group, the higher level of technical methods should be applied. The volleyball online pickup play management system example given previously implements the website functions using both front-end web development languages like JavaScript as well as back-end web development languages like PHP. The PHP was used to connect the back-end database that stores the users and events details information. The reservation process is putting data into the back-end database and exchanging the existing data. The game events that automatically listed on the webpage are an information

11 9 retrieval process from the back-end database. This method is simple and easy to control. However, as the users and events grow larger and more functions added into the system, it is better to implement the system using a Java MVC frame like the second example of Play Local. But for the basic functions, the method from the above is the most efficient. To test the usability of this reservation system, user feedback is quite important. According to some related studies, there are many common questions when they doing the testing work. For example, before designing a new reservation system, we need to know the percent of stackholders who are not satisfied with previous reservation system and willing to change[10]. Also, we need to identify which group of people will use this system. After the implementation of the new system, several questions need to be answered from the user through the usability test. Identifying which feature that matter to the users[11] is quite important. Usually, usability test will pay attention to new functions of the system and do a comparison with other similar products[10]. Factors like users overall rating for the new system model[9] should also be taken into account.

12 10 3 System Design 3.1 Limitations of previous systems My concept for designing this simple online reservation system for meet-ups is to make it simple and easy to use. As we discussed before, there are several mature meet-up applications as well as some social networking applications that provide meet-up functions. However, there are quite few applications with the simple purpose for playing sports games within local community at today s softwares market. Many existing systems mainly have two limitations Hard to use. According to the systems just designed for sports game meet-ups we discussed previously, the system designers tend to pay less attention to the usability of the platform. However, in real life, people tend to like to use simple applications that could finish the work in a short time, especially for such simple things (looking for a game event nearby). Although the functions might be simple, the developers should also spend time on exploring the users preferences and applications usability. For example, most interfaces are designed only applicable to the full-page website, and the the interface is hard to use when users open the link from their mobiles.

13 Core features are ambiguous. Most simple systems are not mature enough to implement the full functions. They chose to cut off some functions. However, what to keep and what to cut off is difficult to decide. The PlayLocal ( intends to let the players to find players with the same level so it designs a block for the users to search for players. The two blocks ( find a court and find a player ) designed are together in the main page. However, in my opinion, that design is not useful for local people who want to find a game quickly. When the users enter the interface, what they want to see most is the list of nearby game events. People could communicate with each other when they are in the same group and can make friends afterwards. In addition, it is better for the game creator to enter a meaningful event name and an appropriate description, so the users will know better about the group and choose to join or not. 3.2 Design Requirements To make a better design for this interface, I made several improvements based on the previous discussed systems. The features will be focused on the core functions of the system, and the user interface should be mobile-friendly. We ll also talk about the different types of services this system will provide. Currently focused on the local community with relatively small population, this simple system will probably not encounter a heavy data flow, thus we may not be worried about the system computing efficiency, sever loads, as well as the database storage at the current time. The system design is focused on the features(functions) design and implementation, user interface design, and modules design.

14 Features Based on the related work we ve discussed previously, the related features to this kind of systems can be listed as follows: User Login/Registration. User Profile. User timeline Follow/Unfollow a user Upcoming events news feed Events sorting Events filtering Events searching. Creating an event. Joining an event. Leaving an event. Looking up location maps. Looking up event participants. Sending an to a group. Administrator over the events. Notification center However, to build a web site with the full functions as above should be complicated and it is hard to complete by one person within a short time period. In addition, our purpose is to design a simple interface that can be easily used by sports lovers. Therefore,

15 13 we cut off some functions of the system, like user profile, follow/unfollow, administrations, etc. We ll keep the core functions which related to the events objects only. The following list is the actual features we have designed for this system. User Login/Registration. Upcoming events news feed Events sorting Events filtering Events searching. Creating an event. Joining an event. Leaving an event. Looking up location maps. Looking up event participants. Sending an to a group 3.4 User Interface design According to Chen (2014), an effective and well-defined interface design will help users to locate the most critical information[12]. For the interface designed for people who looks for game events nearby, the most critical information should be the upcoming events list. Therefore, it is appropriate to make the upcoming events as main contents of the main page. Because people tend to see as much information as possible in one page, one event is designed as a row that will show the event name, event date, event time, event locations, and number of players already have. The event detail descriptions, maps

16 14 and players names will be hidden until the users mouse over the event name, location and number of players, which reveal details via tooltips. To locate the events quickly, I designed a filter by location on the left side bar. All possible game locations in local area will be listed in the side bar area, and the users can filter the most nearby locations. There are also functions like searching events, sort by events date/time and sort by number of players, which will help the users to quickly find the information they need. I named the interface as PickUp Events ( According to Fig 1, the main page shows an upcoming basketball events list. For each list, users can have two actions, join or leave. The search box is on the right head of the event list table. Users could resort the list by click on each tittle of the events list. Locations filters are on the left side bar. Currently, the interface only collects two major basketball courts at Chapel Hill. More locations will be added when the application is ready to use. When users mouse over the event name, it will show the event descriptions. When users click on the location, it will show the Google map with the location details in it. When users mouse over the number of players, it will show the name of the event participants.

17 15 Fig 1. Main Page of PickUp Events Users can also create a new event. Users can find new event button either on the navigation header of the main page or on the side bar. The new event page is showing as Fig 2. To create a new game event, users can choose game date and time period as well as preferred location. The locations here are game playgrounds (like basketball courts) in a local area. Creating a good name and writing down appropriate descriptions can help to attract the interested participants. For example, if you name your event as Beginners game, then other users will know your skill level and find if this group is suitable for them. Fig 2. Page of Create an Event Fig 3 shows the mobile version of this interface. The most important change on the mobile is that,the list row become blocks on the the small screen. If we do not change this on mobile, each row will be too long to be fully shown within the mobile screen, so users need to swipe right in order to see the full details. The design facilitates ease of use for the mobile users.

18 16 Fig 3. Interface on Mobile Screen 3.5 Modules design Each module is a tiny application of the system. Systems are composed of one or more independently developed modules that are not combined until the system is linked. A single module can contain one or several routines. In system design, the modules are also known as system services. To understand the PickUp Events system and its modules, I listed the four major modules of this system. According to the Fig 4, this system should handle four different kind of services, user service, event service, location service, and communication service. Each service contains one or more features we ve discussed before. Each module is like a tiny application and can be developed independently. We ll implement the system from the four parts.

19 Fig 4. Modules Design 17

20 18 4 System Implementation and Coding Since it is a simple reservation system and the data for local users are not so big, we could just implement the online system using web database technologies, e.g., front-end web development languages like JavaScript as well as back-end web development languages like php. I ll use a MySQL database to store the data. 4.1 Events services The major function for this interface is to get the events news feed for every user. We design to create an upcoming list based on today s date. When users browse the events, they will see the events list from today and after. Each event details are fetched from from MySQL database. The event table detail is showing as Fig 5. Fig 5. Events table

21 19 The location_id and the creator_id are foreign keys which can link to other tables in the database. As we designed earlier, each event should show event name, event description, event date, event time, event location, number of participants, participants names and also their s. When we retrieve the information, the first query should be as below (Fig 6): Fig 6. Query of the events details Then we have to find the participants names and s. My method here is to write another query from the database and stored the names and s as two PHP arrays, so we could use it later. The code is in Fig 7. When users click on the icon, it will pop up an box that generate all the group members s as the recipients. When users mouse over the plays number in the list, it will show a tooltip of the participants names.

22 20 Fig 7. PHP code of storing participants names list and s list After we prepared all the data, we should display them to the front-end user interface. I used PHP echo functions to print the data out. I used a table format to display the events list. The code is as below (Fig 8):

23 21 Fig 8. PHP code of printing the table to the web page The next step is to deal with the interactions with the users. The interface provides services that users could join or create an event, and also they could leave an event freely. Here we have another table which manages the relationships between events and users (See Fig 9). A user can join multiply events, and an event can have multiply users. So we need the link table in the relational database to fetch the cross-table data we need. Fig 9. The link table between the users table and the events table

24 22 The join service is to insert a new record with event_id and user_id into this M_e_u table. After insert, we also need to update the number of participants which is a field of the M_events table. The delete service is to delete a record from the M_e_u table. However, when the user is the last one to leave the group, this event should be deleted. The code is as below (See Fig 10): Fig 10. PHP code of deleting an event The create service is to create a new game event. For the PickUp Events interface, users could either click the new button in the main page or choose New events in the side bar to go to the new event page. The page is very simple. Users should enter the

25 23 event name, event description, date, time, and location. Then when the users click on the Submit button, this record will be written into the database. I used a PHP from to send the record. In the front end, I mainly used two plugins to make it easier for the users to enter the date and time information, one is datepicker, the other is timepicker. Those plugins can be easily controlled with JQuery code. Besides the technologies we talked above, for the front-end, we used a bootstrap template to make this interface responsive and mobile-friendly. Each object of the system is designed responsive. Also, I changed the default format of the table when it goes to the mobile screen. On the mobile platform, what people will see is the blocks list of the upcoming events. I used the rule to make this happen. See the Fig 11 for the code.

26 24 Fig 11. CSS code of special design for mobile screens 4.2 Location management We have the locations table to mange the locations data in local area (See Fig 12). However, the users can not enter a new location into the system for the current time. We ll prepare the locations list for the uses to choose from when they are creating a new

27 25 event. One reason is that the addresses that users enter might not be accurate, which will lead to an error when generating the maps through Google API. The mechanism to generate maps is, firstly insert the accurate location record in to the locations table, then output XML of map attributes with PHP, and finally create the map in the web page [12]. We can see the current locations details from the XML we have generated(see fig 13). Fig 12. Locations table Fig 13. XML of the Locations For the current time, this system only collects two locations in the center Chapel Hill. After we get more data on the local area, we could handle more locations for the users to choose from. 4.3 User services The PickUp Events interface provides users with login/registration service. When users log into the system, they can interact with the interface. If they do not have the

28 26 account, they should register one first. Registration is completed by using a PHP form. According to the user table (see Fig 13), the address is served as a user name, which must be unique. The s can also be used as communication tools between the event group members. Fig 13. Users table 4.4 Communications In this simple interface, we mainly handle the communications between the group members by s. However, for the security reasons, users could not see individual s address, but the only the s list of the group. People could find each other through the interface, but for a deep communication, they should go to the s and talk about it later.

29 27 5 Usability Study For the evaluation, a user study with the objective to assess the potential usability and usefulness of newly designed system was conducted. The study will have participants perform several tasks using the interface. Then they will be asked questions about their experience and what they think about the interfaces, including feedback about potential capabilities to add to the system. This user study makes an effort to learn potential usability and learnability issues, observe what aspects of the system would and would not be used, determine what capabilities provided the most value, and identify gaps and missing capabilities. 5.1 Overall objectives for the usability study We will gather baseline data about the overall effectiveness of the PickupEvents website. The goals of this study are to: Assess the overall efficiency and usefulness of the interface for performing basic, common tasks. Identify obstacles to completing game pick up events activities on the site. 5.2 Research questions In addition, in this study will try to answer these questions: How easily and successfully do users get started with creating or joining an event on the site?

30 28 What paths do users take to completing a reservation? How closely does the organization and flow of the site match users expectations? What obstacles do users encounter on the way to creating or joining or canceling an event? What questions do users ask as they work through their reservation? How do users feel about how long it takes them to complete an online reservation, both the perceived of time and the number of steps? How satisfied are users with the interface? At the end of the sessions, we will have generated the following quantitative data: Errors in completing a reservation activity we will know where the participant selected the wrong link or clicked the wrong button to reach the goal, taking wrong turns. Whether participants successfully completed tasks we will know, even if participants make errors on the way, if they can complete the task. Time on completing a reservation activity we will know how long it will take for the users to complete a certain task. Additionally, we will generate the following qualitative data: The verbal protocol the running commentary that participants make as they think aloud will give us indicators about what participants were confused by and why. Interviews - we will ask participants questions about how do they feel about the interface, like ease of use, satisfaction, usefulness, and efficiency.

31 Location and setup All research will be conducted in the computer lab located in the first floor of the School of Information and Library Science of the University of North Carolina at Chapel Hill. Participants will use a Mac machine and Firefox browser with a high-speed connection to the Internet. They will also use their own cellphone device (must be smart phones) to test the mobile version of the interface. A digital voice recorder will be used to create a set of audio recordings when participants are doing the tasks and during the posttask interview sessions. 5.4 Recruiting participants The study will recruit UNC-CH students that love sports as participants, regardless of their gender and race. Anyone interested in the study could participate. All participants will be contacted in person or by . There will be ten total subjects in the study. 5.5 Methodology This usability study will gather assessment data about the effectiveness and usefulness of PickUpEvents site. We will collect data about error and success rates as well as qualitative data about participants experiences using the site Study Session design The study will have participants perform several tasks asking using the interface. Then they will be asked questions about their experience and what they think about the interface, including feedbacks about potential capabilities to add to the system. Each participant s session was conducted individually and consisted of three main phases. The

32 30 first phase (tutorial) focused on learning about the system. An overview of the new system and a description of the underlying data will be provided. For the second phase participants will do a set of tasks testing the functionality of the interface. The errors and timing will be recorded during the phase. In the third phase, participants will be asked questions as part of semi-structured interview process. This will provide the qualitative data about how they feel about the interface. In the mean time, we will also follow up on any problems that arise during the second phase Session outline and timing The test session will be about 45 minutes long. I will use 15 minutes for pre-test introductions and trainings and 10 minutes for post-test interviews Pre-test arrangements (2 minutes) Have the participant: Sign the consent forms. (See Appendix 2) Review and sign nondisclosures and recording permissions Introduction to the session (5 minutes) Discuss: The study, including the scenarios of the interface design and the purpose of the study. Room configuration, recording systems, devices, etc. The protocol for the rest of the session.

33 31 The think-aloud process, tell the participant that they will have to verbalize all thoughts and reading while using the web interface Background interview (2 minutes) Discuss the participant s: Experiences in finding a group to play games together. Whether they have used similar tools for playing team sports before Training on using the interface (6 minutes) Train the participants to: Sign in or register the interface. Click the two buttons at the right hand of the list to join or leave an existing event. Mouse over on the list details to see more descriptions. Click on the new button on the first page to jump to the creating event form. Use the search box to search the listed events. Resort the list by click on the right side of any titles. Click on the toggle button to show or hide the left side bar. Click on the tree menus to look for more information. Zoom in or zoom out the interface. Click on the mail button on the left side of the list to send an to the group. Using the same interface via mobile. Touch each items on upcoming events list for more information. click on the toggle button at the top left to show the

34 32 side bar menus. Practice joining, leaving, creating actions on the mobile interface Tasks (20 minutes) When we have the participants ready, we ll start the tasks. For each experiment, I will have paper copies of the tasks to give participants (See appendence 1), which will have the each task number along with its descriptions. It will show the expected finishing timing and allowed clicks for each task. I will also record the actual timing and clicks during the experiment. The task list: Join a basket ball game at 6-8pm this Friday at Rams Head Find the names of people who joined the same events with you. Send a message to your team players. See the location maps. Quit the event you just joined. Create a basketball game event tonight at Fetzer gym basketball courts. Cancel the event you have created. Use the mobile version to create a game at 3pm this Friday at Rams Head gym basketball courts. Use the mobile version to join an upcoming game you are interested. Use the mobile version to Talk with your team members about the play rules before the game starts.

35 Post-test debriefing and interviewing (10 minutes) Ask broad questions to collect preference and other qualitative data. Follow up any obstacles they encountered during the tasks. Follow up on any particular problems or questions that came up for the participant. How easy was it to perform the tasks? (likert scale 1-5 very hard to very easy) Which tasks were the most difficult and why? How do you like the interface? (likert scale 1-5 not like to very like) What did you like about the interface and why? What did you not like about the interface and why? If you were a designer for such kind of system, what design would you expect? Now you have seen my interface, what the gap between your ideal design and my work? If you could change any aspects of the interaction in any way, what would you change? 5.6 Measures To answer research questions as I listed before, I will collect two types of data during the test sessions. The performance data: Number of tasks completed with and without assistance. There are 20 minutes in total for the participants to complete all the tasks. If the

36 34 participant asks for any help while using the interface, it is considered as with assistance. Actual clicks of each task. Actual finished time of each task The interview data: We will record the debriefing and interviewing phase, get the qualitative data on evaluation the interface. We will also pay attention to the words while the participants saying during the tasks phase, those will help us to analyze personal thoughts on using the interface.

37 35 6 Results 6.1 Quantitative Analysis We collected three kinds of quantitative data during the study. We observed the study participant s behaviors while they are doing the tasks. The recorded the number of tasks completed with and without assistance, the actual finishing time of each task, and the actual clicks of each task. All those three metrics will reflect how easy to finish those tasks, which could tell us whether the interface is ease to use. The actual finishing time of each tasks will also tell something about whether the design of the interface is efficient or not. In addition, we can see if some designs are redundant or not from data of the actual clicks of each task. We analyzed the three kinds of data and summarized it as below: 100% participants finished all the tasks within a total time of 15 minutes (except the time of deciphering the task questions). 90% participants finished the tasks without assistance. Only one participant asked help on task #7. The participant was confused at how to cancel the event he has just created because there is no cancel button at the front page. After I suggested him that why not try to leave the group and see what happened, he successfully cancelled the event after he saw the system alert You have left the group. The event has been deleted because no on is in it.

38 36 The actual timing of each task completed by each participant was less or equal to the expected finishing times. We computed the average time for completing the tasks. According to Table 1, the actual average finishing timing is about 51%~90% of the expected finishing timing. Participant rarely encounter tasks where the time is not enough for them to complete the task. Task No. Expected Finishing timing Actual Average Finishing timing 1 60s 42s 2 30s 27s 3 90s 46s 4 60s 41s 5 30s 19s 6 120s 93s 7 90s 52s 8 180s 132s 9 20s 15s s 187s Table 1. Timing of each task Compared to the expected allowed clicks, the actual clicks are or less equals to what we expected. We recorded each participant s clicks on each task, and the details can be found on Table 2. Some tasks seems very easy and can be done within 0 or 1 click. Task No. Allowed clicks The least actual clicks The most actual clicks Table 2. Clicks of each task

39 37 According to the data above, we can conclude that the interface interface allowed the users to complete the tasks as fast or faster than the goals we set for each basic function task. We believe the designed features are easy to learn and easy to use. The participants rarely took a wrong turn when they are using the interface. Thus, users could finish their reservation needs (whether joining, leaving or creating) with high efficiency. This is encouraging that the system maybe be easy to use. One limitation noticed, was that since the interface does not have cancel button for the existing events, the events creators might be confused about whether they could cancel the event they have created or not. Actually, my design for the cancelling is that, only the last one of the group can cancel the event. That means, even though you are the creator of the game, but if more than one person joins the group before the game start, you can not cancel it on your own. The interface is designed for all users and currently there are no administrators who can rule over all the events. 6.2 Qualitative Analysis We have a both background interview before the session start and a post-test interview after the participants finish all the tasks. We could collect qualitative data through those two phases. In addition, since we have a think-aloud process during the tasks, we could also find what the participants thought when they were trying to finish the tasks Discussion on Obstacles and problems We found one interested common behavior among the participants when they were doing the tasks. We observed that when the participants joined or left or created an event, they usually tend to look for the activity history they have done. Even though they have a

40 38 feedback (e.g. alert from the system), they still need a confirmation. That is, most participants want a timeline of their own page instead of looking back on the event list. Even though the main page could help the users to locate the event (like using search boxes, sorting the event, and looking up the participants names), it is still necessary for the users to have their activity timeline. Another way to avoid this obstacle is to have a notification message, i.e., when user have a new activity, they will be notified by an . The other problems participants usually asked are about the cancelling. As we discussed before, this system will not allow the creator to cancel the event they created. The mechanism for deleting an upcoming event is that, the last one of the group leave event. My design for this is want to keep all functions in one page and make the interface very simple and easy to manipulate. Although users could finally find the leave button to cancel the event if no one else is in it, explanations on this mechanism are needed. One place to explain it would be during the New Event creation process Whether the system is easy to use Based on the interview question, How easy was it to perform the tasks? (likert scale 1-5 very hard to very easy), we could see the difficulty level of using the interface. According to the data we collected from the interview, 3 of the participants gave the 4 score and the rest of the them gave 5 score. Nearly all participants thought this interface was very easy to use, and they could locate to the most critical information at a very short time. When we discussed which task was the most difficult one, 2 participants said that it was cancel the event you have created, and 2 participants said that it was send an

41 39 to the group on your mobile. The rest 6 participants said nothing difficult at all. The reason why sending s on mobiles is difficult is that, users need to touch the button twice to pop up the box. That s is because the icon was attached with two actions, one is mouse over and other is click, but on the mobile platform people can only touch the icon. So, when people touch the icon for the first time, it will show the description message, and the when they touch it for the second time it will finally pop up the box. One participant suggested that on the mobile screen, when the item is clickable, the mouse over functions should be disabled. Other interaction tools should be used to show such information Discussion on usefulness and efficiency Before we lead the participants into the real tasks, they are given a background interview on how familiar they are with similar systems. Four people said they heard about the Meetup (meetup.com) but only one had used it. Eight people said they heard about the Facebook group event, however, none of them had attended an event through that. When I asked how to meet up with other players nearby, nearly all of them answered they would like to ask their friends first. They usually used personal social networking software to discuses the game event within friends group. However, if there are not enough friends are willing to come, they have to cancel the event. Although people tend to look for friends to play with first, a platform that helps people to find enough game players would still be helpful. Sports game are not like other events that would disclose some important personal information, and playing games with strangers is acceptable by most people.

42 40 According to the post-test interview, most people said they like the most of the design features of the system, and it should be useful when they are trying to find a game event nearby. According to the interviews, the simper the interface, the more likely they are going to use. For such kind of simple thing (i.e., finding a nearby player), the efficiency is the most important thing for them. They will not waste time on struggling with complicated interface and looking into the details. According to the users feedbacks, the PickUp Events interface is simple and efficient both on the UI design and the services providing Users Satisfaction According to the interview question, How do you like the interface? (likert scale 1-5 not like to very like), we can see the participants satisfactions on PickUp Events. the average score for this question is 4.2. Three participants said they would like to give the full score because of the simple design and the core features. One participant said he would like to give a score of 3 because there is no personalized page for a certain user. Most participants said the PickUp Events could satisfy their basic needs and on sports game meet-ups and the upcoming events list is exactly what they want most. Although people have different opinions, the over all satisfaction from the participants is optimistic Wish to Change When discussing participants expected designs, 2 people said they would more likely to choose a dropdown box to show the item details more than use the function of hovering the mouse over an item. They said it would be better if we hide the event descriptions first, and when the users click on the event name, the full details including

43 41 location descriptions, players names will be shown as a dropdown box. And when click it again, the box will be hidden, so users could continue to look for other game events. Three people talked about the administration issue. Currently the system does not have an administrator to rule over all the events, nor to manage the users services. They thought it should be added into the system so that the system could provide better services for the users. One person talked about the users security issue. He suggested that the user authentication is required before they could join or create an event. It was strongly recommended for the users to link their personal social networking accounts to this interface accounts. In this way, the users will feel less worried about their group members identities, which will make it easier for them to meet in person. According to the interview, the feature of user s personal timeline is the most want to add feature. Seven participants said the user timeline helped the users to remember what they have done previously and notify them of the upcoming events they have joined. Some of them also suggested to move the event details like the event participants names into the personal page. That means, only after you join the event can you see the other participants and their contacts. That suggestion is also reasonable.

44 42 7 Conclusions This paper proposes an online reservation system for local sports game meet-ups with a novel user interface based on the functions of the system. It provides users with services including creating events, joining existing events, searching events, cancelling events, and communicating between group members. The system was developed with both frontend and back-end web development technologies. A high-efficiency and user-friendly interface has been implemented through the project. Responsive design theory was also used to make the interface easier to use both on the desktop and on the mobile phones. We also conducted a usability study to evaluate the system. The goal of the user study is to assess the overall usefulness and efficiency of the interface for performing basic tasks, as well as identify obstacles to completing activities on the site. The study results showed that the system was very ease to use, and should be useful in real life scenario. However, there are also some limitations for this project currently, e.g., lack of user timeline and events administrations issues. Future studies should explore more advanced applications of this system, including notification center for the system, personalized user pages and interface administrators. Functionality should also be extended to the major social networking systems and cloud computing services, so that the users could connect their activities to other platforms.