This is an excellent idea, it is a bit hard to use though.
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.
I figured it out easily enough, adding annotations and removing them was understandable enough, what the annotations did was a bit trickier but I think documentation would be better than a tour. A reference gallery showing what each one does would be ideal.
+1 to this. Not sure if it was just that 'play' was too fast (I agree with the other comment about 'play' probably not being super useful here), but on my 27" 2560x1440 monitor, it took me a few slides to notice that there was even text at the bottom changing. I thought I was just supposed to read the comments.
+1 - came here to say this. I love the idea, but the text block at the bottom of the screen and the corresponding code at the top left is a bit of a pain to go back and forth to with your eyes before the time runs out. It would be great if the text was much closer to the code.
I think that the default behavior should be that the user has to click or press the keyboard to progress the story. I started reading one of the stories, and it quickly went faster than I was processing. (Partially because I am unfamiliar with the source language and framework.)
I think that pause-by-default is more important than keyboard support. Put another way, I don't think that "play" as in "play a movie" is the right metaphor. I think that by default, the user should control progression forward and back, like scrolling through slides or flipping the pages of a book. Each person is going to want to linger on different steps for different periods of time, because we're all going to want to read different things along with what just changed.
Not sure either way, but if you keep play, the user should be able to click both play and pause without moving their mouse. currently, play appears a couple inches to the left of pause.
For me, this issue is made worse by the fact that the text boxes can pop up basically anywhere... More than once in watching the first story, I only just located a new text box just as it was disappearing, and I had no hope of reading it.
Can you make the textbox draggable? Or at least, reposition it near the center? It's a bit difficult to switch between reading code and reading the story.
It looks cool, but needs some mobile love. The screen gets very crowded on a phone, and feels very chaotic with things popping up and moving around. Touching the screen makes stuff scroll away from what the presenter intended, making it hard to figure out what's going on. Also, touching the "go back" button in the overlay triggers the phone's text selector, and seems to randomly bring you back to the very start of the presentation.
It definitely needs a more visible way to lead your focus. It's hard to tell what you're supposed to be looking at.
This is awesome, I've wanted a similar tool before. Is this open source or are you planning to commercialize?
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?
Current plan is to make this available for free to public repos. Will be adding an app in github marketplace for private repos. Code will be open sourced after some cleanup.
A copy of the code is stored in the DB. so its a snapshot of when you created the story. The annotations are react components added on top of the code. Soon you will be able to add custom components to annotate the code. (WIP)
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.