Page History

...

UPCOMING Upcoming games are displayed using the same game box structure as in the main page. This achieves consistently throughout the site and improves learnability. Game history for past games also uses the box structure.

Implementation

PickFind is implemented using web technologies including HTML, CSS, Javascript, PHP, and MySQL. The front end layout and color scheme is in HTML/CSS. The middle layer interfacing front end client side with the back end server side is implemented in Javascript. The back end uses PHP and MySQL.

1. Back End
We store our data in two MySQL tables -- one for user data and for game data. We created a PHP file for each large operation into the database, such as create a game, edit a game, get the user’s upcoming schedule, get the news feed games, get all the filtered games, etc. To call these operations, we use Javascript and AJAX post requests to the specific PHP files.

• Game data
  The gamedata table stores a new record for each game. Each entry is identified by a unique, auto-incrementing game ID. Other fields include game start date, game end date, location, organizer, and game name. The organizer field contains the user ID of the organizer and can be used to direct an entry in the userdata table. In addition to these fields, there are also two fields that are a list of user IDs that relate to the userdata table. These two fields are list of players field and list of watchmen field.
• User data
  The userdata table stores a new record for each user, each identified by a unique, auto-incrementing user ID. Typical user fields include their first name, last name, username, password, email, age, gender, skill level, phone number, about me blurb and a profile picture URL. There are also a set of fields that keep track of lists of ID’s referencing another user record (user ID’s) or a game record (game ID’s). One field stores a list of user ID’s referencing a list of users you are currently following. Three other fields: list of games, list of organized games, and list of watching games, store a list of game ID’s. These ID’s provide a means to relationally access the other game data database.

2. Website Pages

• Login Page
  The login and logout process is handled with PHP.  A login cookie is created for each user session after a user successfully logs in with their registered username and password. Unless the user logouts or the cookie expires, the user will have access to their personal PickFind profile (their profile information, active games, game history and list of users they follow). The login page has a “Forgot your password” option. Passwords are  encrypted with MD5, and as a result, if a user misplaces their password, it must be reset.
• Logout Page
  The Logout page is accessed from the dropdown menu next to the username. As with the login process, logout is handled in PHP. On logout, the session cookie is deleted, and any attempt to load the main index.php page will redirect the user to the login.php page instead.
• Registration Page
  The registration page was implemented with a html frontend and PHP backend. The entries are checked to make sure the username and email address are unique, and also that both password entries match. If all conditions are met, a new record is inserted into the MYSQL database.
• Change Password Page
  The changing password page is also accessed from the drop-down menu next to the username. A PHP script verifies that both password fields match, then encrypts the string with MD5 before updating the user’s record in the MYSQL database.
• Logged-in Main Page
  The main page of PickFind, or the index.php file, is the page the displays whenever the user is logged in. It is split into three sections: the top header section, the right section with the schedule and news feed, and the large section containing either game information or profile information. The top and right sections are organized with <div> tags, while the large section is an <iframe> tag.
• Home Page (frame)
  The home page is the page inside the <iframe> tag the shows up when a user first logs in. This page displays the filter and list of all games as specified by the filter. The home page is organized with <div> tags. The filter portion is a <div> that expands and collapses as dictated in Javascript. Inside the filter, we use a few JQuery libraries to display the calendar when filtering date, display the time list when filtering by time, and display the slider when filtering skill level. Clicking on the “Filter” button or changing a filter field sends an event to Javascript that triggers an AJAX request to the database. The request retrieves the filtered games to display on the page. When we get this filtered result, we use Javascript to parse the data. Javascript then populates the game boxes in the All Games <div> and changes the window height. When the user clicks to expand/collapse the roster, a Javscript event fires to change the page accordingly. The appearances of these game boxes are defined in CSS.
• My Profile Page (frame)
  The profile page is divided into four main sections. The first section presents the profile information about the user. This is taken from the user database. All entries are initially non-editable. Clicking the “Edit” button/icon toggles the fields, and they become editable. This was implemented with a series of hidden fields that would toggle between hidden and unhidden by clicking the “Edit” button/ icon or the “Cancel” button in edit mode. In edit mode, making changes to the fields and clicking “Save changes”, sends an update command from PHP to the MYSQL database, changing the value in the fields as requested.
  The second section presents a list of users you are following. When you follow another user, you get updates about their game statuses, which show up in your news feed in the right pane. Five users are displayed in each row, with the option to display more available by clicking the ‘show more’ button. Javascript expands the size of the frame. This allows us to only request data from a small set of records each time, instead of having to pull the entire user database from MYSQL. There’s a filter option which let’s you search your following list. The search looks for matching substrings in the username.
  The third section displays a list of active games you the user are currently involved in. This includes future games you are organizing, joined as a player or watching. This list is pulled via a list of corresponding gameID’s stored in game lists in the user database. To display the games, both databases are queried. For consistency, these game boxes are identical in appearance  to the ones of the main page, and each provide the option to leave, join, edit, delete, watch or unwatch are required by the current status of the user in the particular game.
  The fourth section displays a game history: all games the user has participated in in the past. Similar to the third section, the game data is pulled from the game and user databases, but as expected without the options to leave, join, edit, etc.
