StyleShare+Final+Report

**Introduction**  People tend to spend a lot of money on fashion and on organization. Style Share tries to bring the two together to help people match the clothes they have in new ways and to share and find fashion ideas.The system is designed to link articles of clothes together for a visual look to match clothes - people no longer have to physically get all of their clothes out to compare which looks best with which! With this application, users can spend their time more efficiently by doing the whole process from anywhere they can access the internet. Users can simply add friends, find clothing in our system, put it together in the form of an outfit, then save and/or share it with their friends. Others can search for these outfits in a number of ways and either modify them or simply steal the idea for their own. User interactions are potentially tracked in this process to give feedback; outfits can become popular or unfavored through a 'liking' system, and can be recommended to friends with the click of a button.

**Credits**  Throughout the project, a ll decisions were made after consulting with everyone in the team. At each phase we initially distributed tasks to each member based on expertise or volunteering. Equality of the division was done on the basis of time spent working, and consequently, everyone worked roughly equal hours through the development process. Each of the write-ups and reports were divided in this way, as well as the software engineering. The heaviest work, consisting of everything done collectively to create the final prototype, was done as follows:

[]
 *  Zach Boldyga was responsible for essentially all of the Javascript database work throughout the website. This includes management files available at:


 * Lauren Ficco created much of the current visual interface, working from a template that the group created earlier and adding changes and fixes to satisfy the feedback from the usability tests.

**Audience**  Audience was a broad topic that was intentionally left as such when we pursued Style Share. The original intention of the project was to tend to twenty-somethings and thirty-somethings “as these tend to be the years in which most people are concerned about their image and experiment with their style”. We did not offer any proof of this guess and was based primarily off of everyday observations of peers. The issue of economic class was not originally addressed and one cited model of using UPCs would have encouraged people to create outfits from clothes only they owned. The set-up that ended up being developed did not concentrate on the use of UPCs at all and clothing would be added to a database by the administration of the website. This offered a different emphasis and mental model of “owned clothing”; no longer did a user need to have something in their closet. With this new development, the economic class is only as limited as Internet access. The visual representation of the site was the part of the project that really kept a younger age bracket in mind as part of the final product. Brighter colors took over the black and white palette as this was thought to be more hip and potentially attractive to the age range. This decision was not based on fact, but rather a perceived understanding of the group member’s own aesthetics and that of their peers, which constitute a good representation of the intended audience.
 * Aisya Aziz mainly worked somewhere between the two extremes, focusing on the layout of various pages, and contributing to the settings, messages and notifications pages.

 Many users from the bracket of our intended audience have seen the movie “Clueless” and Cher’s closet became a competitor. In our Proposal, we actually posted a link to Cher’s closet as this was the vision of what our product could be. Although a clip only a few seconds long and on what could be colloquially considered a prehistoric machine now, Cher’s virtual closet set out the basics of the competition. We would want users to be able to sort through the clothing they own to see how objects match. Cher’s closet also featured 3D modeling, which our group immediately decided not to pursue. Although much of our research during the User Needs stage related to this concept, it was something the group determined to be out of reach for our time constraints. Instead it was chosen that our group would model the simplistic design that Cher’s closet portrayed as this would be easier to model for a website.

