display pacing advice based on slide timings

[aspiers]

Display advice on whether the current pace of the presentation is on track for the right timing, and if not, whether the presenter should speed up or has the luxury of slowing down.

By default this assumes 120 seconds per slide, which can be a reasonable rule of thumb, but this can be configured by the defaultTiming parameter in the Reveal configuration block, and also per slide <section> by setting the data-timing attribute. Both values are the number of seconds.

Here is a screenshot:

The pacing advice changes red when you are behind, and blue when ahead.

[fghaas]

So I had a look at this and it's certainly useful, if not quite as useful as it could be. A few issues:

• What's a typical reason for not finishing a slide on time? Taking a question. Would you want to discourage taking questions? I hope not. So maybe you'd want to be able to to pause the countdown while taking a question, and intuitively you might want to click on the timer. Currently that resets the whole talk timer to zero, meaning your pacing now assumes that you have an additional buffer equal to the combined time budget of all prior slides. So that's a missing feature (which is fine, can always be added later) combined with somewhat counter-intuitive and illogical behavior (which really should be fixed).
• What do you typically do to account for that in your time budget? You plan a reserve at the end of the talk. Defining a reserve is something you may want to consider, as in "you're over time on this particular slide, but you've only used 30 seconds of a 5-minute buffer".
• Setting the default to 120s is problematic. The "2 minutes per slide" rule gets repeated just as often as the "no more than 7 bullets per slide" rule, and both are equally wrong — the time you spend on a slide is inherently flexible based on a number of factors, just as 7 bullets is way too many. I'd suggest having the default be set to 0, in which case the pacing information should also be suppressed in the speaker console.

[aspiers]

Would you want to discourage taking questions?

I think there are two approaches to talks:

1. Insist that people hold their questions until the end (important with large audiences)
2. Welcome questions at any point (better with smaller audiences, at less formal events)

Clearly, a strict timing plan will not work as well with the latter, but it should with the former. But having said that ...

So that's a missing feature (which is fine, can always be added later) combined with somewhat counter-intuitive and illogical behavior (which really should be fixed).

Congratulations for correctly predicting my next plans for this feature :-) I was thinking of adding +1 and +5 minute buttons to add more time - not just for questions, but also sometimes the event organizer decides to give you more time during the middle of the talk. But your pause button idea is a great idea - probably even better. Maybe we can have both.

Defining a reserve is something you may want to consider

Another excellent idea! Yes - allocating a 5 min reserve would mean that it could be used up accumulatively at any points during the talk. Saving it to the end is ideal, but having flexibility to take questions earlier is even better. Question: should a pause button always toggle countdown between the main timer and the reserve timer? Or sometimes do you really want to pause everything? That would have the effect of delaying the end of the presentation, of course.

the time you spend on a slide is inherently flexible based on a number of factors

This is of course true. However in my experience, when averaged out over a whole presentation, 2 minutes per slide is startlingly accurate as rules of thumb go, for my personal presentation style. Your style tends to use far sparser slides, so I doubt it would work as well for you. That said, you may well be right that it makes more sense for this feature to be suppressed by default.

[aspiers]

The other problem I have noticed is that generally we don't want the timer to start until the 2nd slide or so, e.g. if the 1st slide is a QR code or other cover slide which is to be shown whilst waiting for the audience to get settled. Suggestions very welcome for how best to handle this.

[fghaas]

I'd say for any slide that doesn't count toward the time budget, the onus is on the speaker to set data‑timing="0", which should be interpreted as "this slide has no time budget," rather than "this slide has a time budget of zero, except when massless and traveling at c which would make the time budget ∞".

[aspiers]

I was thinking "-1" might be a more apt value, but it doesn't matter much. The difficult bit is figuring out how to pause the timer when it's on that slide. Would you say this would only happen for slides at the beginning?

[fghaas]

I'd say if a slide has data‑timing="0" (or "-1", whichever you prefer), then just pause the pacing timer as soon as you get to that slide. For the overall time budget count it as zero. Doesn't matter whether the slide is at the beginning or midway through.

Yes of course you should also have an option to pause the timer, rather than only be able to reset it, but reveal currently doesn't have that for the "elapsed time" timer either. So that's icing on the cake.

[aspiers]

Just thought of a second use case for "pause" slides: a long session (e.g. hands-on training) where you want to allocate flexible breaks at various points. So yes, something like data-timing="pause" seems to make sense.

