GR6 - User Testing

Design

One of the most important design considerations that we changed from our paper prototype to our final design was to allow the user to create events from the homepage, in addition to search for them. We recognized that the important distinction between our two main classes of users, party-goers and party promoters, was their primary tasks were searching and creating parties respectively. The original design only had a search bar on the main page, which only allowed partygoers to look for their event. If the search came up empty, there would be a link to create an event. This is not ideal for the party promoter because the interface is not easily learnable nor is it accessible. Therefore, we created two toggle buttons on the homepage to allow both user classes to easily access their primary tasks from the homepage.

One of our user tests pointed out that they didn’t know what they could type in the search bar to effectively find parties. We realized this was a problem with usability and that it might cause errors if the user tries to find their event by date and cannot find it. Therefore, we came up with two solutions: to either create tooltips that would appear when the user clicks on the search bar or to display a watermark tip in the existing search bar that would disappear when the user clicked to focus on the search bar. We chose the later of the two choices because it would be more visible to the user since it appears by default and also because it was consistent with other search engines like Grooveshark, Pandora, and Last.fm that all use watermark tips.

Lastly, we made some cosmetic changes to the splash image to reduce its look as a button. Some users tried to click on the splash image, for no reason but that they wanted more interaction. Because each image has a border around it, it gives it the slight affordance that makes it look like a button. Thus, we removed this border to make them look more like pure images.

Implementation

The major features that required the most attention to improve from prototype to beta version included logging in, searching for events, creating events, and uploading songs. We implemented the login system using a simple php library called Light OpenID. Specifically, we limited the available Open ID providers to Google, allowing the user to log in with his or her Google account. Once the Light Open ID library had authenticated the user's credentials, we gathered the necessary user information from the authentication request and stored it in a loosely encrypted form using a PHP Session.

To enable search, we developed a simple algorithm to scan all available event data for strings matching the user input. The application used PHP to connect to a MySQL database, so we used the SELECT SQL query with regular expressions to allow for dynamic search capabilities. To create events we used the CREATE SQL query, submitting text data for the basic information of the event. Since the flyer image was binary data, we used a BLOB column to store it in the database along with the rest of the event information.

Finally, the event page called for multiple key features in the upgrade from prototype to beta. The upload feature used the standard php file upload method, saving the file to a predefined place on the server. To allow the user to listen to the song we used a simple embedded flash player provided free by Google. The source of the player could then be set to the uploaded song's filepath on the server which could then download the data for the user to listen to.

Evaluation

Briefing

We appreciate you taking the time to partake in our evaluation.  Our website is called RemotePlaylist and it enables users to upload, download, and browse music that are being played at variety of different venues.  As a partygoer, you can search for an existing party or you may create a party of your own.   As the website states, “RemotePlaylist is a social music recommendation engine that lets you request your favorite songs before going to the actual party. That way, you know you're going to have a good night before even leaving the door.”

Users were selected randomly among the MIT population.  We would ask people to take a few minutes to test out our design.  The user testers were generally within the demographic that the website was geared toward:  college students with an interest in music and fraternity parties, and did not have extensive knowledge of user interface design.  Users would first take a couple moments to look at the icons before

Scenario Tasks

1. Log in using your Google account

2. Create a party

3. Search for a party

4. Browse through a list of parties and find your desired venue

5. Play a song the playlist

6. Upload a song onto the playlist

7. Rate a song using likes or dislikes

8. Log out

User Testing - Usability Problems

User 1

Problem 1: One user noted that while the buttons on the front page add to the aesthetic value of the front page, he was tempted to click on them.

Given their size and contrast to the background, it is conceivable that  they give off the affordance of a button.  Nonetheless, this was a tradeoff that we were willing to make because the icons are able to succinctly describe verbally and visually the function of the website.  (Minor, button affordances)

 
Problem 2: There currently does not exist a discernable ordering of parties.

This will require figuring out a way to incorporate likes/dislikes into the position in which the parties are ordered.  (Minor, Flexibility and efficiency)

Problem 3: There isn’t an option to perform an advanced search.

To correct this issue, we will have to find matches from in the database for a specific set of fields that the user would like to search for :  (i.e.  DJ Zeus, City:  New York or Boston)  (Minor, User Control and Freedom)  

User 2

Problem  1: There currently does not exist a method through which users can browse parties according to specific fields:  time, date, location, party playlist rating

One possible solution is to incorporate a tab that allows the user to reorder parties by different fields, in a manner similar to Itunes, which allows users to order music through song title, artists, and length.  This can be done by drawing information from the database to create a dynamic view of partylists. (Major, Flexibility and efficiency)

Problem 2: User also reiterated the importance of an advanced search. 

 As he stated, "I would like to be able to restrict my search results to a specific t ype of party at specific date, and a specific city. 

Problem 3: When uploading a song, the program does not check for duplicates.

In order to prevent duplicate songs, we will need to match check songs that and double check that there aren’t any songs with the exact entries for the following fields: song/title, file size, track length.   (Minor, Error Prevention)

User 3

Problem 1: Should place the search bar at the top, even before the three icons,  as it is considered to be the most important aspect of the main page (Minor, Efficiency, Visibility)

Problem 2:  After the search has been populated, the main focus should be on the playlist. 

Users have a list of all the songs in the playlist on the front page, or at least a sampling of the most popular songs being played, with a link to a player. The purpose behind the website is the enable the user to browse through the selection of songs, and  not the individual club.  (Minor- Major,  User Control)

Reflection

Our team learned some valuable lessons from the iterative design process. At the beginning of our brainstorming process, we were maybe too confident in what we wanted our final project to look like. We believed that our mental concept of the website was very solid and would be simple to use and aethestically pleasing, but in the end, we realized that some of our ideas were still premature and vague.

Sometimes, our users provided us comments about very obvious problems with our interface, which we were blind to becuase we would find ourselves focusing on specific aspects becuase they are in front of us. Users wondered how they could create parties using our application. We didn't have a very clear way for them to do this, so we added an option to create parties on the homepage.

If we started the project over, we would try to focus even more on usability. One of the faults that affected our final project was the fact that we realized there were alot more actions than we originally planned. We didn't intend for users to change their event once they created it. We created an interface that allowed a user to change their event, but it was not as well integrated becuase the idea to remodify events was not introduced early enough in the brainstorming process. We would also focus more time on even more usability features like suggestions for search, tooltips for form completion, and better error prevention.