Blog

Blog

Bitmotion’s Status Board

When more or less accidentally I stumbled upon the great iPad App „Status Board“ by Panic (almost years ago – *sigh*), it was clear to me that I wanted this for Bitmotion.

Bitmotion Statusboard

The idea of showing various status information in the middle of the office – read: Next to the Cafeteria :) – in a beautiful way seemed very attractive to me. So after playing around with the App and its standard widgets to display data, and after some team brain dumping what sort of „data“ was desired for us, we came up with the following information to be presented on the Status Board.

  • Project work packages and their status
  • Customer support tickets and their status
  • Infrastructure status from our hosting environment
  • Customers that visit us at our office for workshops, trainings or general meetings
  • Colleagues that are away (i.e. vacation or external training)
  • Any other information like a countdown, picture, message of the day, etc.

So the next step was to identify where to get the data from, plus how to process and to display it.

One important early finding was that we do not want to query our services directly from the iPad App, but to use a proxy layer which can fetch the data from the different sources (with configurable timing), process and cache it where needed. For us, this part is done on an internal Linux server.

Our data sources turned out to be:

  • Redmine for project information like work packages, their owners, customers and due date to show in a list view
  • OTRS for customer support tickets, their status, owner and process time to show in a list view as well as a graph „new vs. closed per day“
  • Nagios for information on server and services status (warnings and critical for the services like processes, http/s connectivity, DNS connectivity and so on)
  • A simple TYPO3 extension to provide visitor information  (name, company, date time)
  • Again Redmine to get the colleagues „away“ information, taken from a specific project (name, reason, date from, date to)
  • Any TYPO3 Content Element on a special page to show counter, picture or text and so on

Now that we had the raw data, we started to design the Status Board grid layout plus the looks for each widget (almost all done in HTML/CSS/JS). We found pretty quickly that not all the information will fit on the screen at the same time, so we decided to periodically swap the content from „customer visits“ with „who is away“, and the same with „OTRS ticket status“ vs. „Redmine ticket status“. With this little trick we managed to show all information in a good-looking manner. Our proxy layer – the linux server – enables us to mange the rotation of the information (the iPad App is not capable of such things).

Technology

For those who care for the bits and bytes, let me give a quick technical overview. Surely you will be able to adapt this for your own board quickly.

On our proxy layer, we run a simple cronjob for each service which will call the appropriate PHP files to get the information and cache the HTML.

Example for getting information from OTRS:

php […]/get_otrs_tickets.php > […]/output/otrs_tickets.html

Of course the technology for querying the services depends on the service itself. Here are some examples.

For Redmine, we call the server with search parameters, as

[redmine-host]/issues.json?status_id=open&sort=due_date:asc…

then putting the data into a template object which will be rendered as a HTML table.

For OTRS we are using a little class for the existing OTRS RPC interface

// Get all new tickets
$otrs_client = $this->getNewOTRSRPCClient();
$tickets_ids_new = $this->getNewTicketIds($otrs_client);
$tickets = $this->getTicketsFromIds($otrs_client, $tickets_ids_new);

In the Nagios case, we get a big XML file for the status, parse it and display the information as needed.

wget -O – [nagios-host]/inag/statusXML/statusXML.php > […]/nagios/nagios.xml

For visitors, we call the TYPO3 page where the plugin resists with a defined type num that will only render the pure HTML and then apply our own styling to the result.

Conclusion

For me, seeing this information on a large screen while grabbing a coffee or getting some cold drink from the fridge is a perfect talk starter for all of us: While you stand in front of the board, you can easily have a conversation with a colleague about some overdue work package, or inform yourself how well the support team is handling customer tickets.

How hard it all was? The data sources that we use all provide a „web service“ of sorts to hook on to  – some easy, some of course a little bit harder… Again, without our proxy layer there might have been some show stoppers. Thus a clear recommendation for all advanced use cases!

The Status Board App itself, however, does a good job for us – although (surprisingly!) it did turn out to have some minor issues, most of them with the HDMI output. We just opened bug reports; no feedback by the Panic folks so far, but hopefully those glitches will be fixed soon.

By the way, the obvious alternative would have been to use a web application (existing or homebrew) rather than an iPad App. Frankly, we did not even fully explore this option, because we found having a working and good-looking framework to be a valuable asset and wanted to focus our energy on the content :)

How about you? Do you have a Status Board in your office? What kind of information do you display? Which technology do you use?

Ihr Browser ist veraltet!

Bitte aktualisieren Sie Ihren Browser, um diese Website korrekt dazustellen. Den Browser jetzt aktualisieren