Show HN: StoryTime – Create stories about your code instead of documentation

I like this mode of explaining code things by slowly building up &amp; talking through examples. I have been doing this in talks for a while to go over code bit by bit without live-coding. Examples:<p>1. click &quot;present&quot; &amp; advance step by step to see transitions <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;presentation&#x2F;d&#x2F;1KVMwffTe-aam8Mq7LwfZzXwtlcy-VRHrBPk20x47_zk&#x2F;edit?usp=sharing" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;presentation&#x2F;d&#x2F;1KVMwffTe-aam8Mq7LwfZ...</a><p>2. Advance with spacebar: <a href="https:&#x2F;&#x2F;sequoia.makes.software&#x2F;composer-talk&#x2F;#&#x2F;7&#x2F;1" rel="nofollow">https:&#x2F;&#x2F;sequoia.makes.software&#x2F;composer-talk&#x2F;#&#x2F;7&#x2F;1</a><p>I describe the process here: <a href="https:&#x2F;&#x2F;sequoia.makes.software&#x2F;techniques-to-avoid-live-coding-part-1&#x2F;#solution-2-code-quot-fade-ins-and-highlighting-" rel="nofollow">https:&#x2F;&#x2F;sequoia.makes.software&#x2F;techniques-to-avoid-live-codi...</a>

Innovative ways to explain code is a great idea and I love the project.<p>However, I don&#x27;t love the name.<p>These are explanations - not stories (unless we consider stories as being 100% exposition). There&#x27;s no beat, scene, or chapter structure that pushes meaningful values back and forth in the face of conflict (&quot;make it work&quot; isn&#x27;t a meaningful value - since it&#x27;s the obvious goal of every character here), no progression or character building, no subtext or sub-agendas, no sense of agency or suspense where the code might pursue something counter to its purpose...<p>Feel like it&#x27;s a bit of hijacking of &quot;story&quot; in order to make headlines, since &quot;code explainer&quot; isn&#x27;t as sexy.

The links at the bottom look like ads. I unconsciously ignored them until I visited the page again.

Hi, OP here. Would love to get some feedback from HN community.

The story text at the bottom is too far away from the code for me so I constantly need to &quot;switch&quot; between them and I don&#x27;t have time to read both. Any reason for not putting it next to the code?

It moves a little too fast for me to read the message (bottom of my screen) and then flick my eyes back up to the code and internalize what it&#x27;s doing. I&#x27;d prefer speed controls at a minimum but really I just want to hit space&#x2F;right-arrow to progress when I&#x27;m ready... Like a slideshow presentation.

Bug:<p>It looks like you&#x27;re hitting the `master` branch by default - GitHub allows you to set other branches as the default for the repository. Several of my repos have `primary` as the default branch and don&#x27;t even have a `master` branch, which causes this to fail.

This is very cool. This is basically what I do when I&#x27;m making a presentation and talking about a block of code (albeit with a ton of work in Keynote to make it easy to follow).<p>I think this is a really great way of explaining code, and I hope it this makes it easier for people to adopt.

Great work! I would love to see the comments inline next to the current highlighted lines vs. at the bottom of the screen. Also having this like watch windows would be awesome as well, especially if you can clearly see the different state transitions that happen.

I see a lot of comments on the usability improvements have already been surfaced, but I wanted to print out that one possibly invisible implication of this is that accessibility is an important aspect of these changes. I hope in addition to the visible changes of keyboard controls some attention. Is paid to ensure that the function of the tool is accessible to people with visual and motor impairments. Having good aria tags for descriptions, controls, politeness settings for changes and ensuring you using the right elements for the controls. The WAI and WCAG guidelines are both great resources to check for more info. (Sorry on mobile and check myself or easily get links).

In the &quot;Start Now&quot; section, don&#x27;t make me type something in if you have the default text. Right now, the text appears to be there but clearly we visit <a href="https:&#x2F;&#x2F;storytime.dev&#x2F;&#x2F;blob&#x2F;master&#x2F;" rel="nofollow">https:&#x2F;&#x2F;storytime.dev&#x2F;&#x2F;blob&#x2F;master&#x2F;</a> instead of <a href="https:&#x2F;&#x2F;storytime.dev&#x2F;facebook&#x2F;react&#x2F;blob&#x2F;master&#x2F;" rel="nofollow">https:&#x2F;&#x2F;storytime.dev&#x2F;facebook&#x2F;react&#x2F;blob&#x2F;master&#x2F;</a>

Very interesting concept, thanks for sharing! Context and intent are critical when trying to understand code - this looks like a useful way to capture that. Merging the call stack display with the &quot;debugger&quot; is IMHO a particularly good idea.<p>Out of curiosity: have you explored stories for code _over time_ at all? It might be useful to be able to build stories for a block of code that change from commit to commit as the code itself is mutated.

The text snacks should show up next to the code. Not fixed to the bottom. It makes it hard to follow.

&gt; Add memes and GIFs as you walk the code!<p>Cristo.

A really polished version of this could get you acquired by MS for a hundo million I feel.

Very interesting concept. I found that the transitions were too quick for me to read the descriptions at the bottom of the page. It might be nice to set this transition interval or perhaps click to advance.

This looks pretty cool. One thing I&#x27;d like to see that could make it really useful is oembed support, I&#x27;d love to be able to embed a sort of mini-tutorial on my own blog post.

There is a typo on the landing page.<p>StoryTime enables developers to easily simulate a debugger-like visuals to tell or read a story about pieces of code.<p>There shouldn&#x27;t be an &quot;a&quot; in front of debugger-like.

I love this. This is how I document my side projects, I tend to write long stories to myself with chunks of code thrown in for clarity. This is much more elegant though.