more on org-reveal, custom CSS 🔗
I spent a chunk of the weekend working on a presentation using org-mode and org-reveal. I kept getting reminded of why org-mode is so powerful, both as a paradigm and as an ecosystem.
The presentation itself just went faster freed of having to either operate inside presentation software, or working with an eye to moving things into presentation software. You’re just outlining, which is efficient and fast with org-mode.
As you work in the early “get it all out of your head” stages, you can take advantage of org as a todo-inflected outliner, adding literal TODOs and tags to headings to remind you to follow up or help you find common themes/areas. It’s simple to reorder headings, subheadings, and lists. You can make a kitchen sink area and mark it :noexport: and quickly refile dead-ends or reminders with no place to go into it. As you move into refining, those reordering and moving/refiling features make short work of small changes/adjustments. Unlike presentation software, you don’t get caught up in positioning/layout hell.
That’s not to say that there are no positioning concerns, and the way you address them is something a lot of people aren’t going to tolerate, but works fine for me: If you want, e.g. columns – maybe two or three equally sized ones – you have to do it in CSS.
That raises a few usability questions: How much CSS, and how do you wedge it into the org format?
“How much” isn’t much, at least if you know you have full control of the display environment for your presentation. I got away with a few lines:
.reveal .leftcol {
float: left;
width: 48%;
}
.reveal .rightcol {
float: right;
width: 48%;
}
How to wedge it in isn’t hard, either, at least with org-reveal:
You just put it in your org directory somewhere and pull it in at the top of the presentation file:
#+REVEAL_EXTRA_CSS: css/my-reveal.css
If you get tired of repeating yourself across multiple presentations, just customize it with org-re-reveal-extra-css.
There were a few things about the revealjs theme I am using that didn’t quite work for me, and it was easy to use my extra-css file to override them after a quick session with the Web inspector.
The markup inside a doc is pretty simple, too:
* Slide Title
#+BEGIN_leftcol
*Left Heading*
- foo
- bar
- baz
#+END_leftcol
#+BEGIN_rightcol
*Right Heading*
- foo
- bar
- baz
#+END_rightcol
The BEGIN_ keyword just ouputs a div with the rightcol or leftcol class.
So, do I like doing this?
I mean, not in an absolute sense. The presentation I’m working on right now is supposed to represent a work plan I hope I get a chance to actually start implementing. In my ideal world, I’d have a way to hide the positioning/styling markup in a drawer so that it was there and out of the way, allowing the presentation to be a living document that flipped back and forth between a roadmap work document and a presentation.
If I wanted to make that sort of document “code switching” a priority, I’d get rid of the positional stuff, and I’d be in a pretty good place to pull it off. Good enough for my style of presenting.
And even if I’d rather not have the wasted motion, it is not a bad amount of wasted motion. The separation of concerns between content and presentation is still balanced in a direction I like, and it’s not a lot of work to take a practical working doc and turn it into a useful presentation. It reminds me a lot of early, pre-WYSIWYG word processors, like PaperClip III, and typesetting systems that needed “dot commands” to send formatting information to a spooled laser printer.
Here’s a pretty good presentation on the stuff you can do with org-reveal (as bundled into emacs-reveal). It’s where I got the CSS stuff from after a little excavation.
Zoom and Mac display mirroring 🔗
Getting ready for that presentation, I wanted to do something really simple:
- Open my presentation in Safari.
- Open RevealJS’s presenter window (current slide, next slide, timer, speaker notes)
- Put the presentation in fullscreen
- Share the fullscreened presentation
- Run the presentation from the presenter window
Which … no. Not happening.
I could do everything but last part, because when I’d move from the fullscreened Safari window to the presenter window, the thing shared on Zoom became Safari’s placeholder “ESC to exit fullscreen mode” tab, and it paused sharing anyhow.
I fiddled around for a while, gave up, and decided maybe the best option was a Firefox plugin that makes a window look mostly fullscreen while not being actually fullscreen. I knew I’d wake up this morning hating it, but also knew I had something I could live with, and that would allow me to turn back to polishing the actual content.
This morning I did, indeed, wake up hating the solution. So I went back into Zoom because I vaguely remembered that you can share classes of things besides “apps,” e.g. devices and displays. Sure enough, you can share devices, displays, and whole desktops (mostly, since full-screened Safari exists in some sort of desktop/screen netherworld, I think.)
I ended up grabbing my iPad Pro, connecting it to my Mac Studio, and using it as a secondary display/desktop. It was easy to drag the full-screened Safari presentation into the iPad Pro, full-screen it, open the presenter window, move that up to the primary desktop, and have it all work as expected.
I am positive I had the setup I thought of first working in the past with just a single monitor, and I found evidence of people noticing that something changed at some point and offering frankly bizarre and counter-intuitive workarounds. I’m glad I just have an iPad Pro to throw at the problem.
I’m also glad that I’ve fully embraced “don’t change anything on game day.” It didn’t take me long – maybe 30 minutes – to get from “I’m using a new presentation approach and I should test this” to “this isn’t working how I remember” to “I tried everthing I know” to “settling on this workaround” to “oh, right – this might work.” Just fine for 36 hours out. It would have sucked on game day.
Scrum and kanban 🔗
Interesting post: “You don’t need Scrum. You just need to do Kanban right.”
As my friend Luke is fond of pointing out, most people don’t know what Kanban even is, thinking it’s more of a presentational approach than a whole methodology.
Regarding this post, which I have read once and have marked to read again more carefully, the one thing that stuck in my craw a little was the theme of “making work visible,” because – and I need to do that second read – it seems that visibility stops at the edge of “the team.”
Scrum may, indeed, be “manager training wheels,” and it can definitely become brittle in the face of “a stochastic process such as software development.” But it also makes a team (or organization’s) work seem more legible to the rest of the business, which is busy trying to understand what’s going into the next quarter’s training offerings, messaging briefs, marketing plans, forecasts, etc.
One of the lessons the Fourth International took away from the failure of the 1917 Russian revolution (not the eventual “Berlin wall comes down” failure – the “oh, did you intend for there to be Stalin?” failure) was that you can’t have socialism in one country. A friend of mine did his master’s work on intentional communities such as the Amana Colonies, Harmony, etc. and found similar: Given a local system that is misaligned with its broader context, the broader context takes advantage of its encirclement and either forces compliance or increases pressure until internal contradictions destabilize the system and cause it to either fail, or betray its own principles in order to “survive.”
I’d love to talk to someone who’s “done kanban” as their agile methodology on an enterprise delivery footing. Not because I don’t think it’s possible, but because I’m curious about how it worked.