Page History

{pagetree2:DogPack}

h2. Table of Contents
{toc}

h2. Design

OurAs expected, our design has changed drastically from how we first envisioned it. AsThrough wethe completedmany differentevaluation evaluationsstages, a common theme amongst our feedback was the need to simplify the user interface. BecauseAs ofa thisresult, betweenour themajority various iterations of our design, we spent majorityfocus through the various iterations of the timedesign attemptingwas toon simplifysimplifying 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 notificationsinvitations 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 bloatedcrowded, and users had trouble recognizing the notificationinvitations button in the navigation bar. In the computer prototyping stage we tried making the sections smaller and scrollable and adding more affordance to the notificationsinvitations dropdownbutton, but feedback from heuristic evaluations were still negative. As a result we did away with the sections and added a tab view for viewing notificationsinvitations, upcoming meetings, and past meetings. Because theupon meetuplogin notificationsthe needinvitations toshould be handledattended to first upon login, 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 differentusing 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!

The final design of the profile page is shown above. 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 didwas notgenerally yieldpositive. manyThe issuesonly regardingmajor thischange page.from From the computer prototype to the final design, thefor onlythis major changepage was making the meetup button more descriptive by makingreplacing it"Meetup" saywith "Let's Meetup\!" versus just "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 just 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 increasedwith learnabiltythis 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. Most of the major changesThe few significant changes to these pages, such as adding autocomplete to the search page for efficiency or allowinglisting a users or listing the 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:*
* TheOn datethe andschedule timepage, fieldsplace on the scheduledate pageand weretime placedfields on separate lines
* The On the home page, change the "History" header was changed history to "Previous Meetups".
* Autocomplete was added On the search page, add autocomplete to the location field on the schedule page to increase efficiency
* The calendarOn from the home page, replace the calendar that showedshows upcoming meetups was replaced it with a list
* More affordance was given On the home page, give more affordance to the buttonrate buttons thatfor listsprevious invitationsmeetups
* TheOn currentthe dateschedule waspage, highlightedhighlight inthe thecurrent calendardate onin the schedule pagecalendar


*Heuristic Evaluation:*
* PhotoMake photo sizes were made constant regardless of aspect ratio for better internal consistency
* AllChange all text besides headers were changed located in the body of every page to usea standard serif fontsfont
* The On the profile page, change the "Meetup" button was changed to "Let's Meetup"
* The review button was given a greater affordance
* A On the home page, give more affordance to the rate buttons for previous meetups
* Show a confirmation dialog is shown whenever the negative review button is selected for better safety reasons

*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 wasis coded using standardin HTML, CSS and Javascript, while the back end wasis coded in Ruby. The application is hosted on Heroku and uses a PostgresSQL database. We used Twitter Bootstrap to style our app, andproviding it providewith 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 unfortunately we need to tweak a lot of the files as we imported into 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 get everything working correctly. 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}


h2. Reflection