What was the problem to be solved?
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.
What was the proposed solution?
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.
What challenges arose during the project?
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.
What was the technical approach to the project?
Our approach was to extend the Open Source software to add the required features.
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.
What was the project management approach to the project?
What did you learn from working on this 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.
How did this project benefit the client?
User session time increased by more than 30% with the new features while repeat visitors increased by just under 20%
What tools, techniques and methodologies were used on this project?