Uploading wardrobe

In order to upload his wardrobe, Sylvester uses the mobile application.  When he opens the application he is presented with the sign in page (if he wanted to register he would have had to have done so on the website).  Upon signing in, he is brought to the phone's proprietary camera interface.  He takes a photo of an item of clothing, and is brought to a page with a thumbnail of the image and the option to accept or retake the photo. No matter what he selects, he is directed back to the camera.  If he chooses "Upload" the photo is uploaded to his account, and if he chooses "Retake" the image is discarded.

When he is done taking photos and uploading them using the mobile application, Sylvester opens up the homepage of the site on his computer's web browser. He chooses "Add to Wardrobe" and is directed to a page with all of his clothing that has been uploaded to the website.  When he selects an item of clothing, he is able to tag it both by adding text tags and by selecting predetermined 'visual' tags (such as shirt, dress, neckwear, etc.)  When finished, Sylvester selects 'Done' and is brought back to the homepage.

This mobile app for taking pictures offers some strong learnability, has good safety, but lacks efficiency. The mobile app is separate from the web app, which can be confusing, but otherwise takes advantages of previously used interfaces: we use the built-in camera phone interface, and limit the options to a few, clearly labeled buttons. While an uploaded item cannot be taken out of the wardrobe on the mobile app, any poorly taken pictures can be discarded and redone. The biggest problems are in the efficiency: each picture requires multiple steps to be uploaded, and must later be tagged in the web app. While some of this inefficiency cannot be removed under current constraints (each article of clothing needs a distinct image for use, after all), it is noteworthy.

Requesting advice

On the homepage, Sylvester chooses "Ask For Advice" and a simple window pops up where he can request advice and add details to give context for the request.  He requests for advice about what he should wear to impress the girl, adds a few details about the girl, and hits "Ask".

Requesting advice on this web interface is fairly straightforward. The system is learnable, fairly efficient, but not very safe. The button to access the requesting advice page is well labeled and has strong affordance, but is similar to other buttons on the page and therefore doesn't scan differently than the other buttons. The request interface itself is very simple, with two text fields and two buttons. The lack of tagging makes it very efficient to make a request, and a user can make as many requests as they have with ease. However, once a user commits a request to the system, it cannot be removed: requests will exist in the system indefinitely in this design.

Browsing requests

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.  Because the system relies on a scenario with quick turn around, we have prioritized organizing by date submitted in order to encourage people to post advice on the most recent requests.

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).  

Browsing requests on this web interface is very learnable, very safe, but only moderately efficient. The main page dedicates much of the screen real-estate to the scrollable list of requests, each of which pops when moused over. Clicking on the highlighted request moves to the specific request's page - strong affordances here improve the learnability. The request's page has limited options on the page, as well as a familiar scrolling window and up/down vote mechanics for rating existing responses. Moving about the browsing regions (forwards and backwards) is easy and reversible, guaranteeing safety. Efficiency is compromised by a lack of tagging in the previous section, as there is now no easy way to sort through the list of requests. Efficiency at looking through responses is a little better, as they are ranked by popularity (net number of up votes), but still lacks an efficient searching mechanism.

Creating an outfit

Felicity selects "Answer" on the comment page, and is brought to the outfit creation page.  There she is able to add items to the wardrobe.  The left panel is a selection of labels, organized and presented entirely visually.  Types of clothing include items like t-shirts, dresses, neckties, etc.  When she selects to narrow by a filter, the rightmost pane displays all items in Sylvester's wardrobe that fall under that category.  In this example, she has narrowed down the selection to neckwear.   

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.  A male 'mannequin' is the centerpiece as a reference point.  When she drags an item to a part of the body, that part of the body glows.  When the item is released, it is locked in and an arrow is drawn connecting the article of clothing with the body part.

When she is done assembling the outfit, Felicity selects 'Done'.

Creating an outfit with the web interface is a task that is mixed in all of its qualities: some elements are learnable, others are efficient, and others still are safe, but nothing really provides everything desired at once. Articles of clothing are sorted by part of the body, and are dragged to that part of the mannequin to show to others, which is learnable. There is also continuous visual representation of the drag & drop actions, informing users of exactly what actions they are taking. However, viewing parts of the wardrobe with each of the icons on the other side is not immediately obvious - the interaction isn't learnable. Similarly, the inability to show layered clothing breaks the continuous representation down. The process of creating an outfit involves many steps, all of which are easily reversed (clothing can be deleted easily, different menus can be opened with a single click), making the system safe in the short run. But once the response is posted, it is static - updating and deletion isn't applied yet, reducing safety in the long run. The lack of shortcuts and other efficiency-increasing elements means that behavior is fairly static - once the menus can be navigated competently, an expert user won't find additional efficiency in this design.

