Wishdex GR6

Design

Screenshot	Feature
	1. The Home Page We were motivated by the paper prototypes to have a home page that serves as a tutorial for the user, to act as the briefing from user testing. The heuristic evaluations mentioned the lack of a login alternative. We still used facebook connection for the simplicity and overall feel of the implementation, but we tried to make the "Start wishing" more prominent on the page with a bigger click area.
	2. Left Navigation After some confusion from the heuristic evaluations, we decided to have a disappearing tree navigation menu, with wisdex names hidden outside of the "managing" tab. We also fixed some of the highlighting issues in the heuristic evaluations by clearly indicating to the user whether they are on the Explore page, the Friends page, or a Managing page. If they are viewing another person's wishdex, none of these are highlighted to indicate that the act of viewing a wishdex is not part of Friends or Exploring.
	3. Logging out We added the ability to logout as per our heuristic evaluation suggestions.
	4. Add a Wishdex Originally we thought about having an in-place text edit on the left menu bar to add a wishdex. We did not have a popup up for adding a wishdex in our computer prototype, but decided that the best way to add a wishdex would be to better indicate the textbox affordances to the user in a popup window.
	5. Add an item We added information scraping for one site, anthropologie.com to allow the test users to get a sense for an easy add-item experience. The user enters a URL and the information is grabbed from the site and populated into the appropriate spaces. We did not include this popup in our computer prototype, but did have a positive feedback from our paper prototype users for automatic scraping.
	6. In-place confirmation In this screenshot, the user can click on the X to delete an item and the confirmation message will show in place. We were motivated to make this decision to facilitate the deleting process. Our computer prototype had no deleting functionality, and the heuristic evaluations reflected this.
	7. Item information editing Clearly labeled sections allow user to easily see the current information. Hovered colors with change cursor give affordances to user for clicking to edit the information. Our computer prototype did not address the editing issue, and the heuristic evaluations reflected the lack of editing.
	8. Tooltips Each button on the item information page has a tooltip that helps the user understand the purpose of the button. Our heuristic evaluations and paper prototype indicate that users were confused about the meaning of "Acquire" or "Claim". Tooltips help to guide the user to their intended action and allow them to explore the possibilities in Wishdex.
	9. Sharing a Wishdex Clicking the "share this wishdex" button opens up a unique URL. The sharing link comes with a tooltip that explains the purpose of the sharing (indicative of heuristic evaluation points). Our user testers after the final implementation all suggested to automatically highlight and copy the URL. We definitely agree but did not have time to make the changes.
Hotspots, wishdex image Arrows:	10. Explore page Hotspots Heuristic evaluations suggested that we make it easier for the user to scroll through the items. We decided to add hotspots to allow the user to seamlessly browse with only hovering. Wishdex image We moved the image of the wishdex to outside of the scroll to indicate that everything in the scroll is part of that wishdex. Arrows Heuristic evaluations suggested that we indicate the end of the scroll more obviously. We removed the arrows completely when the end of the scroll is reached.
	11. Friends page Search Despite one heuristic evaluation that suggested we put the search bar on every page of the website, we decided to restrict the search bar to only the friends page because we saw little improvement in user experience for putting the search bar on a managing a wishdex page or the popular page (which is only one page!). The search bar autocompletes, a decision that was influenced by our paper prototype users. Recent Activity We create appropriate links to the user's home page, a specific wishdex, or even a specific item on each recent activity item as per complaint about no interactions with the feed from the heuristic evaluations.
	12. Item information popup Many of the heuristic evaluations indicated a messy display in our item popup from the computer prototype. We organized the layout into a more intuitive display with tooltips that help the user understand what the buttons do. We added in comment functionality, and the time displayed is user friendly ("3 days ago" vs "May 8th") Like and Claim buttons change color when activated, with tooltips that indicate the reason for the change. We added the functionality to copy an item to your own wishdex. The user clicks on the "Copy" button and a dropdown pops up. In the future we will change some of the buttons as per our final user test results as well as add in comment deletion.
	13. User page Each wishdex box has a mouseover iPhoto-like effect for the pictures of items in a wishdex. Moving the mouse across the box will allow the user to see the pictures change. We made this design decision because heuristic evaluations indicated that we need to make a wishdex different from an item in their display.
	14. Stylistic changes All icons were reinspected for aliasing (heuristic evaluation)

Implementation

Our project is a website, and was thus made using standard web programming tools. The frontend is entirely HTML, CSS and JavaScript. The backend was written in Python using the Flask web framework, utilizing SQLite for the database.

Important Design Decisions in Implementation

Minimize page refreshes

To improve the usability of our interface, we tried to avoid have the page refresh when the user performed most actions. For example, claiming, liking, and commenting do not cause apparent page refreshes. Even more complicated actions, such as deleting items occur without a refresh. In cases when a refresh is necessary, we tried to keep the experience as stable as possible, such keeping the item popup open when copying an item to a different wishdex.

Download pictures to keep browsing fast

Initially, we only stored image URLs and loaded and resized them on page load. However, we found that this made browsing slow, particularly for the scrolling interfaces we had built for the Popular page. We therefore wrote the add item process to download and locally store small versions of the images.

