I would like a tool that does something similar to this but on a more ad-hoc basis. i.e. to track my own explorations and understanding for fixing a given problem in a code base.
I'll also admit that I had a hard time understanding exactly how it worked.
It wasn't completely clear for each 'slide' what code was being referred to, I think the highlighting of the code being explained needs to be much more defined or the dimming of surrounding code needs to be more pronounced.
I think it would also be better if there were markers directly in the code side of the window that you could hover over to highlight parts of the slide that are relevant. It would also be beneficial if it also worked the opposite way. i.e. when clicking on a marker in the slide, scroll to the relevant code.
I also think your datapipeline example doesn't really show the value of the tool. i.e. it seems like a very straightforward piece of code that could just be read directly.
How are you planning to keep the slide information in sync with the files on github as they change?
I may not be the target audience for this because I would like it to work with code on my local machine and would only publish if I wanted advice from another programmer and then I would push up my branch and provide a link to the codeflow.
> I would like a tool that does something similar to this but on a more ad-hoc basis. i.e. to track my own explorations and understanding for fixing a given problem in a code base.
We're changing the dimming of the non-highlighted code right now -- that's feedback that we've gotten before.
We're also looking into ways to embed code into the markdown, and scrolling to the relevant code is a particularly good idea.
I think a lot of the value comes from when you're not sure how to navigate the codebase, so I agree that the example doesn't show the total value of the code. In larger codebases that are harder to navigate, I expect these to be much more useful.
Right now, we save the ref of the commit the slide was created on, so it's possible that the code will go out of date, but the slides will always be in sync.
One niche we were exploring was remote teams. We saw that they generally resort to screensharing to explain code and thought that this may be a better, faster alternative.
I'll also admit that I had a hard time understanding exactly how it worked.
It wasn't completely clear for each 'slide' what code was being referred to, I think the highlighting of the code being explained needs to be much more defined or the dimming of surrounding code needs to be more pronounced.
I think it would also be better if there were markers directly in the code side of the window that you could hover over to highlight parts of the slide that are relevant. It would also be beneficial if it also worked the opposite way. i.e. when clicking on a marker in the slide, scroll to the relevant code.
I also think your datapipeline example doesn't really show the value of the tool. i.e. it seems like a very straightforward piece of code that could just be read directly.
How are you planning to keep the slide information in sync with the files on github as they change?
I may not be the target audience for this because I would like it to work with code on my local machine and would only publish if I wanted advice from another programmer and then I would push up my branch and provide a link to the codeflow.