Skip to: Site menu | Main content

Blog > Building a Status Screen, part 3: Display

>> Building a Status Screen, part 3: Display

Fri, Jun 4th 2:43pm 2010: IVT

This is the final installment of a 3-part series on building a visual status screen, or dashboard, for your company. If you missed the previous parts you can find them at:

 Building a Status Screen, part 1: Hardware
 Building a Status Screen, part 2: Collecting Data

In the first installment I showed how to physically mount LCDs on a wall, and in the second I showed how I go about collecting data from various systems (both internal and external) in a central location.

The final step is taking that data and displaying it on the status screens, and then updating the display whenever the data changes. There are a huge number of ways this could be done depending on what sort of system you are accustomed to working with, but since I normally do web application development I decided to take the simple way out and make the status screens using dynamic web pages. Yes, when I'm swinging this PHP hammer every problem looks like it could be solved with a web page!

I'll start by showing you the simplest, most brute-force approach that should be easy to get going. It's a bit crude but it'll get the job done, and later I'll mention some enhancements that can make it more elegant.

In the last installment we ended up with all the relevant data being stored in simple text files on a central machine. With all the data in one place it's easy to create a dynamic web page that is served by that machine and displays the data neatly formatted to suit your LCDs, and by displaying it in a browser like Google Chrome that can run in full-screen mode it can look really pretty.

You'll need some kind of scripting system running on your server to generate dynamic web pages, and there are many alternatives so I won't go into detail here. I'm using PHP but you could do the same thing with Perl, Python,, or many others. It's really up to you.

Let's start with just about the simplest case possible, which is a page that loads a single value (the current temperature, in this case) from a text file on disk, displays it, and reloads itself periodically.

<meta http-equiv="refresh" content="10" />
  $temperature = file_get_contents( "/home/statusscreen/data/data-weather-temp" );
  echo "The temperature is " . $temperature . "&deg;";

That's it! Not so hard, right? If you put that code into a file called something like "screen.php" inside the web tree on your server and load it up in a browser, you'll see a mostly blank page with the current temperature displayed on it - assuming your data collector script is updating the "data-weather-temp" file as described in Part 2.

The "meta" tag at the top is a special tag that tells the browser to reload the page periodically, and in this case it'll reload every 10 seconds. If you leave the page open in your browser and alter the value in the "data-weather-temp" file you'll see the change reflected in the web page after a few seconds.

Of course this is a very minimal example, and if you've done any programming it'll be obvious that there are many ways to improve the code above: for example, before attempting to retrieve the contents of the file there should be a check to make sure the file actually exists. Then once the value has been extracted it should probably be cast to a numeric value just in case something nasty ends up in the file. The page itself will also be totally unstyled, simply displaying default black text in the top left corner of the page on a default white background. You'll also notice that the entire page is reloading every single time, when really it's only the temperature value that should need to be fetched from the server.

It's a start though, and with some further development it can end up as quite a decent system. To test it you can open the Google Chrome browser on the computer connected to your wall-mounted status screen, press F11 to go to full-screen mode, and leave it open. The page will continue to reload every 10 seconds so by editing the script on the server you'll be able to see the effect of your changes almost immediately. You can also preview the page directly on your laptop or desktop, of course, but having it open on the machine and screen combination that you'll ultimately leave running can be handy because it may have a different resolution to your own computer. Normally when developing web pages it's a good principle to structure it in such a way that it looks good in different browsers at different resolutions, but in this case you're creating a web page that will only ever be loaded up by one computer running that specific browser at a known resolution, so you can tune it to look exactly the way you want without caring about how well it works on other computers.

The next step is to expand the script to include other bits of data that you want to display on the same screen. In my case I wanted a simple 4x3 grid layout for one of the screens so it made sense to put the different parameters into a table. The result could be something like this:

$datapath = "/home/statusscreen/data";
$temperature = file_get_contents( $datapath . "/data-weather-temp" );
$brillianz = file_get_contents( $datapath . "/data-ops-br" );
$sb4 = file_get_contents( $datapath . "/data-ops-sb4" );
$projnum = file_get_contents( $datapath . "/data-projects-projnum" );
<meta http-equiv="refresh" content="10" />

That's functional, but still ugly. We're still dealing with default text on a white page in an unstyled table.

But now you can apply some styling to make it look pretty. By putting class names and IDs on the various elements and loaded an external CSS file you can now make your plain page look as classy as you like. In my version I applied styles to just about everything using CSS: the font size, font colour, text shadow, page background, borders and margins, and cell backgrounds you see in photos of the screens are all just styled with CSS.

At this point you have a system that is not only perfectly functional, but is actually starting to look pretty sweet as well. You could leave the system running exactly like this and be happy.

If you want to take things a little further though there are many things you can do. For example, rather than load the entire page every time you could have the page only load once and then use AJAX to periodically fetch and update data for the individual cells. In my version I have a bunch of Javascript that fetches values and then applies a "fade" effect to update from one value to the next, making the visual transition much smoother than a jarring reload of the whole page.

Because I have three screens on the wall I actually have three pages defined. One uses the simple grid layout described here, while one loads a web-based energy monitoring system created at IVT to display real-time power consumption in different parts of the building, and another displays bar graphs using data collected from various internal systems such as our bug tracker and package autobuilders. What you want to display is totally up to you.

The energy monitoring system is actually based on slightly different technology to what I've described here. It's still a web page, but it uses Adobe Flex to display real-time data that updates dynamically without having to reload the whole page.

I've deliberately become more vague towards the end because this is where you really have to decide what data you want to display and how you want it to appear. I built a system that suits my requirements, but it may not suit yours.

If you've built a status screen for your company I'd love to hear about it, so please drop me an email!

Bookmark and Share