Page History

!DogPack_Logo.png|width=300!
{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

*Current Home Page : *
!homepage_current.jpg!
|| GR3 Prototype || GR4 Prototype || GR5 Prototype ||
| !V2_HomePage.jpg|height=300!\\ | !homepage_prototype.jpg|width=300!\\ | !homepage_prod_v1.jpg|width=300!\\ |

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. During our GR5 implementation, we tried using a Carousel, since it lets the user view multiple items within each section quickly. But we realized, while this might have been good to scroll by items within a section, it was crowding the homepage with multiple sections, each with a separate carousel. So for our final version we replace it with 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 felt the affordance of the rate buttons wasn't good enough, and in the computer prototyping stage users brought to our attention, a 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 safety. 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

{color:#800000}{*}Technical Infomation{*}{color}

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

{color:#800000}{*}Encountered Problems{*}{color}


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

{color:#ff0000} {color}

{color:#800000}{*}User 1{*}{color}

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

{color:#222222}We found this user in the basement of MIT Ashdown House and conducted the test using a group member's laptop. {color}{color:#222222} {color}

{color:#222222}{*}{_}Representative{_}{*}{color}
* {color:#222222}He's been a dog owner for  2 years and the dog is about 4 years old. {color}
* {color:#222222}The user bought the dog from another owner because he really loves having a pet. {color}
* {color:#222222}He often socializes with his dog (roughly twice a week) at MIT Ashdown Community or Boston Common Park. His dog has a "social circle" and he usually schedules meetups with friends from that circle. {color}
* {color:#222222}He would love to learn how his dog could meet more friends and play at more places.{color}

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

We simply introduced the purpose of our application and then started testing. Our application is for dog owners to socialize their dogs. They can use it to find dog friends, schedule meetups, rate other dogs, etc.

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

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    {color} {color:#222222}_ \[ add a message 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, which is not easy to find   _\[add a "reschedule" button in the "upcoming events"\]_


h2. Reflection

Upon examination of the entire project, we have noticed and learned much about the process of designing an interface. To start with, a major impression that we are left with is how important it is to communicate and receive feedback from possible users. Designing an interface is much unlike sketching or painting on a canvas where the artist is at liberty to hide for days working on a masterpiece. We benefited greatly from the feedback cycle, firstly from early prototyping, to the heuristic evaluation and all forms of user testing that we carried out. The final stage of user testing where we met with actual dog owners still revealed additional design limitations in our interface. We realize from this that it was in our own interest to design a project for a user class we did not belong to. We simply would not have experienced the adjustments and redesigning that is usually involved in interface design for given user classes. Each part of the design project, GR1 to GR6 played vital roles in steering our design towards an acceptable finished product. It is now clear that each stage was indispensable and perhaps could be even more advantageous if taken further. By this we mean that we felt for example, that if our early prototyping had used dog-owners, rather than random users, we might have learnt much more earlier about the usability of our interface for our intended users.

Our design project targeted a specific user class and each design decision we took aimed at learnability, efficiency and safety for this group of users. The scope of the project was well suited to the course material and now we can appreciate the work involved that goes into a design with a larger scope. Essentially, we can now grasp and fathom how much more intense, delicate and time-consuming a design for multiple types of users would be. Internationalization and accessibility would bring in the need for several more stages of testing, across different platforms and even demographics. Handling specialized accessibility presents a slightly more complex problem which would be interesting and challenging to tackle.
!DogPack_Logo.png!