Page History

Uploading wardrobe

In order to upload his wardrobe, Sylvester uses the online interface.  He signs onto the website and is presented with the homepage.  The most prominent part of the page is a list of recent requests by friends, everyone, and himself.  He selects the button "Add to Wardrobe" from the right pane. This differs from the previous two design in that it is a web interface, not a mobile one.

He is brought to a page where he can add photos of clothing he has taken and has on his computer's hard drive.  After he is done uploading his photos, he is brought to a page where he can tag different items of clothing.  He can both tag with text descriptors and with visual preset tags (shirt, pants, dress, etc.) This screen is the same as in the last part of "Uploading Wardrobe" in part 1, used to tag items.

Using this web interface for taking pictures relies heavily on existing photo interfaces. Assuming that the user can bring photos to his or her computer, our application follows many conventions, creating a system with high learnability and good efficiency, but weak safety. Initially, the unpopulated wardrobe prompts the user for input, creating learnable interactions. Browsing for photos uses existing web browser upload interfaces, increasing learnability and efficiency for those familiar with those systems. Uploaded images are associated with a set of tags and an icon indicating which part of the wardrobe it falls into: the strong affordances and familiarity here also correspond to an efficient, learnable interface. All changes to items in the wardrobe are saved on-the-fly and can be updated, but items added to the wardrobe cannot be removed completely - not the safest of designs.

Requesting advice

When done uploading photos, Sylvester is brought back to the home screen.  There he types 'What should I wear to impress a girl?' in the Ask bar at the top of the page and selects "Continue". He is then brought to a page where he can tag his request. Some recommended tags based on the context of his request and the context of past requests similar are presented on the page.  Sylvester chooses some tags from the preselected options by clicking on them and they are automatically added to the tags line.  He then hits "Submit" and his request is put on the site.

Requesting advice on this web interface is a slightly more complex process than in previous iterations. This approach is more learnable, while having good efficiency and moderate safety. The main page follows the design of Yahoo Answers, increasing consistency in the hopes of boosting learnability. Upon continuing, the user can update and modify the question, as well as offer specific details and tags. All options are apparent and distinct from one another, making all options learnable. The ability to skip through with the bare minimum information improves efficiency. Again, while any steps taken along the path between starting a request and submitting it can be reversed, once a request has been made, it lives in the request space forever, limiting the safety of the system.

Browsing requests

(Note: This interface is almost same as in Design 2. The storyboard is copied here for better readability.)

Felicity and Sylvester visit the homepage.  They see Sylvester's request at the top of the list under both the "Friends" and "Everyone" tabs (for Sylvester his is also shown under the "Me" tab).  Requests are organized by date added, most recent at the top of the list.  In addition to being able to browse requests by date added on the front page, Sylvester and Felicity can find requests using other search venues as well.  Most notably, they can select the "Answer" button on the top middle of the screen to go to a page where requests are sorted by genre/type.  They could also use the right pane to see recommended advice posts based on request/advice history, and can use the search bar to search for requests.  The search algorithm takes into account both matching search terms with exact words in the request and search terms that match request tags. 

Felicity chooses his request and is brought to a page where she can see recent comments and outfits, and is presented with the opportunity to comment as well as create a new outfit. Here, Sylvester and Felicity can up and down vote different outfits that have already been created. (Note:  The top request in the mockup above is a request about a wedding.  In this specific scenario, advice would be requested by Sylvester and be about his new outfit to woo the girl).  

This interface offers the same behavior as the browsing mechanics found in Design 2. The analysis is therefore very similar, with the additional benefit here of staying within the same interface instead of swapping from mobile app to web app (increasing consistency, thereby increasing learnability). The full discussion is replicated here for completeness:

Browsing other users' requests uses the web interface. This new web interface focuses on increasing consistency with other interfaces already in existence. This change improves the ability to search requests in a variety of ways: efficiency benefits, but learnability loses out as a result. With more ways to search (by tag, using the top button, or by suggestions based on past answers given, or by scrolling through requests in the main pane), finding particular questions is far easier for users. Learning the functionality of these options is not obvious, however, and requires some experimentation for a user to learn. All of these search and browse options are thoroughly safe: all actions can be reverted easily.

Creating an outfit

Felicity selects "Answer" on the comment page, and is brought to the outfit select page.  There she is able to add items to the wardrobe.  The right panel is where Sylvester's wardrobe is presented.  Felicity narrows down the wardrobe selection by searching for tags.  If no tags are being searched for, Sylvester's entire wardrobe would be presented.  

In order to add items of clothing to the 'outfit', Felicity drags items from the right pane directly into the window in the middle of the page.  She has freedom to place items anywhere she wants on the page.  Each item has a clickable box on the upper right.  When clicked, a window appears where Felicity can add comments about how an item should be worn, where, why, etc.  When finishing putting together the outfit, Felicity selects "Done".

This menu is a simpler implementation of our first menu, in certain respects, cutting down on sidebars. The system also incorporates searching by tags, allowing for more efficient access to particular items the user wants. The canvas space is more free-form in this design, decreasing the learnability some (it's less clear how to make a good outfit and submit it). The increased efficiency, however, means that dragging and dropping important articles that don't really need arrangement can be done rapidly. Safety remains largely the same: any changes made can be reverted while working on the response, but once submitted cannot be edited or removed.

Browsing a response to a previous request

(Note: This interface is almost the same as in Design 1. The storyboard is copied here for better readability.)
In order to browse answers to his own requests, Sylvester can visit the page for his request as shown earlier in the storyboard under "Browsing requests."   When an answer is selected (the thumbnail clicked), a window opens with a larger view of the outfit. 

The interface doesn't change after a user has made a response; the analysis of the browsing structure is repeated here for completeness:

Browsing other users' requests uses the web interface. This new web interface focuses on increasing consistency with other interfaces already in existence. This change improves the ability to search requests in a variety of ways: efficiency benefits, but learnability loses out as a result. With more ways to search (by tag, using the top button, or by suggestions based on past answers given, or by scrolling through requests in the main pane), finding particular questions is far easier for users. Learning the functionality of these options is not obvious, however, and requires some experimentation for a user to learn. All of these search and browse options are thoroughly safe: all actions can be reverted easily.