At Bottle Rocket, we occasionally take time out of our week to focus on exploring new technologies. We call these “Hack Weeks” and they generally consist of small teams forming and meeting for an hour or two each day to try out some new ideas.
In early December, we had a hack week around office apps that we called “Teemwork Makes The Dream Work,” a play on words that uses the Teem moniker for an extra level of puns. We had several teams explore integrating with Teem, and several that worked on other ideas. With Hack Week, anything is on the table! So let’s dig in to a few of the ideas we saw:
OFFICE TEMPERATURE TRACKING
Tyler Milner, one of our iOS Jedi, decided to dig up an old Rocket Science project of his called BR Ice Box. The project observes the temperature readings from the Bluetooth beacons around the office and stores that information in a Firebase Realtime Database, displaying a list of all of the beacons and their corresponding temperatures in a list. The main idea of the original app was to make it easy for people to figure out the warmest/coldest areas of the office.
For hack week, he decided to build upon this project, extending the functionality to also send the temperature readings to the Teem API. In the Bottle Rocket kitchen, we have a large television that shows a list of meeting rooms and their current availability. His goal was to also display the temperature information that the app picks up on that screen as well, so people could get a sense for office temperatures without needing to download or use an app.
Overall, I didn’t get very far in my implementation of the Teem API since it took some time to write the code that executes the Teem API’s OAuth flow. I did get the OAuth flow working, and was able to successfully get an access token and verify I could hit Teems API to get a list of room information, but I didn’t have time to take my temperature readings and execute the necessary PATCH calls to attach my temperature readings to each meeting room.Tyler Milner
Hack Week doesn’t require successful completion of the projects that are started, the learnings from the experimentation lead to more ideas. Next up was an experiment with using a keyboard within iPad apps.
KEYBOARD FUNCTIONALITY ON IPAD
John Davis explored using a third-party framework to expand an application’s support for keyboard-based navigation.
I believe great keyboard support sets apart iPad and Mac applications that feel well considered and accessible from those that feel preliminary. The need to discover efficient solutions and patterns to implement this results from two fronts: Apple’s allowance of iPad applications to run on Mac, and a drive to better support accessibility standards that require keyboard controllability.
The framework John explored is named KeyboardKit and is developed by Douglas Hill. The demo app highlighted components, like tab bars and navigation bars, provided by the framework that come with easy to use support for invoking buttons and navigation actions via the keyboard.
As with most hackweek projects he was short on time and not able to explore much more, but he found the framework falls short in the same ways that Apple’s provided tools fall short. That said, it helped him learn how simple it can be to add these interactions to an application and provide a more complete experience to users.
SLACKBOT + ANALYTICS
Several weeks ago, a few Rocketeers discussed the idea of using a Slackbot as an internal test bed for analytics and user engagement tools. For Hack Week, Jason Brewer was interested in the effort it took to develop a Slackbot and how feasible or successful this idea might be.
I found that developing an intelligent Slackbot was as easy as getting an API key and standing up a Node JS server. Then I needed something for it to do so I grabbed several easy public APIs that returned nice JSON and connected them to key words the Slackbot watched for.
To bring in the analytics and engagement element, he had the idea to just let users engage the Slackbot with no context or information about its features and collect analytics on the discovery of its ‘random’ features. Using the workspace we have as a result of our partnership with Amplitude, he integrated an Amplitude package into the bot and defined events to track:
- User joined the channel
- User asked for help
- User asked for a clue
- User ‘discovered’ a feature (by typing one of the key words that triggered the feature response
By gamifying the interaction, he was able to collect data from other Rocketeers who played with the slackbot. Few people found all the features, but quite a few people participated and enjoyed interacting with a rudimentary AI. He was able to collect data around which features were the easiest to discover, and how the clues given by the slackbot impacted the successful discovery of more features. This kind of analysis is similar to what we see in our clients’ analysis, so it was nice to experiment with a version of this ourselves.
Hack Week is a great time to explore new ideas, and experiment with technology we have been following. We never know where these ideas could lead, and if you any questions, or would like us to explore ideas with you, feel free to reach out. [Link to contact us page].