CueTimer is a timer-application which helps presenters, performers and production-crew stay on time for live shows, streaming and broadcasting.

One of the first decisions we had to make when creating this app, was whether to go for a browser-based app that runs from a server, or make a desktop-app with a native user-interface.
Browser-apps are getting more popular for the Audio/Video industry, and one of the reasons is probably that it is easier to develop things faster when you only need to make it work on the browser. And with remote workflows the ability to work on an Internet-browser becomes more appealing. 
So why did we instead decide to make CueTimer as a more traditional desktop-app for both Mac and PC? I will explain why, but first I want to tell a little bit about myself.

I have worked several years as an audio and audio/video engineer in Norway,  through my company Brekkelyd. As a show-operator, or FOH-engineer, I am expecting a high standard for the user-interfaces I operate to run the shows.  For example, the audio-console should have solid buttons and faders, and intuitive navigation. When I started to think about a new timer-app for events, one of my first requirements was that it should be as solid, reliable, and fast to handle as that you would expect from a video, light or audio-console. I wanted to treat this as a show-critical tool, something that you could depend on to run a live-show. And that made browser-based solutions less appealing right away. I couldn’t imagine myself running a live-show from an Internet Explorer browser-tab next to Facebook and YouTube, it just didn’t feel solid enough for me.

Now, a couple of years after CueTimer was conceived, the skepticism towards browsers is perhaps not justified. Engineers are not scared of using browsers during the shows, and Companion, which we also support, is a great example. There are great programming-tools for developing rich user-interfaces for browsers, and sometimes it’s even hard to distinguish between apps created for desktop or browsers.
But I still believe that a desktop-application has some very clear advantages, especially when you are dealing with live shows where things can go wrong very easily.

When I use CueTimer for my own projects, it feels very different from testing the applications at home. One thing I discovered when working at live-events with CueTimer, was that I almost never had the luxury to dedicate one mac or PC to the timer-application, there simply wasn’t enough computers, or space at the mixing-position (FOH), to separate everything. Usually I must use the timer-machine for communication, mails, downloading material, and pause-music. The ability to multitask becomes important. By having the CueTimer app away from the internet-browser, it is much easier to find the CueTimer-window when I need to. I can do whatever I want with Chrome or Safari without risking closing CueTimer. While I am using other apps I can also view the preview-window with the timer, as it will always stay on top of the screen. This makes it much easier for me to monitor the timer.

The preview-window stays on top of the screen when using other apps

What is perhaps more important than the user-interface, is the output-windows we create to let other people see this countdown. One option we have in CueTimer is to send the timer-data to an online server and create a webpage where people can see the countdown on their local Internet-browsers. This is a great way to spread the countdown all over the world. But usually you want to display this countdown locally as well, as a monitor on the stage for a presenter, or a video-signal to the vision-mixer. And in those situations I don’t think it’s the best approach to rely on a browser connected to the Internet: The Internet-connection can fail.

This actually happened to me last autumn. I was in a conference-hall as an AV-engineer responsible for the PowerPoints, videos and the timer, and a different company was working with the live-streaming. When the internet for the whole building went down during the show-preparations, I didn’t want to ask the streaming-company if I could borrow some bandwidth for the timer. I was very happy that the countdown-monitor on the stage didn’t rely on an online server.

Another way to display the countdown-monitor could be to have a server inside the CueTimer application that creates a webpage which can be accessed on a webpage connected locally, either on the same machine, or over the LAN-network. This approach would be very similar to sending spreading the timer over the Internet , except that the server never leaves the CueTimer machine, so you are not relying on Internet-connection. Although this could be added as a useful option, we believe we have better ways of displaying the countdown locally.

In the event where the internet broke down, the timer-monitor was connected directly from the computer with CueTimer through HDMI and SDI-cables. I had no preview-monitor or Multiview where I could see what was displayed on the stage. Then it becomes important to have a reliable way of filling the whole external monitor with the countdown-graphics, and a way to check that it is displayed properly during the whole show. 
With CueTimer this is very easy. Just push the “Fullscreen” button, and the timer-page will fill the external monitor by default. As long as this button is lit yellow, you know that the connection is working.

When we display a countdown-page on an external monitor, it all happens within the CueTimer application. This gives us full control over what happens with this window, we can place it anywhere we want, turn it on and off, and give feedback of its status. This level of control is not possible when using third-party browsers that are not a part of the CueTimer application.

So these are some of the reasons why CueTimer is a desktop-application for Mac and PC. We could probably have spent less time and developed faster with a browser-based app, but then it would be more difficult to ensure broadcast-reliability for our timer-app made for live shows and events. In the end we think it will be worth it to go the extra mile.

Written by Morten Brekke Stensland, CEO of PresentationTools A/S