I think, I would switch this to be the default option, as I would do with the vertical scroll-option (a scroll bar is only shown if it is necessary anyway), as this makes life much easier "for beginners (and even experts ;)" (scrolling does not always work immediately though, sometimes, the slide deck has to be travelled a bit before the bar is shown on too large slides, but this happens only in certain presentations and migth be a tricky issue only occuring in my environment, so forget that ;)
Especially in a live context, if you leave the live presentation, modify some cell and restart the live presentation, I can hardly imagine a use case where you want to start from the beginning (and not from the slide you modified very recently). And even if you would prefer a re-start, the Home-Button is your friend.
I usually include
"livereveal": {
"scroll": true,
"start_slideshow_at": "selected"
}[,]
in the notebook's metadata.
Yeah, being able to avoid scrolling would be nice, but in some situations, that becomes hard (larger output of a code cell for example, or large code cells). It is not necessarily an issue "per se", as scrolling is performed in the (hopefully well-defined) semantic context of a single slide (so that the scrolling naturally extends the presentation of a single topic), in contrast to the somewhat nastier scrolling necessary when presenting a non-slide notebook "from top to bottom", where you always have not-so-nice moments with mixed content (content not completely presented yet from topic A.1 and content already shown from topic A.2, for example). And, hey, everyone scrolls today all the time, look at your mobile! ;)
I really like the RISE stuff so far, as I, of course, really like the Jupyter stuff. But I am not sure yet, if I will be able to switch all my teaching to it. Here is one situation that I haven't solved yet:
The "scrolling is not too bad" argument above is quite plausibe in situations that lead naturally to a linear presentation that may "grow" dynamically (as the live execution of code with rendered results below seems to be a good example for).
However, there are a number of situations where a parallel presentation would be much more advisable. A typical use case, for example in "Algortihms and Data Structure" courses, is the following: you show the algorithm on one screen, and on the other screen, a small sample problem is shown and the inner workings of the algorithm are "traced" step-by-step (which ultimately lead to the final result), for example a table is used to track the update of certain information while computing a shortest path with Dijkstra's algorithm on a given graph, or a heap is drawn and extended step-by-step while managing a priority queue in an algo etc., you get the idea. Here, not the final result is in the focus (which would naturally extend a story line linearly like: here is the algo, next there is a sample problem given as a parameter to the algo, and, voila, next is the result, conclusio: the result looks good, the algo seems to be clever, hurray!, remember how you call it). Now, we want to understand, WHY the algorithms solves the problem (by using, hopefullly, appropriate data structures and understanding their dynamics in parallel to code execution). Later, we want to ask questions like: "how could you improve the algorithm with respect to time and/or space efficiency" or "would this algorithm still work, if the problem slightly changes (for example: with some negative edge weights?) - and, if not, can you modify it to solve the new problem?" (no, sorry sir, but I can show you a video on youtube of some guy who could...problably at least ;)
Well, that is tough in a linear slide show. I have two screens available for presentation (or, logically, a *really* broad one), I would like to be able to execute the code in a code cell step-by-step on one "side" and, right next to it (not below!), show the computed results, equally "step-by-step" and, of course, in a synchronized manner - and that either in one "broad" notebook (two slides side-by-side) or, also possible, in two synchronized notebooks (output of code cell 3 in notebook one is directed to "presentation" cell 3 in notebook 2; or both browser tabs show two views of the same "living" notebook instance, so that you could position one view on the algorithm and one on the output the algorithms produces dynamically - you may want to edit the code live to vary the problem etc., so identic static views are not a solution).
Well, ok, sorry for so much text, not really a RISE issue (it could be made to one though: reender the output of the slide with the algorithm not below the algorithm but into a pop-up window (upon choice of the author per code cell, of course)...this could be placed "by the user" next to the algo as a parallel "result slide" on the broad (or second) screen (and it should be reduced for the next result etc,). Well, this would still not be "step-by-step", but that could be simulated ex post by pointing to the appropriate lines of code while explaining the related output (or vice versa).
[You may ask yourself, where the data structures dynamics become visible in the output...we usually provide two versions of the algorithms in a notebook: one "pure" and one that also outputs the stuff we want to trace, for example a table with some values from the variables used in the algo). In an ideal world, you would show the pure version and the output of the second. In an even more ideal world (yeah, there is no way to improve ideal...I know), the presentation of the "pure" code in the slide with the algorithm would be generated from the second version (simply by leaving out appropriately marked lines, e.g. # dont show start....# dont show end), but all those lines should be executed when producing the output. Our current "workflow" is: show the pure algo on one screen, show an example and a sample computation (usually drawn by hand) on the other screen, than execute the pure version first to show that the result was correct, than execute the second version and show that the result and the computation were correct (not in a mathematical sense, ofc). Later, the students can use the second version to study for the type of questions in the exam where they should trace the algo execution with exactly those presentations the second version of the algos produce. We support this for most of the presented algortihms in a learning system where problem instances are automatially generated and the students fill-out the representations and receive immediate feedback.]
BTW: Thanks, Damian, for all your work and the others, esp. Scott, for there inspiring and informative comments in this threads.
Al