User Account Development

JIRE wanted to better connect with site visitors and leverage them to share content for marketing purposes.

At the same time, JIRE wanted to provide a set of tools to add value to site visitors, making them more likely to stay on the page longer as well as return more often.

Gunner proposed allowing guests to create their own account for the site.

The site already offered robust searching capabilities for filtering and searching real estate listings, but not much in the way of preserving these sessions.

Having an account would allow visitors to sign in and save their searches and also denote which listings they are interested in so that they could receive updates.

For example, saving a search for three-bedroom homes, would create an alert that would notify the user whenever a new listing for three-bedroom home came on the market.

Similarly, a user would be able to express inteREST in a particular property and receive notifications when the property changed (i.e. price reduction, sold, etc)

Finally, with user accounts, we could connect to their Facebook accounts, which would allow them to share listings with their Facebook friends.

The site was built on top of an Open Source CMS, which offered user accounts, but only for site admins.

Users with accounts could login and update the site and listings using this account.

We wanted to extend that to allow for guests to create accounts, but not give these accounts access to edit the site, obviously.

This required implementing access roles and allowing admins to manage lower-level access.

The site was already built using Ruby on Rails with an Open Source CMS called "Refinery."

Our approach was to extend the Open Source software to add the required features.

For Facebook integration, we relied on another piece of Open Source technology in the form of a Ruby gem called Koala.

Koala provided a nice wrapper around both the oAuth and OpenGraph APIs that Facebook offers.

For notifications, we leveraged AWS SQS which provided background queues that run jobs whenever a listing is updated.

The queues store the updates and the Elastic Beanstalk worker daemon polls for changes.

When a change is found, a separate Ruby process determines which users, if any, should be notified and hands the data off to SES which notifies the required users.

We tackled this project using Agile Scrum.

We started with a Research Sprint to educate ourselves on the best way to extend and/or modify the Open Source CMS, Refinery.

With a firm grip on the technology, we began weekly sprints that lasted through the duration of the project.

A lesson that was reinforced is that it's always better to figure out the "right way" to extend or modify Open Source technologies.

The code we inherited had been badly monkey patched, which broke certain extensions we tried to implement.

We ended up having to go back and refactor the old code to be compliant with the Refinery API.

We also learned the difficulties of trying to manage relationship between unstructured data and specific users.

For example, saving a search and then checking each saved search whenever a listing is modified.

We accomplished this by saving a a URL encoded string of the search.

Then, whenever a listing is updated, we re-run each search to see if the modification caused the listing to newly appear in that search.

If it did, we collect other users who also saved the same search and notify them all at once.

The difficulty there, of course, was that rarely were two searches ever the same.

With over 20 search options, we rarely had overlap.

User session time increased by more than 30% with the new features while repeat visitors increased by just under 20%

Gunner Technology works extensively with Open Source technologies and is a staple in the Open Source community.

We also had an existing relationship with JIRE, which added trust to our proposal.