1. click "present" & advance step by step to see transitions https://docs.google.com/presentation/d/1KVMwffTe-aam8Mq7LwfZ...
2. Advance with spacebar: https://sequoia.makes.software/composer-talk/#/7/1
I describe the process here: https://sequoia.makes.software/techniques-to-avoid-live-codi...
1) Not sure about private repos 2) I'm sure it doesn't work against bitbucket :(
However, I don't love the name.
These are explanations - not stories (unless we consider stories as being 100% exposition). There's no beat, scene, or chapter structure that pushes meaningful values back and forth in the face of conflict ("make it work" isn't a meaningful value - since it'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...
Feel like it's a bit of hijacking of "story" in order to make headlines, since "code explainer" isn't as sexy.
User stories have been used for quite a long time for both software architecture and establishing/informing QA and testing processes.
This strikes me as user stories without the "user". It's the same concept at a different level of abstraction. A "code story" is to a unit test as a "user story" is to an integration test.
> This strikes me as user stories without the "user"
It strikes me as "code stories" without the story. They're literally just explaining the code. Glorified comments with a slick UI.
That is useful though, I really do think it's a cool product - I often feel like comments take up a lot of screen real estate and sometimes want to go deeper with explanations. It is a great idea to move them out and make them more like a slideshow with even more opportunity to do so.
User stories aren't stories either, they are feature requirements from a user's point of view.
I feel like this is all the inverse of when we watch movies that have hackers. There's a craft to storytelling, there's a craft to programming, and we can't just assume that superficial similarity is enough. When a character in a movie types a bunch of garbage onto the screen, that isn't programming. When a software manager describes feature requirements from a user's perspective that's not a story.
I think small children are pretty good at telling the difference since they consume stories voraciously... try reading them a book of "user stories" or "code stories" and see what happens.
(I get that you're saying it's not a story in the literature sense - but that's my point, there is no other sense and these other things are hijacking the term. By "literature" what I really mean is any medium that can properly express a story - song, dance, etc. are all genuine, proven storytelling avenues too.
The reason I jumped on here wasn't to be a downer - it's because I was super excited, I thought someone figured out a way to use code to tell stories! That would be awesome... Unfortunately that's not what's happening here and I was super disappointed. sorry!)
It looks like you'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't even have a `master` branch, which causes this to fail.
I think this is a really great way of explaining code, and I hope it this makes it easier for people to adopt.
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.
Cristo.
StoryTime enables developers to easily simulate a debugger-like visuals to tell or read a story about pieces of code.
There shouldn't be an "a" in front of debugger-like.
I’m just not a very good programmer so unless I explain to myself what this code does and why, I’m not likely to remember why I wrote it.
Some thoughts.
I would prefer breakpoints to be disctinct from the current execution position.
When thinking analogously to a debugger, Breakpoints indicate where the program should stop not where the program currently is, and consequently breakpoints can exist on multiple lines at once.
I prefer a different graphic to indicate the active line. A line highlighted colour would be enough
On my machine the area that is active for the 'line annotations' pop-up menu has no visual cue to say that it is there.
It appears to crete a new 'line annotations' menu for each hover with the old menu lingering a short time before dissapearing, this looks quite odd.
I have achieved multiple perminantly open 'line annotations' menus at the same time.
It would be beneficial to have line ranges on annotations so you can higlight a block of code.
Adding a new frame duplicating the current annotations would be good. Either that or have a way to declare the same annotation applies to multiple frames.
Having the ability for an annotation to collapse a section of code to ... for within a single line or \n...\n for multi line collapse would let people focus on the code being explained.
It definitely needs a more visible way to lead your focus. It's hard to tell what you're supposed to be looking at.
One bit of UX feedback - the modal with the commentary text is a bit low on the screen (at least on chrome on a 15 inch retina display), I think it would be better to have it higher up on the page, or possibly even aligned with the current line?
a related project you might be interested in https://ourcodestories.com/