**Competitive Solutions & Deficiencies**  Belief of applicable competitive solutions changed throughout the project as the project became something different. The majority of desktop software was never considered to be a competitive solution as our group began Style Share with the intent of bringing the social side to our project. Most solutions that involve a desktop-based program are for personalized management of clothing and do not draw on other users. Also, our group would most likely not be able to duplicate the computing power that provided these programs with more data-rich results with our web-based focus. Applications for phones, specifically, the iPhone were also looked at. This genre of virtual closets was believed to solve a comparative solution to our group. In the original thought that users would be able to scan bar codes to directly add their own clothes, the iPhone’s integrated use of a camera was able to spike a bit of jealousy. Among the group we discussed that users would most likely not be willing to type in many long stream numbers and developing a bar code scanner utilizing a web camera might be out of our scope. The technology of the apps, which could implement a pre-exisiting API for the built-in cameras, was something we could not directly compete with. This was a contributing factor into why the group decided to move away from the use of UPCs. However, we did enjoy the sleek and simple set-up for this style of closets and was something we tried to emulate in early sketches of the user interface.

 The final but most directly related competitive solution that already existed of our problem of organizing clothes in a digital fashion was other virtual closet websites. From observations, it seems that many websites lack sophisticated technology altogether, or instead look likely to employ a team of developers, with very few sites in between. The desired competition was to compete with the high-end sites, but soon, the limitations of our project held us back from this.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> “Clothia” was the strongest of our competition, and according to a self-made description, appeared to have many of the features we desired. If the group had more time to work, we could have produced endless bells and whistles at the scale of Clothia's implementation. Unfortunately they supposedly employ 4 developers and 1 UX/UI specialist ([]), making competition tough. Our group had, at its peak, four members with a relatively small number of hours to contribute each week. Given the time frame we had, and without learning a great amount of code, Style Share could not become as polished as Clothia. We couldn't utilize a web camera with motion detection controlled options, and also had to ignore a large portion of potential competitive additions due to time and educational constraints.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%;">**Solution** <span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> As touched on previously, Style Share proposed its solution in a web context. We knew there were major points we wanted to emphasize through the design. We wanted to equally weight the importance of people, clothing, and outfits. We also wanted to provide a search for each of these classes of nodes, with results that would make them easy to identify (hopefully image based). Lastly, we wanted to allow any given user to be able to 'own' items to give them more creative power and loosen the boundaries around their thoughts and ideas. The layout of our website is the direct result of these features.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> Given the design we wanted, we knew at the beginning that we would need some sort of server in order to manage all clothing content and personalized clothing content per user. Our original plan was to use a MySQL server and PHP code, but this did not become tangible as our resources were limited. As a secondary solution, our group used the database developed by the RESTful web service. This JSON and jQuery database does have some inherent problems, but allowed a narrow category for our proposed solution to still exist. According to our planned User Needs, required implementations mandated a database for all clothing on the website and individualized clothing per user. This User Need was satisfied through the creation of five databases: Clothing (all individual clothing items on the site), Outfit (all outfits created or assembled on the site, private or not), Users (all users of the site), UserClothing (individual clothing per user), and Outfit-User (individual outfits assembled by each user). Additional databases were created to add bells and whistles to the bare system.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> Each database was controlled by its own interface located at:

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> []

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> The managerial site is a simple table that supports adding, editing, and deleting of entries. Each individual clothing article, user, and assembled outfit is assigned its own identification number. In order to figure out the personalized items, such as which outfits or clothing has been added to “My Closet” by one user, the identification numbers are linked in the user-specific databases. The linking of individualized numbers can be thought of as a Undirected Graph. When saving a specific outfit, this can be thought of as a Directed Graph where one individual outfit contained pointers to the individual clothing items contained in it. Friends were managed in the same fashion with the UserUser database linking users who had friend connections. The additional databases follow this format and the choice of tables should be evident to anyone with knowledge of database theory.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> Designing an outfit is where many of the solutions to a virtual closet differ. As referenced previously, some competitors are able to use 3D modeling, a web camera, sophisticated image manipulation, or just user-submitted pictures of clothing. Style Share had to decide from several potential options, the first of which was that all clothes would be administratively added to the database. Originally, we believed that we would be able to use an API that would interpret a UPC. Then, we figured we could develop a parser that would go to the clothing developer’s website and pull an image. When this could not be done, the user would be able to add their own picture. As our solution was trying to market towards a more sophisticated selection of the general audience, the self-taken-picture with its possibly unappealing background was quickly ruled out. If clothing was added to the database by administrators, then Style Share would not have to worry about variable images as they could be loaded in a controlled and formatted manner. Similarly, UPCs would no longer be of an extreme concern as user’s could compare to how their clothes matched visually.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> The second decision made in regards to editing or creating an outfit was how to display clothing on the body. Early it was determined that clothing could not truly be “fit” onto a virtual body due to technical limitations. Several group members proposed ideas and the final solution was a blend of all. The edit page would space things out as a body was permitted with a controlled amount of clothing that can be added to the various layers. It was reasoned that a user could potentially want to wear two different things on his or her head, three layers of tops, two layers of bottom clothing, one layer of shoes, and four possible accessories.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> A diagram that explains the website through screen shots and a flow chart can be found at:

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> []

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> We designed the website in a way such that we felt that it did not require help files or a tutorial. There was minimal literature added within the site itself in the final phase to help provide guidance, but generally speaking we followed the design styles of popular websites to make the website as intuitive as possible. Based on the user studies, we found that those with experience in internet shopping understood the site with ease.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%;">**Usability Study** <span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> After assessing our user needs, we prepared a set of tasks, with a mix of simple and challenging ones, to analyze the interaction of the users with our application. Before the test began, the subjects were asked to answer some pre-test questions for us to know the social characteristics of the subjects being tested. They were also reminded specifically that the interactions were tested - not them. After the subject completed all the tasks, they were given a set of post-test questions that determined the difficulty of iterating through the tasks and the level of comfort with the website. Most of our subjects were in their early twenties, and all of them spent at least several hours per week on the Internet - which concludes that they fall into our realm of target users.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> The problem that appeared in most subjects results was the inability of our ‘Edit/Create Outfit’ to visually reflect the subject’s mental model. Since this is one of our core components in the website, it was very important for us to overcome this problem. The images were also not displayed in a way such that they could be clicked by intuition. Throughout the test, a number of subjects were confused with the images - users weren't sure whether or not they were clickable and what kind of information they would provide. Apart from that, although most subjects agreed that the site makes them feel comfortable, the subjects suggested that we should make the website more appealing and for us to improve the visual aesthetic of the website since it was less attractive at the moment. Overall, after analyzing the problems, we found that our pages did not properly implement the ideas that we attempted to utilize from other websites or software products. For this reason, we were not able to properly use the intuition of our users.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> In order to solve these problems, we decided upon some changes and improvements to our pages. One major focus was on the Create and Edit Outfit page. In the prototype we used for the usability study, our page contained mainly just place holders for each item, without an indication of what the blank boxes were for. We found that the subjects tended to always click on the place holders to get some information - when nothing happens, they thought that the page was either not working or they were in the wrong page and decided to navigate to other pages. Hence, we added a ‘help pop-up’ which provides tips for users to actually check out at their ‘My’ section (‘My’ section is a place holder for clothes or outfits that the logged in user has). A similar problem was solved with the click-ability of the images in search results by changing their CSS roll-over properties. Besides that, to make our website become more attractive, we also improved the layout of the website - instead of sticking to a black and white layout, we decided on using blue and yellow as our color theme. We also redesigned our top menu for them to be more visible to users - the buttons are more prominent and we have also included the ‘Create new outfit’ button in the menu for ease of navigation since it is one of the main things users would like to do when they log in. <span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%;">**Issues** <span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> Although we tried hard to make the project meet all of our expectations, we found that there are still limitations to what we could do. In our proposal, we mentioned that we would use UPCs to ease users to add their clothes - so that they won’t have to provide information and take pictures of the clothes they have. However, there are two down-sides of this; the user would probably have lost their UPCs and even if they do, the UPCs don’t provide pictures and to integrate it with our current database will probably require much more time than we have for this project. Aside from that, our search engine to browse through clothes didn't come together in a reasonable amount of time. Apart from having less details on each items, we were concentrating more on the functionalities and interface of the websites than the data themselves, hence we set the search engines at a lower priority.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> We also decided to opt out the sales concept of our website (suggest places you can buy the clothes at) because of our database limitation and time constrain. Since we are using Tuples as our database, hence javaScript as our main programming language, we find that it limits us to what we could do - and if we have a large number of users, it will be time consuming to get the data that we need. It will definitely cause a lot of problems in long term. Because of the time constrain, we haven’t really focused on the security of the web page.

<span style="color: #000000; font-family: Arial,Helvetica,sans-serif; font-size: 120%; text-decoration: none;"> If we were to continue with the project, we would probably change our database - from tuples and javaScript to something more like MySQL or Ms SQL. Besides, we will also try to figure out a way to solve the UPC problem as we think it’ll probably be essential for users to be able to key in their UPC number. Our next step will probably involve more of a user-friendly environment where user would be able to find clothes they have and are thinking of buying in order to match them with clothes they already have to see if they should buy them. For our business strategy, we find that the sales concept of suggesting clothes of similar looks, cheaper price or some of better materials will allow developers to generate incomes from the websites. Lastly, we would love to make an iPhone application or an Android application because we find it will be more useful and will serve it’s purpose more. Users will be able to mix match while doing real shopping (without having to bring their entire wardrobe with them!). Or even just on the bus, while he or she is doing nothing.