Uncommon architecture for common good.
As the Thanksgiving holiday was just upon us, the time seems just about perfect for discussing a choice we made in the wearable architecture that might benefit the sector. Instead of building our own CMS for the content or even using something you’d commonly think of as a platform for hosted content we went a different route. We decided to use Salesforce to host the wearable content; this very unconventional choice paired with off the shelf hardware means we may just be able offer wearable piloting to the sector without having to take on the burden of shared systems hosted by us.
The funny thing about this choice was just how much head scratching came with it — why in the world would we host our content in this way when we could, in theory, make a more conventional choice of a standard CMS? Well, Salesforce offers anyone a way to spin up an instance and run it without technical expertise and there’s an API. That’s a boon for the Barnes because it means we can get up and running quickly without an in-house developer staff, but it also means we can hire a firm to use the API to develop something unique and meaningful on top of the data. At the end of the day, we had to ask ourselves, how different is a constituent record in a CRM from what we know of an object record? Truth is, not so much.
The beauty of this is that thing that made it easy for us —call a rep, spin up an instance, great non-profit pricing — makes it fast to prototype and, also, makes it darn easy for us to share this project pretty widely.
At base, that means we’ll be publishing the app code to our github. You’ll see that happen in early January just after we get through bug testing. This means in order to use it, you just spin up a Salesforce instance, populate it with short form content according to our directions, get an API key, assign/install some beacons, buy some hardware off the shelf and you are pretty much ready to go. The beauty for the Barnes is we get to share without taking on the overhead of providing a service.
To most institutions with technical teams, the content generation would be the hardest part of this and the rest of that stuff might take you a day or two. To institutions without technical teams, you might look at that list and find even that daunting. For those situations, we actually think we could make it easier by creating a way to assign the API key to your wearable app without the need to ever touch the code.
Before we all get too excited, let’s get this product on the floor and see how it works. We’re going to start by publishing our wearable code and step-by-step directions so you can DIY. We’ll see if non-technical users can follow those directions and start piloting without more help. If it looks like we need a quick way to assign the API key without code, we’ll see if we can make that happen.
In the meantime, using Salesforce has not been without its hiccups. Aside from some fiddly things we had to do with structure and permissions, the most problematic issue we face is with the Salesforce API limits — 25 requests every 20 seconds. While we don’t see that as a problem for the prototype pilot, we think we might very well become one in a full deploy at what we see might be maximum use.
Still, though, this has been a great exercise in pushing the limits of shareable projects and we think it’s worth it to go the path less travelled for one that might become the opposite.
The Barnes Foundation wearable digital prototype is funded by the Barra Foundation as part of their Catalyst Fund.
Want more info? Read more about the Barnes Wearable on Medium and follow the Barnes Foundation publication, where we’ve got multiple authors writing about our projects.