• Other User’s Profile Page
  Clicking on the link of another user’s username takes you to their profile page. This page is presented in the same manner as your own profile page. The difference is that instead of the “Edit” button, you have an option to follow or unfollow them (depending on your current status). Clicking “Follow” or “Unfollow” has immediate feedback, updating the page by toggling the follow/unfollow button as appropriate.
• Update Profile Picture Page
  Profile pictures are stored are a URL string in the user database. To upload/remove a profile pic, PHP was used to check the validity of the uploaded file, including file type (.png, .jpeg, .jpg or .gif) and also the maximum file size. If requirements are met, the file itself is uploaded into the athena locker and the URL path to this file entered into the user record. Removing the picture, removes the url from the record. During page load, an empty entry in this field loads a default user image instead.
• User search page (frame)
  User search is accessed from the user search bar at the top of the page. This searches for a matching substring in the usernames across the entire user database. Clicking ‘Go’ takes you to the user search page, which displays the filtered results. Similar to the list of followers presented on the profile page, once again five results are displayed at a time to limit the requests required of the database server.

3. Event-handling

When the user triggers an event (normally by a button click), the event is handled through Javascript. Oftentimes it requires Javascript to make an AJAX request to change the back end database. Such events includes when a user joins, leaves, watches, or unwatches a game. These events trigger AJAX requests that update that particular game entry in the gamedata table and also updates the user’s list of joining games or list of watching games. Then the frame and feeds reload so the user sees the most up-to-date information. The same happens when an event triggers through creating, editing, or deleting a game.

Other events include following and unfollowing a user. When this happens, an event triggers to make an AJAX request update the user’s list of people he/she is following. The right side news feed also repopulates to include information that takes into account the new follow/unfollow change.

Events that do not involve AJAX include events where the user expands/collapses the roster/filter or clicks to see a pop up dialog. These are handled solely in Javascript.

4. Design Decisions

• The reason we used an <iframe> on the main page is so that we could change the contents in that section without changing the top or right sections. For example, moving to the user’s profile page does not require repopulating the user’s right section containing the schedule and news feed. This requires fewer AJAX calls to retrieve duplicate data from the back end.
• The reason we went with MySQL instead of some other database representation is because it handles concurrent actions, is easy to select specific table entries (making filtering easy to do on the server side), supports a large amount of data, and is easy to interface with through PHP. Originally we had planned to use JSON. However, drawbacks to that included that it was stored in a single file which limits concurrency and data size. It also forced us to write Javascript functions to manually get everything from the database and filter those entries.
• Our very first paper design used a separate game page to give users detailed information about the game. Eventually we took out the game page because it did not give much more information than what was presented in the game summary boxes. However, as we were implementing our page, we found that it was necessary to have some way for the user to get information about games on the news feed by simply clicking on those game links. Since a separate game page was out of the question, we decided to implement pop ups that looked like the game boxes that the user was already familiar with seeing.
• The reason we implemented a followers system instead of a buddies system is because we would not need to require mutual agreement and acknowledgement from both parties. See the first bullet in section 5 for more details.

5. Implementation Problems

• One problem we faced during implementation is that of the buddies system. Our design called for a buddies system, but while implementing we found that our system made it difficult to keep track of pending buddies, accepted buddies, blocked buddies, etc. This affects the usability because now a user can follow other users without them following the user back.
• We had problems implementing the news feed to include information about new follow events from people the user is following. In order for this to happen, we needed to keep track of the time when a user follows another user and display the most recent events. Because our system was not set up for this, we did not implement this feature. It is a step backwards for usability because information becomes less visible to the user.
• A major problem we ran into while implementing is the issue of getting information from the server side PHP and passing it to Javascript. We eventually decided to use AJAX requests and to put the data Javascript needs into the AJAX responses. For example, when a user filters a list of games, we send an AJAX request for the filtered games. We then use PHP to get those games from the database and put it in a response. It is only after the response is complete that Javascript gets the list of filtered games to display. In other words, the list of games cannot display until the response is received. This damages the latency reduction (visibility) aspect of usability because it sometimes takes a little time to receive the AJAX response, thus giving a longer response time.

Evaluation

We conducted our user test on three basketball players who regularly play pick-up games at MIT. They represent three different skill levels and are from diverse subsets of the MIT community. Our users all volunteered to participate in our evaluation. They were briefed with an overview of PickFind and then were presented with a series of tasks to accomplish. We chose not to include a demo so that we would be able to test the initial learnability of our interface. Response was generally positive, and users were curious to see how PickFind would work.

...