The main product of the company I currently work for is a hosted store locator and lead manager service, named Bullseye. We’ve been concentrating on both improving it and marketing it recently, so there’s some fairly interesting things going on that I thought I would write up. I’ve mentioned some of these things previously, but I thought it might be useful to have a single consolidated post with some pointers.
We have a Facebook store locator, which you can find at https://www.facebook.com/BullseyeStoreLocator. The Facebook locator was an interesting project. The first iteration was outsourced to an external developer, and was completed before I started working for the company. Due to some major changes in the way Facebook supported app development, we had to do a lot of work on the Facebook locator in mid-2011. I did a pretty major rewrite of it, using the Facebook C# SDK (which seems to have moved to Github, and gotten a nicely redesigned website since I last looked at it). Since that rewrite, one of our other developers has been working on it, mostly adding new features. The most recent new feature is one that allows you to attach ‘like’ buttons to individual locations in the returned results, linking them to individual Facebook pages for each location. It’s described in a blog post here.
We also now have a Drupal module that allows you to easily implement a store locator in any Drupal 7 site. (I’ve blogged about this previously.) It’s still a sandbox project under my drupal.org account. Cleaning it up and getting it ready to be promoted to a full project is on my rainy-day to-do list. (I’ve done a bit of work towards that goal, but I still need to do some more.)
And we now have a way to import and sync locations from Salesforce into Bullseye. This was another component that was initially outsourced. I’ve done some maintenance work on the project, and it’s pretty interesting. We’ve implemented a way to filter the results that we pull in from Salesforce, using serialized LINQ expressions. I was initially leery about this approach, and there are still some things I don’t like about it, but if you need to abstract out and save complex filter conditions to a database, I guess there isn’t a better way to do it than this. The one difficulty is that it’s fairly difficult to read and comprehend the expressions, once they’re serialized, so it’s important to keep track of the original LINQ expressions, for reference.