Page History

Design

Screenshot	Feature
Image Added	1. The Home Page We were motivated by the paper prototypes to have a home page that serves as a tutorial for the

As usual, be complete, deep, and concise. Tidy up your entire wiki to make it a usable presentation of your term project. If your project changed direction or scope over the course of the semester, update earlier sections (such as the original Problem section you wrote for GR1) to reflect your final project.

Design

Screenshot	Feature
Image Removed	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.
Image Modified	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 uers 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 faciliate the facilitate the deleting process. Our computer prototype had no deleting functionality, and the heuristic evaluations reflected this.
	7. Item information editing Clearly labled 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.
Image Modified	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 seemlessly 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.
Image Modified	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.

...

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

Discuss what you learned over the course of the The iterative design process . If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observationswas 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

Versions Compared

Old Version 16

New Version Current

Key

Design

Implementation

Reflection