Browsing a response to a previous request

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 requests on this web interface is very learnable, very safe, but only moderately efficient. The main page dedicates much of the screen real-estate to the scrollable list of requests, each of which pops when moused over. clicking on the highlighted request moves to the specific request's page - strong affordances here improve the learnability. The request's page has limited options on the page, as well as a familiar scrolling window and up/down vote mechanics for rating existing responses. Moving about the browsing regions (forwards and backwards) is easy and reversible, guaranteeing safety. Efficiency is compromised by a lack of tagging in the previous section, as there is now no easy way to sort through the list of requests. Efficiency at looking through responses is a little better, as they are ranked by popularity (net number of up votes), but still lacks an efficient searching mechanism.

Uploading wardrobe

In order to upload his wardrobe, Sylvester uses the mobile application.  He registers using the mobile application (he could have also done so directly on the website).  Upon signing in, he is brought to the page where he can choose to a) add clothing to his wardrobe b) request advice on the website c) view requests he has made in the past.  He chooses Add Wardrobe and is immediately brought to the phone's proprietary camera interface.  He takes a photo of an item of clothing, and is brought to a page with a thumbnail of the image and the option to accept or retake the photo.  If he chooses accept, he is brought to a screen where he can tag the piece of clothing.  At the very least, he must use the visual icons to tag the type of article of clothing (t-shirt, dress, shoes, etc.).  He also has the option to add verbal tags that describe the article of clothing in more detail (purple, striped, etc). If he chooses to retake the photo, he is taken back to the camera screen.

Using a more complex moblie interface, we allow the user to have more options at the start of the process. This leads to increased efficiency at the cost of learnability; safety is moderate. The ability to add to the wardrobe is one of a few buttons now, but followed by the familiar proprietary phone interface. The follow-up of the image now incorporates a tagging mechanism: properly labeling  the wardrobe here removes strain from the web interface, making the  whole labeling process happen in one place for improved learnability and efficiency. The tagging supports other efficient behavior later. The ability to retake photos provides safety during the process, but items added to the wardrobe cannot be removed once they are added.

Requesting advice

After adding clothes to his wardrobe and selecting 'Done', Sylvester is brought back to the menu page where he selects "Ask for Advice".  He is brought to a simple page in the application where he can request advice and provide details. Sylvester fills in a request for advice and a few details about his target girl and upon hitting "Submit," Sylvester's request is immediately posted to the website.

On the same mobile interface, access to requesting advice makes for an extremely efficient and learnable process, without much safety consideration. The two text fields of our web application are replicated here, making for an interaction that emphasizes simplicity above all else. This makes for efficient, learnable behavior. Again, while a request can be cancelled during the creation of the request (by pressing the back button of the phone), any submitted request cannot be removed.

Browsing requests

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. 

 (Note: This interface is similar to the same as in Design 1 regarding browsing requests. The storyboard is copied here for better readability) 


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). 

On the same mobile interface, access to requesting advice makes for an extremely efficient and learnable process, without much safety consideration. The two text fields of our web application are replicated here, making for an interaction that emphasizes simplicity above all else. This makes for efficient, learnable behavior. Again, while a request can be cancelled during the creation of the request (by pressing the back button of the phone), any submitted request cannot be removed.

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.  When she selects "Add Item", a window pops up where she is able to filter Sylvester's wardrobe using visual icons.  When she selects an item, she is then brought back to the wardrobe assembling screen, where she is able to directly comment on each article of clothing to explain why she chose it, how it should be worn, etc. This differs from the first design in that the item cannot be physically manipulated on the screen.

This outfit creation format focuses on creating a more straightforward, efficient interface; learnability is also good, while safety is low. Adding items has very few steps, all of which are clearly labeled and easy to follow. The comments fields are optional, improving efficiency. The articles of clothing are also sorted by tags (determined when clothes are added to the interface), further improving efficiency. The lack of full figure vision makes understanding the end result harder, reducing learnability. Individual articles and comments can be removed, but modifying the outfit after submission is not supported, reducing safety.

Browsing a response to a previous request

Sylvester gets a notification on his phone and notices that several people have suggested outfits for him.  He uses the mobile application to open up his list of previously asked personal requests, and selects the request about how to impress the cute girl.  He scrolls through the items in the outfit created by his friend Felicity by scrolling up and down. By scrolling left and right, he can view other outfit creations by users he has never met.

Requests that a user posts can be browsed on the mobile app, using the third option. This interface offers additional efficiency to users, while still being learnable and safe. The quick visibility of responses vastly improves efficiency for users. The simplicity of options makes for a learnable interface, and the stateless approach to browsing makes actions safe (every forward step can be reversed).

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 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.