Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

Jeffrey Chan, Ryan Lacey, Amruth Venkatraman

Design

YourTurn is composed of the following webpages:

Home

Give

Find

Messages

About

as well as this sitewide content:

Login / Registration


Implementation

Overview

Your Turn was developed in a Windows OS for Google Chrome users. The front-end was built off HTML5 and Javascript/jQuery. The look and feel of the website was built off of Twitter Bootstrap (http://twitter.github.io/bootstrap/). PHP was used to manage the backend for managing server code (storing and fetching information stored in a SQL database hosted by MIT SQL Scripts.

Design Decisions

Toy Donation

The toy donation page uses a simple form submissions interface. Users fill out a duplicated form for each toy they want to submit. The different toys being submitted at the same time are managed by using a Bootstrap "Tabbed-pane" to persist information filled in while tabs are cycled through and hidden. A photo linking system is used to let users upload a photo to submit along with their toy. When the submit button is pressed without all of the information for a toy filled in, Bootstrap error notifications are shown to notify users what went wrong with their submission process. On pressing submit after properly filling out the form, the user is taken back to the Home page, signifying that they are "done" submitting a toy. One tradeoff this forces is that upon first use of the website when a user, who doesn't read the form, presses submit when he/she meant to add another toy, he/she must redirect back to the Give page to continue the toy process. On form submission the data is pushed to a SQL server.

Finding a Toy

The "Find" page uses a layout that emulates external shopping websites with the notion of filtering by categories, ages, and searching. Each of the categories have checkbox click handlers that register the categories still selected. There are also age and search filters that on selection or submission update the results showed. Every time one of the filtering options change, a compound SQL statement is issued by an AJAX POST call to the SQL server, which returns a serialized list of the matched toys in the system. 

Once a user presses a toy for more details, a hidden modal pops up with the details of the toy filled in. On pressing escape or clicking out of the modal, the modal disappears and the user can go back to browsing. In the modal view, the user can press the "Message Owner" and is then directed to the messages page. Alternately the user can press "Add to Cart". After pressing this button, an alert pops up notifying the user that he either has too many toys in his cart or that it was successfully added. 

Checkout System

The checkout system happens through a series of modals. On pressing view cart, a modal pops up with the entire cart contents with the option of removing them by a simple click of the X near the toy name. On pressing checkout another modal pops up with a Bootstrap tabbed-pane. There is a tab and textarea for each of the toys being requested with the tabs populated by the toy name. When the user presses "Send Message" the message is sent to the SQL server with feedback given to the user. 

Messaging

Messaging works in a simple manner as well. The database is polled by the user's username and the usernames of those he most recently communicated with. The results are then pushed to the page in a well where the user can type replies and have his view updated by simple jQuery and updated in the database by AJAX calls.

Tradeoffs

The choice of using SQL Scripts as our server host lead to a couple unexpected consequences. Even on a small toy listing, running a query to the server and fetching the results takes a lot more time than expected. This is a result specific to SQL Scripts, and unfortunately this meant that users are left waiting for their messages and toys to load. To deal with this problem a loading animation could have been added but this complication was not forseen. Other implementation choices like using PHP over RoR meant that a lot of messy hacks had to be done to get desired results. Alternately some PHP frameworks could have been used. 


Evaluation

Our briefing and user tasks required little change from GR3 as our implementation kept close to our original design. They have been rewritten and slightly revised below for reference.

Briefing

Thank you for volunteering to test our website. We're working on a design for 6.813 and believe that your feedback will help us revise our design to be more intuitive and easy to use.

Our site, Your Turn, is a toy exchange website. Imagine you're middle aged man (or woman, depending) whose daughter, Susie, has an upcoming birthday. Susie has grown out of a lot of her old dolls and trading cards, so now they're wasting storage space. You decide to donate the unused toys and want to find something nice for Susie's birthday. You recognize that she has been talking about wanting to learn how to play an instrument a lot lately.

We'll provide you with a couple tasks to try to accomplish, but feel free to explore the space. We encourage you to talk aloud as you navigate the site, especially if you find something confusing or peculiar. And don't worry about trying to find "the right way" to do things. We are testing our site, not you, so any troubles you encounter reflect a flaw in our design. Your test results will be kept confidential. Feel free to stop at any time.

Tasks

  • List donations on website.
  • Search for a nice gift for Susie's birthday.
  • Check messages to see if anyone has responded to your listing.

Users

User 1
  • Problem(Cosmetic): Wished the action items on the front page were bigger.
    • Solution: Make bigger Give and Find buttons.
  • Problem(Minor): Finding an image was frustrating. Preferred it not be required.
    • Solution: Remove it from the requirements for submitting.
  • Problem(Minor): Messages loaded too slow and got confused
    • Solution: Create a loading page.
  • Problem(Cosmetic): Logo at the bottom looked like a button.
    • Solution: Make the entire footer a different color.
  • Problem(Cosmetic): Reminder text to login or register was too small.
    • Solution: Make the text larger.
User 2
  • Problem(Minor): Wanted to save the toy listing information that he entered before adding another toy.
    • Solution: Create text that says information saved at some timestamp.
  • Problem(Major): Didn't know initially that toy descriptions are mandatory.
    • Solution: Include asterisks marking which fields are required.
User 3
  • Problem(Cosmetic): Found the font too childish.
    • Solution: Switch to a more standard web font.
  • Problem(Major): On the find page, toys for all ages only shows the toys that were selected as all ages rather than all possible ages.
    • Solution: Switch all ages to not filter any by age.
  • Problem(Minor): Wished that the search feature allowed for partial searches and wildcards.
    • Solution: Include search for partial strings.

Reflection

In our design process, we were worried that our website would not be robust enough with features and during the design process was wondering whether our website had enough functionality. However, we had decided to reduce a lot of the features initially and build on it later if necessary. Fortunately, we found that the additional features would have probably muddled the design and taken away from the overall user experience. The reduced feature set allowed to tailor the user experience to a very precise user group with one goal in mind. For example, we removed the add conversation feature because we had figured the average user of our website would not contact any other user for any reason other than to get a toy.