Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The back end of the web site was built using Node.js and Express.  In The decision to use Node was mostly for self-improvement purposes, as no one in our group had used node before and wanted to learn something new.   In addition, Socket.io was used to build the event driven portion of the app, mainly the Question Queue.  The database used was Postgresql, interfacing via the 'pg' module.

...

The front end of the web site was built using HTML, CSS, and Javascript at its core.  However, many frameworks were involved.  For one, the javascript was served using Embedded Javascript (EJS), which is a templating system.  In addition, Jquery Mobile was heavily used, which provided us nice ajax animations and mobile widgets.  The decision was made because we figured the biggest use case was on a mobile phone.  Other frameworks include Swipe.js for the Stats page, and jquery-rate-it for the stars on the feedback page.  

Implementation vs Usability

The main problem with our implementation versus the usability of our system was in the time aspect.  By attempting to build our system on a new infrastructure that we were not familiar with (node), there were many speed bumps and getting up to speed to do usability fixes proved very difficult.  Much of our time was spent trying to generate data dynamically and setting up the database than usability fixing.  In hindsight, it would have been preferable to do a framework we were all familiar with (i.e. rails) as opposed to something new, as that would have allowed us time to make more usability changes.  The technical learning curve was our biggest obstacle.  

There were other usability fixes that we just didn't know how to do. For example, we were unsure how to augment the Question Queue to include upvotes and to allow the tour guide to remove questions. The latter would have required a tour guide portal that we did not have time to do.  The Maps page initially was going to include a path indicating the current tour, current location pin, and a color overlay across the buildings so that the tourist would know what type of building they were walking by (for example, coloring all administrative buildings red, all computer science buildings blue, etc.).  This would require a lot of customization with the Google Maps API, which would have been tricky.  The 'schedule meetup' feature was supposed to notify the student via email, however that was not fully implemented due to issues getting email to work with node.js .

Evaluation

To evaluate our implementation of the ConnecTour UI, we crashed a tour being conducted on Monday and asked three tourists to test our interface. The three users we found to conduct this round of user testing were tourists, although they were unfortunately not all prospective college  students. Early on in this project, we determined that our target user population would be what we called "story tourists": prospective students who were interested in hearing specific and detailed stories from college students about what the college was like. However, as it was already hard enough to find students who were prospective students, let alone "story tourists," our user population was the closest we could find to our desired target population.

...