cover image courtesy of Nathan Anderson

Is It an Article or a Deck of Slides?

Bits by bits I'm building a feature in my personal site, where all my talks have a readable "article" mode which is literally just my talk script, and a "presentation" mode which turns the same content into playable slides. Privately, there's also "speaker" and "notes" modes which includes or exclusively displays my notes.

Note This article is not finished. And it will be a nonsense article documenting the stories and thoughts behind building the features, with links to notes about things I learned building them.

Why this

Motivation

  • I believe that a good talk (script) is also a good read, so why not make one file compile to both
  • Slides are not good presentation of resources after talks, who plays them? So what are we actually sharing when we share links to our slides? Likely we're sharing the resource links, some code, references, etc. What about people who never watched the video but landed here for the content? I think the best browsing experience is probably to share it as an article.

Prior arts

Why still do dis

  • most existing libraries focus only on slides, whereas my idea has its root motivation in good talk scripts are also good reads, so what I really want is one content compiling to two (or more) formats
  • it's a "do chefs cook at home" problem, I want to home cook my own slides library because, because ¯\_(ツ)_/¯

Clearly you're joking, Wei

I got a push into actually doing this when me and our co-organizer, Ken, were preparing for our first React Knowledgeable meetup. Throughout our past year of running RK internally, we had been passing markdown notes on what to include in each week's session. This then became another use case for the idea, why don't we simply compile the notes into a presentation slides?

It was the weekend before our first meetup. Ken was going to host this and he asked if I had anything in mind in particular that we should include. I told him I'd create slides for him that he could then add on to. So that became the initial version, which I was clearly cheating. All I did was to put each heading into a <section> tag, and make each <section> full screen size. And you "page" by pressing the spacebar 😅. You need to tweak the height a little bit to make it equal to how far a spacebar travels.

Recipes

I then moved the whole cooking into my personal site and slowly building the thing bits by bits. And I'm using it for my own talks such as why i write docs for JSConf China, devtools for RK, and more.

Over the course, whenever I want certain feature from normal presentation, I struggle between

  • use that other framework, which will involve extra work creating the slides on that framework, and
  • build that feature on my slides

Slowly, I find myself struggle less and less between the options because my slides are getting more refined, satisfying more of my needs, and more fun to use because I can build whatever I like, such as:

  • customizing styles
  • keyboard shortcuts (vim-flavored navigation)
  • Joy-Con Clicker, remote control / clicker using Switch's Joy-Con

Learning

And it then becomes my playground to learn about web techniques:

Request Fullscreen

Slides should be played full screen when prensenting. When you maximize window with Chrome, it hides the URL and the bookmark bars for you. But if you use FireFox, you cannot hide them unless you request fullscreen.

more

  • cross-tab communication
  • keyboard events, MDN doc
  • markdown parsers and in particular, the unified ecosystem
  • the whole controller is written with React hooks and that's some thorough examination about my understanding on closure

Links

Prior arts

Link to my notes