Page History

{pagetree2:DogPack}

h2. Table of Contents
{toc}

h2. Design

As expected, our design has changed drastically from how we first envisioned it. Through the many evaluation stages, a common theme amongst our feedback was the need to simplify the interface. As a result, our majority of our focus through the various iterations of the design was on simplifying the interface while still offering the functionality wanted by the user.


h6. Home Page

!home_page.png|border=1!

In our paper prototyping stage, the home page contained separate sections for upcoming meetups and previous meetups, and invitations had to be viewed via a dropdown which was triggered by clicking a button in the navigation bar. After performing user evaluations on the paper prototype, we quickly realized that separate sections made the home page too crowded, and users had trouble recognizing the invitations button in the navigation bar. In the computer prototyping stage we tried making the sections smaller and adding more affordance to the invitations button, but feedback from heuristic evaluations were still negative. As a result we did away with the sections and added a tab view for viewing invitations, upcoming meetings, and past meetings. Because upon login the invitations should be attended to first, the notifications tab is set as the active tab when the home page is loaded. We also added a header to point out how many pending invitations a user currently has right below the greeting headline, and fixed the sizes of the images in each tab to increase internal consistency.


h6. Rating Feature

!Screen Shot 2013-05-15 at 1.05.19 AM.png|border=1!

In the paper prototyping stage users complained about the affordance of the rate buttons, and in the computer prototyping stage users complained about the lack of feedback and safety with clicking the negative or positive buttons.  As depicted in the screenshot, we addressed the users concerns by using colorful buttons with better affordance, and using a confirmation dialog when performing negative ratings to increase feedback. We also provide feedback by disabling the buttons once a review is submitted.


h6. Profile Page

!profile_page.png|border=1!

During the paper prototype stage, the design of this page was cluttered with attributes about the dog and comments left by reviewers. We simplified the design by first reducing the amount of attributes that are shown about the dog, and using white space to properly group items. We also made sure to only show positive reviews versus listing every single review that the dog has received. Because we fixed these major problems, feedback regarding this page from heuristic evaluations was generally positive. The only major change from the computer prototype to the final design for this page was making the meetup button more descriptive by replacing "Meetup" with "Let's Meetup\!".


h6. Schedule Page

!schedule_page.png|border=1!

The schedule page has undergone many subtle changes that have made it much more learnable and efficient to use. During the paper prototyping stage, we allowed the user to either select time slots in the calendar, or fill out a form that contained fields for the date, time, location, and message. Almost all users agreed that filling out the form was much less efficient than using the calendar. We addressed this by disabling the time field and adding a placeholder that tells users to select a particular time slot. Users also complained about the location field, unaware of exactly how to use it. We dealt with this by adding a placeholder that tells users what to enter, and also added autocomplete to the field to increase efficiency. These changes worked out well, as we received much less negative feedback regarding this page during the computer prototyping stage. Multiple users specifically commended the use of the disabled text field to display the time of the selected block. The only major change change between the computer prototyping stage and the final design is the color of occupied time slots. These were changed from red to grey, since in most cases red is associated with an actionable item.


h6. Remaining Pages

!search_page.png|border=1,width=300! !review_page.png|border=1,width=308,,height=212! !respond_page.png|border=1,width=302,,height=212!
The final design of the search page, the review page, and the respond to invitation page are show above respectively. The few significant changes to these pages, such as adding autocomplete to the search page for efficiency or listing a users schedule in the respond page, were captured early on during paper prototyping. Other then a few cosmetic issues that were fixed after heuristic evaluation, these page have not changed much since the computer prototyping stage.

Below are some of the major design decisions made during the different evaluations of our project.

*Paper Prototyping:*
* On the schedule page, place the date and time fields on separate lines
* On the home page, change the "History" header to "Previous Meetups"
* On the search page, add autocomplete to the location field to increase efficiency
* On the home page, replace the calendar that shows upcoming meetups with a list
* On the home page, give more affordance to the rate buttons for previous meetups
* On the schedule page, highlight the current date in the calendar


*Heuristic Evaluation:*
* Make photo sizes constant regardless of aspect ratio for better internal consistency
* Change all text located in the body of every page to a standard serif font
* On the profile page, change the "Meetup" button to "Let's Meetup"
* On the home page, give more affordance to the rate buttons for previous meetups
* Show a confirmation dialog whenever the negative review button is selected for better safety

*User Testing:*


h2. Implementation

Our website was implemented using Ruby on Rails. We picked Ruby on Rails because it was the only back end technology that at least one of our teammates felt comfortable with. The front end is coded in HTML, CSS and Javascript, while the back end is coded in Ruby. The application is hosted on Heroku and uses a PostgresSQL database. We used Twitter Bootstrap to style our app, providing it with both internal and external consistency.  We used Github to host our code and provide source control.


One implementation problem we encountered was the need to communicate between Javascript and the back end. This communication is necessary to populate the map view in the search page, and to populate the calendar on the schedule page. Fortunately, there is a RubyGem called _gon_ that makes communication from Ruby to Javascript incredibly simple. Another implementation problem was integrating the static HTML, CSS, and Javascript that we developed during the computer prototyping stage to the Ruby on Rails file hierarchy. Ruby on Rails handles file includes and dependencies differently than what we implemented with the static files, so in order to properly preview the website one must install Ruby on Rails, run the server and edit the files in the Rails project. Compared to editing static web pages, navigating and editing Ruby on Rails files can be somewhat daunting if you are not familiar with it.



h2. Evaluation

Our user testing involved the following tasks:

{color:#000000}{*}Task 1{*}{color}{color:#000000} : Respond to the invitation from{color} {color:#000000}{_}Lassy{_}{color}


{color:#222222}{*}Task 2{*}{color}{color:#222222} : Search for dogs in Beacon Hill and schedule a meetup with{color} {color:#222222}{_}Cupcake{_}{color}

{color:#000000}{*}Task 3{*}{color}{color:#000000} : Review a previous meetup with{color} {color:#000000}{_}Allen{_}{color}

{color:#222222}{*}Task 4 :*{color}{color:#222222} Reschedule the meetup invitation from{color} {color:#222222}{_}Tony{_}{color}

h4. {color:#222222}{*}User 1{*}{color}

{color:#222222}{*}{_}How conducted?_{*}{color}

{color:#222222}We find this user in the ground of MIT Ashdown House and conduct the test using our own laptop. {color}

{color:#222222}{*}{_}Representative{_}{*}{color}
* {color:#222222}He has the dog for 2 years and the dog is about 4 years old. {color}
* {color:#222222}The user bought the dog from another owner because he extremely loves having a pet. {color}
* {color:#222222}He often socializes his dog (roughly twice a week) at MIT Ashdown Community or Boston Common Park. His dog has a "social circle" and he usually schedule meetup with those friends in that circle. {color}
* {color:#222222}He feels wonderful if his dog can meet more friends and play at more places.{color}

{color:#222222}{*}{_}Brief & Tasks{_}{*}{color}

We simply introduced the purpose of our application and then started testing. Rather than showing all tasks at once, we let the user see each task only after he completed the previous one.

*{_}Usability Problems \[How to Fix\]_*
* {color:#222222}The user wanted to give a reason for rejecting an invitation      \[ add a meesage area in the invitation page \]{color}
* Map is not autoresize to show the search result in a good view    \[ autoset the map with an appropriate size so that users can find the result easily \]
* Cannot undo a review    \[add this function\]
* Have to reschedule a meetup through the "view schedule" page, not easy to find \[add a "reschedule" button in the "upcoming events"\]


h2. Reflection