Conference Room Tablets

The Idea

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

The Build

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.

    "name": "Moosehead Lounge",
    "events": {
      "current_event": null,
      "next_event": {
      "attendees": [...],
      "created": "2018-07-16T00:08:20.000+00:00",
      "creator": {},
      "description: "..."
      "end": {}
A sample response from our Conference Room Application API, which tells us what the status of a meeting room is. This data has been processed by the back-end of our application into a format that allows our front-end to quickly populate data without having to perform any further logic.

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.

APP.config(['$stateProvider', '$urlRouterProvider', '$locationProvider', 'RestangularProvider',
  function($stateProvider, $urlRouterProvider, $locationProvider, RestangularProvider){
    RestangularProvider.setDefaultRequestParams({format: "json"});



      .state('moosehead', {
        url: '/moosehead',
        templateUrl: 'show.html',
        controller: 'RoomsShowController',
          id: 'moosehead'
      .state('lumberyard', {...})
A sample snippet from our Angular router. The router has a route registered for each conference room, which helps it determine what parameters to send to the back-end for the call to the Google Calendar API.

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

The display portion of our application. The template displays the room’s name, current time, current meeting or availability, next meeting, and options for Quick Booking, if applicable.

The Execution

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.

Unfortunately, due to the small screen size, it was hard to see the conference room’s information at a distance.

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.

An iPad Pro provided enough screen space to see the web application much more easily from a distance.

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.

Our iPads are mounted on the wall via 3M Command Strips on top of a recessed outlet, which provides constant power to the tablets.

Next Steps

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.

The green border, which is visible at long distances, indicates that Moosehead is currently available.

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.

The /openrooms slash Slack command allows users to search for an open room without leaving their desks.

What We Learned

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!

Take Over the World With Us

Work With Us

See how our ideas, insights and know-how can help you tackle your next project — or build a human-centered experience for your brand.


Join the Team

Want to build something you believe in? See what it takes to become part of our fast-paced team of dreamers and innovators.

Open Jobs