Keep structure simple and consistent

We decided to use Flask and SQLite because they are a “micro-framework,” meaning it allows for simple views, templates, and models without extra capabilities provided by more elaborate frameworks. In addition, we tried to keep aspects such as URL structure and parameters for AJAX calls as simple as possible and consistent across different but similar use cases.

Force Facebook Connect for login

We chose to keep the login process as easy as possible by only allowing Facebook Connect. This allowed us to get simple information about the user without requiring another form. This also prevented some validation from having to be written on the backend.

Only allow comments not replies

We chose to only allow comments on items without any replies to them. This greatly simplified the interface implementation on the frontend and the backend structures necessary to store and access the comments. We believe that comments alone are adequate for a user of our website.

Implementation Problems and Effects on Usability

Note: Some smaller issues, such as the user's icon next to a comment not directing to the user's profile page, are mentioned in the Evaluation section.

Scraping limitations

We only implemented a scraper for Anthropologie items. This automatically fills the fields of the “Add Item” popup when the user enters a link. The lack of a scraper for other links makes the site much less efficient for adding items, which is one of our core functionalities, because the user must enter the item information manually.

Speed issues

Although using SQLite as the database kept our development environment simple, it also contributed to some of our pages loading slow at times. In addition, some of the frontend had fairly heavy JavaScript usage, such as the popup boxes. This issue added to page loading times. Both of these problems affected feedback on certain actions to some degree.

Facebook Connect

As mentioned in our Evaluation section, Facebook Connect is not the preferred method for logging in for some users, who prefer not linking their Facebook information with other services. Although Facebook Connect made login more efficient, it also made our website less desirable to use for some users.

Evaluation

We conducted a user test on Sunday, May 8th, 2011 at the MIT Student Center.

We looked for three users who would be representative of our target user population. Our target user population was users in the 18-30 age range who felt comfortable using computers to surf the Internet or do work. The logic behind this was that Wishdex is an online shopping tool for indexing items found while shopping online or browsing the Internet. The tool would only be useful if the user felt comfortable using a computer and online shopping sites. The users we managed to find were all fellow students who fell in this target age range.

We approached students who were already sitting in front of a computer, in the MIT Student Center computer cluster. We found two female and one male test user. Our target user population is skewed towards the female population, because we observed that female students tend to shop online more frequently. However, we built Wishdex with the hope that it would appeal to male users as well, and made sure to find at least one male test user.

Process

We followed the following set of steps with each test user. We made sure that the test environment was as standardized as possible.

The facilitator reads the briefing (see Briefing section) to the test user.
The facilitator reads each task one by one (see Tasks section). After each task is read, the user attempts to complete the task while vocalizing their feedback. Where appropriate, the facilitator encourages the user to provide feedback.
The observer records the feedback given by the test user.

Roles

Susie Fu facilitated the test.
Emily Zhao observed the users.
Ashutosh Singhal was on call to perform last minute bug fixes.

Briefing

Our application is Wishdex.com, a site that helps you keep wishlists. You can keep track of items you find online, show your friends and family gifts you want for Christmas or your birthday, and see what your friends are interested in or check out popular items on the site. We're doing this test to get some feedback on how well we've designed the user interface. There are probably a lot of problems with the design, and we need help finding them. Keep in mind that we're testing the computer system, not you. Also, the results of this test will be kept completely confidential, and you can stop and leave the test at any time. My name is Susie, and I'll be reading out the tasks we want you to perform. This is Emily, and she'll be taking some notes to help us remember the problems we find.

Note that we did not use a demo as part of our briefing. The motivation for this was that we wanted our site to be usable without a demo to the test users we were able to find. We designed Wishdex.com to be a site that someone who falls under our target test definition can go to and instantly be able to use.

Tasks

Log in
Managing
1. Create a new wishdex called "Birthday Wishlist"
2. Add new item from Anthropologie.com to this wishdex
3. After adding the item, change the item description
4. Create another wishdex "Christmas" and move this item to the 2nd wishdex
5. Share "Christmas" with your mom
6. After some thought, you decided to buy this item on Anthropologie.com. You still want to keep the item on your wishdex, though, but you want to mark that you've acquired it.
7. Delete an item
Exploring
1. Browse popular wishdexes on the Popular page
2. Check out the recent activity
Friends
1. Find Emily's wishdex, "Cool Patterns"
2. Like one of the dresses in her Wishdex
3. You want to buy this item for her, so claim the item and view the item on the Anthropologie.com website
4. Copy an item that you like into your own "Birthday Wishlist" wishdex

Usability Problems Found