Current thinking:

• add a new totalIgnoredTime variable
• add a pauseStart variable which is normally null, but gets set to wall-clock time when either a slide with data-timing="pause" is entered, or a pause button is manually clicked
• when a "pause" slide is exited or the pause button is released, the elapsed time since pauseStart is added to totalIgnoredTime and then pauseStart set back to null
• calculation of time left for the current slide adds totalIgnoredTime to the time available
• clicking +1 min or +5 min buttons would add to totalIgnoredTime accordingly

I still haven't figured out the best UI regarding a "reserve" timer though. Intuitively, allowing setting of a reserve timer to (say) 5 minutes as a buffer for unplanned questions makes sense. However if the presenter presses the Pause button, that could be either

a) to answer a question, in which case it should start eating away at the reserve, or
b) it could be for the kind of break mentioned above, in which case everything should be paused.

So how to distinguish between these two types of pause in the UI?

Would also be nice to show:

• how much of reserve is remaining
• current ETA for session finish
• estimate of how long the remaining material should take

whilst somehow retaining a simple and intuitive UI.

[fghaas]

You're burrowing deep in a rabbit hole here. I'd say keep your changes as they are for now, except setting the default to 0 and not showing the pacing timer if the pacing value for the current slide (either via data-timing or by default) is <=0, and get this merged. Then add bells and whistles.

Or, drop this PR and start your own plugin.

[aspiers]

Sure, those enhancements can come in a separate PR to this one.

It definitely doesn't make sense to start another plugin though, because it's inextricably linked with the existing built-in notes plugin.

[fghaas]

Point taken. (I've never really understood how some plugins live in the main repo and others don't, but that's a different story.)

[aspiers]

FWIW this plugin helped me and a colleague successfully deliver > 50 slides and 2 demo videos within 36 minutes ;-) https://www.openstack.org/videos/video/high-availability-for-pets-and-hypervisors-state-of-the-nation

[fghaas]

@hakimel This looks like a very useful feature to me at this point; would you consider merging it?

[hakimel]

This is really nice! Thanks @aspiers.

I'd be happy to merge this with one change; can you make it so that this is disabled by default? Don't want to make assumptions about how long someone wants to spend per slide (we can suggest 2 mins in the readme though), and I think seeing a countdown there without having opted into it is a bit surprising.

[aspiers]

@hakimel Sure, I can do that. Do you think it would be reasonable if it was enabled by the presence of the defaultTiming configuration parameter?

[hakimel]

Thanks! Yea, I think basing it on the presence of that config value makes
sense. Matches how other config values work as well.
On Sat, 11 Jun 2016 at 22:03, Adam Spiers notifications@github.com wrote:

@hakimel https://github.com/hakimel Sure, I can do that. Do you think
it would be reasonable if it was enabled by the presence of the
defaultTiming configuration parameter?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#1564 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAmatRkSFfTnWVJeFj6AdRhOc1qZwkT6ks5qKxSIgaJpZM4II-WK
.

[aspiers]

@hakimel I have just rebased this branch and made the feature optional as requested, so that it's only activated when defaultTimings is configured. /cc @fghaas

[hakimel]

Thanks for the update – this has been merged.

Made a minor tweak; instead of appending "to finish current slide" to the clock where the text is so large I added it into the "PACING" label.

I wonder if you ever want to have both the elapsed time and pacing... Feels like if you opt into pacing the elapsed time counter is only visual clutter that makes it harder to follow your pacing. Maybe we should hide the elapsed time when pacing is turned on?

[fghaas]

Awesome! Thanks for merging this @hakimel, and congrats to @aspiers for getting it landed.

[aspiers]

I wonder if you ever want to have both the elapsed time and pacing... Feels like if you opt into pacing the elapsed time counter is only visual clutter that makes it harder to follow your pacing. Maybe we should hide the elapsed time when pacing is turned on?

Personally I prefer to have it there, and the colouring distinguishes the pacing timer from the previous one - but we could do that, or make it optional.

[bdarcus]

I wonder if you ever want to have both the elapsed time and pacing... Feels like if you opt into pacing the elapsed time counter is only visual clutter that makes it harder to follow your pacing. Maybe we should hide the elapsed time when pacing is turned on?

I agree with your impulse on this, and your conclusion.