Conference Room Tablets

We do a lot of work here at Nebo, and that work requires communication and collaboration between team members. As a result, we hold many meetings in our office conference rooms and work spaces each day. Over time, we’ve noticed that the increasing volume of meetings and room reservations makes keeping our schedules aligned very challenging.

In the not-so-distant past, you might have seen a lone ‘Nebomigo’ juggling a laptop, trying to pull up Google Calendar (the tool we use to schedule office events) to see where their next meeting is being held. Perhaps you might have also seen us not-so-politely sticking our heads in rooms to figure out when the current meeting ends. Yikes!

This was obviously not an ideal situation, so we started to research solutions. We found some products on the market that provide conference room status-checking and scheduling by using a kiosk-like setup. Unfortunately, these setups are expensive, have more features than what we really need (such as multiple views per room, complex scheduling, etc.), and restrict how much customization and control we have of the system.

So why not build our own? Before we began, we set out to achieve four goals:

• Develop a relatively inexpensive status/scheduling system
• Display the status of a conference room/space at a glance
• Allow a user to reserve a conference room/space on-the-fly without interacting directly with Google Calendar
• Design our own, Nebo-branded, interface

Early in the build process we decided that we would like to use a tablet to display the application, though we didn’t know what tablet would work best. Since the final hardware was unknown, we decided to build a web app for maximum flexibility since most tablets on the market have some kind of web-browsing capability.

The Back-End

For the back-end portion of the project, we chose to use Ruby on Rails — we often use this framework for our client work (we did build a CMS in it, after all!), and it allows us to rapidly develop APIs. In this case, we used RoR to build an API that would be able to communicate requests from the front-end of our application to Google Calendar.

To access calendar data, we used the Google Calendar API Wrapper in Ruby. Our application’s backend has a specific API route configured for each conference room, and when that route is called, we use the Google Calendar API to fetch the data for the appropriate room. After fetching the data, we process and reformat it into a easy-to-digest json string for the front-end of our application. This step eliminates a lot of irrelevant information that comes back from Google Calendar and allows us to hide the logic that determines room availability from the client, cleaning up our overall application code.

One important requirement of the project was to allow users to ‘Quick Book’ conference rooms from the application. ‘Quick Book’-ing means that a user would not have to interact with Google Calendar at all in order to reserve 15- or 30-minute time blocks for a room. The Google Calendar API allows for events to be created outside of the Google Calendar interface, but we did run into a small issue — when Google authorizes use of the Google Calendar API, it is on a per-Google-account basis. Since the application doesn’t belong to any one person in our organization, we found that we needed to authorize the API as a ‘generic’ Nebo Google account to avoid making room reservations as any specific Nebo employee.

The Front-End

Internal projects such as these provide a great opportunity for us to branch out and experiment with technologies we may not be as familiar with; for the front-end portion of this build, we decided to try Angular.

The Angular application is integrated with the Rails Asset Pipeline in our web application, but handles its own routing and data fetching. When a user visits the application, our Angular code determines which controller to call based on your url (there is a unique url for each conference room) and the controller handles fetching the correct data from the API we developed on the back-end portion of the app.

Our code fetches the appropriate room data, stores it in the scope, and then outputs it to a template we designed and built.

At this point we had a functioning web application, but no device to display it at our conference rooms. Since our application only requires a web browser to display, we had a lot of options to choose from, but we still had to determine which device would provide the best user experience.

Take One

Initially, we trialled an Amazon Fire Tablet. We really like this tablet because it has web browsing capabilities and is relatively inexpensive. Unfortunately, we found it was too small for this particular use; while our web app could be displayed, it was very hard to see the time and event descriptions from more than a few feet away. Since we have a large, open office, this was not  ideal. Additionally, the display on the Fire Tablet is so small that events with long descriptions and/or guest lists would have to be scrolled to be seen.

Take Two

Next, we tried a 10.5” iPad Pro, which has a significantly larger screen than the Fire Tablet. We found that this provided a much better interface for the user. The increased screen real estate allows the display to be seen from across our office and provides ample room for listing long meeting descriptions and guest lists. It also has enough space to show the ‘Quick Book’ button without scrolling.

In order to remain on all day, the iPad requires constant power. To provide this, we had an electrician install recessed power outlets to the walls outside of our conference rooms. This allows us to hide the power cable behind the tablet when it is mounted on the wall.

Finally, we had to decide how to keep the iPad on the wall at eye-level. To achieve this without any additional modifications to the walls or iPad housing, we used 3M Command Picture Hanging Strips. The strips are made of a Velcro-like material, which allows us to easily remove and replace the iPads on the wall if they are in need of updates or we want to test new features.

As with many applications, we have iterated and refined the functionality of the Conference Room web app over time. One significant improvement was adding a large, red/green border around the interface to indicate quickly whether a conference room was currently booked or not.

We have also added an additional internal tool — a custom Slack Slash Command that brings the Conference Room Application data to any Slack channel. The command allows everyone at Nebo to quickly find an open room without having to search through Google Calendar or get up and look at the app displays.

In the end, our project was a success! Our tablets are in use everyday here at Nebo and they have helped ease some of the headaches surrounding scheduling meetings. Along the way we learned a few things:

• Angular: This was our first time using Angular in an actual application. While there were some things we liked about Angular, we felt that the learning curve was very steep and our final code was rather verbose. In more recent projects, we have started to lean more on React for these reasons.
• Slack: While we had developed some custom Slack integrations in the past, this was the first time we used a slash command. Slash commands are a great way to make data easily available to users as opposed to creating a chat bot, which requires more setup and more effort from the user.
• Tablets: What can we say? Bigger is better when it comes to display technologies users need to interact with. We learned not to skimp on screen size!

Thanks for reading about our Conference Room tablet project! If you ever find yourself at our office, you can be assured you’ll know which room you belong in!