Severity	Description of Problem	Possible Solutions
Cosmetic	Finding Wishdex.com - One user went to wishdecks.com instead of wishdex.com.	Buy both domains
Minor	Log In - One had deactivated her Facebook account. She had also let a friend log into Facebook on her computer, so she had to log that friend out first.	Allow users to create an account and then later possibly link to Facebook.
Major	Log In - Two users were reluctant to sign on using Facebook Connect. We had to reassure them that we were only pulling their full name and their profile picture.	Put a tooltip near the login with a disclaimer that we will not interfere with their Facebook lives or take any personal information.
Catastrophic	Add Item - One of our users accessed the Anthropologie UK site. Although the item information scraping code works for the US site, it failed for the UK site.	We need to improve the scraping system immensely. This was a warning that unexpected things will break. We should look into APIs and smarter ways to get item data.
Cosmetic	Edit Item - Every time the user edited the item description, an extra space automatically appeared at the beginning of the item description.	This is clearly a bug. We need to look at the code and if necessary strip the space on the frontend.
Minor	Share Wishdex - With an item box open, it was difficult to find the "Share Wishdex" button. Many first tried "Item Link."	Ideally, users should be able to share individual items as well as entire Wishdexes. The backend functionality is already built in, we just need to add a button.
Minor	Share Wishdex - Users clicked on the Share link a few times. They expected more to happen.	We should implement automatic selection and copy pasting, with a tooltip that says "copied."
Catastrophic	Viewing - A user tried to click on the user's icon next to their comment. However, clicking on their name/image currently does not do anything. This can be potentially confusing or inconvenient for the user.	We can make the user's icon link to that user's Wishdex profile page.
Major	Move Item - The user clicked on an item and tried to drag it into another Wishdex on the left navigation.	We should implement drag and drop to move items into other Wishdexes.
Cosmetic	Copy item - Copy item is what we label the button used for the user to copy an item into one of their Wishdexes. The user found "copy" to be a misleading word. She said it implied copy and pasting, such as with a link.	We thought of changing the word "Copy" into the word "Add" with an icon that matched the "Add Item" icon, so maybe users will associate it with adding an item to their own Wishdex.
Major	Like Item - Two users wanted to see who else had liked an item.	We should implement this.
Minor	Copy Item - After copying an item from another user's Wishdex into his own Wishdex, the user was redirected to his Wishdex. He said it would be nice to stay on the friend's page.	We are not convinced that all users will feel this way. We would probably run a slightly bigger test to see what people prefer, or maybe implement some way of giving users a choice.
Cosmetic	Move Item - A user tried to add an item from a different Wishdex by clicking on "Add Item" in the new wishdex.	We felt that drag and drop would probably clear up the confusing around moving items between Wishdexes immensely. We want to avoid implementing this too many times.
Cosmetic	Explore - One user avoided hovering over the items on the Explore page. Instead, she pressed the arrows on the sides and did not discover the hover function.	One suggestion is to have a tool tip over the items the first time a user visits, telling them to hover over the items. Once a user tries this once, they often remember it.
Cosmetic	Claim - When trying to go to the item's webpage, one user first thought of clicking the item name. She was hesitant to click "Buy" because she wasn't sure if it would immediately go to the buying page.	We are considering changing the word "Buy" into something more informative, or having the tooltip be visible by default.

Reflection

The iterative design process was a very rewarding learning experience. The following explains the most important things we learned from each of the phases (corresponding to the GRs), and what we would do differently.

Project Proposal and Analysis

This phase showed us the importance of developing a clear idea of what we wanted our project to be before we started working on it. User, task, and domain analysis ended up being useful techniques to thinking deeply about the features and scope of the problem we were trying to solve.

If we were to do this phase again, we would try to even more clearly delineate the tasks involved in our project. Although we eventually fixed this, our original attempt at this phase did not produce concrete enough descriptions of each of the tasks. Some reduction of the number of tasks here probably could have helped us focus on building an interface that does a few tasks very well.

Designs

This phase was significant in realizing that developing the full chain of events a user would go through in using an interface aids thinking about how to maximize usability. Also, resisting the urge to make initial designs too detailed was a difficult but, in the end, important skill to learn.

Spending more time developing ideas for the designs individually before coming together would have been a useful modification in this phase. Our project may have turned out more creative if we had gone through longer iterations of working separately and as a team on the designs.

Paper Prototyping

As our first interaction with user testing, this phase helped us realize that showing an interface, regardless of how close it is in look and feel to the actual product, is much better method of figuring out how to improve the interface than critiquing it on our own.

Trying to make our prototype more similar in how actions would be performed to what we wanted the final version to be would have been useful in this phase. Usability problems that we had to deal with later could have been found here.

Computer Prototyping

This phase taught us the importance of not becoming attached to the initial version of the interface. Realizing that the initial versions are meant to be scrapped helped in thinking openly about improvements, both before and after the prototype was shown to users.

Devoting some time at the beginning of this phase for developing some structure for the prototype would have made iterating on it easier. Even the prototype should first be planned before coding begins.

Implementation

The implementation phase showed us the complexity of building even a seemingly simple interface. The various dependencies between building frontend and backend were difficult to cope with at first, and figuring out how to properly divide tasks even among three people was a good learning experience.

More planning before we started working on this portion would have been beneficial. In particular, deciding from the start the order in which the various features would be implemented and by whom would have reduced problematic dependencies later on.

User Testing

The final user tests was a reminder that new usability problems can constantly be discovered, even after a product seems polished. In addition, it showed us that different users always find different problems, so testing with a diverse group is important.

More development of the briefing and tasks could have helped to make this phase run more smoothly.

Child pages