The Mobile Presenter

I attended FOSDEM last weekend, Europe's biggest Open Source conference. Can you imagine a largely self-organising conference that manages to somehow come up with 500(!) talks for two days? That's FOSDEM.

With so many talks to choose from, I only managed to attend a total of 10 (not counting one spontaneously organised "Birds of a Feather" session). Interestingly, I noticed one common design element on the slides of 3 of these (pretty much randomly selected) talks: A progress bar.

Progress Bars in Software

In theory, progress bars are a good design element to have. If done properly, they give you an idea of where you are in a process and how much time is left until the end. In practice, however, progress bars have a bad reputation, mainly due to their bad implementation in software. We've all seen this: They progress quickly through the first half of a process and then slow down and take much longer for the rest (or vice versa). That's counter-intuitive and counter-productive and hated by the users. As a result, software these days only shows some sort of generic activity indicator, such as a rotating wheel.

I've implemented progress bars in software myself and the problem is really that sometimes you can't predict the exact length of a process. But if you can't, then a progress bar is simply the wrong element to use.

Progress Bars on Slides

Back to the slides: In a talk, a progress bar seems to make more sense, at first. There's a predictable length to the process (i.e. the talk), so a progress bar can be used to indicate to the audience how far along we've progressed in the talk.

Assuming it's done correctly, that is. The trap to watch out for is to equal the amount of slides with the length of the talk. So if you have 10 slides, you would think that progressing the bar by one tenth for every slide would do it. But are you really spending an equal amount of time on each of those slides? There will usually be slides that take more time to explain and others that you'll go through quickly. So to be done properly, the progress bar should represent the amount of time that has passed, not the amount of slides you've shown. That can actually be hard to do in practice.

What's the Benefit?

Which brings us to the question: Is it even worth the effort? What's the benefit to your audience?

It's always a good idea to give your audience an idea where in the talk you are. If you give a quick summary of your plan at the beginning (something along the lines of: I'm going to tell you about our new product, Foofizzle, what it is, how it works, and how you will benefit from it. - not the dreaded agenda slide) and the talk isn't too long, then that will usually be enough. The audience will be able to remember that you are going to tell them 3 things. Simply announce the next section when you get to it and they will know where in the talk you are (and what's still to come). If you have a clear structure, a progress bar will not add any useful information.

When and How

For presentations longer than the usual 60 minutes or so, I do recommend using a (visual) agenda slide plus explicit section title slides, mainly because you probably have more than three or four sections in your talk and the audience will need a refresher. For such a talk, a progress bar could make sense, to give the audience an idea where we are in the course of the presentation.

You should make sure, though, that the progress bar does not add visual noise to your slides. Two of the three talks I saw at FOSDEM were doing that right. They had a narrow coloured stripe at the bottom of the slides (yellow on black background in one talk, blue on white background in another). The third talk actually had what looked like a real progress bar (like you would see in a piece of software) at the bottom of the slides. It wasn't too obtrusive but wasted some real estate on the slides that could have been used for other purposes. This approach would also clash with full-screen photos. So if you're thinking about trying this out, I'd recommend using a stripe at the bottom of your slides.

 

The main problem I see with adding a progress bar to your slides is that it will require a lot of work to be done properly with only rather limited benefit for the audience. You can really only add the progress bar once your slides are done and you've rehearsed your talk a few times. Otherwise, you won't be able to tell how much time you'll spend on each slide. As far as I know, there's no support from slideware applications for this feature yet, so you will have to add the stripe manually; which can be a lot of work if you have many slides.

The Verdict

I appreciate the idea behind the progress bar. In practice, however, I think it's just too much work for a rather limited benefit (both for you and for the audience).

If you want to try it out yourself in your next presentation, please keep in mind:

• make it discreet, e.g. with a coloured stripe at the bottom of your slides
• the bar should represent the progress in time not in slides

Things may be different once there's support for adding such a progress bar to your slides in slideware apps. Until then, I think I'll pass.

(Image Credits: Apple App Store Progress Bar by Rob Enslin, from Flickr; FOSDEM photos taken by my Narrative Clip)