Hacker News Reader

Hacker News

Comment by vidoss | Hacker News Reader

Parent Full thread

vidoss

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

View on HN

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.

Great feedback. Moving this line by line to my TODO. Thanks again.

btw, was the editor intuitive to use? I am thinking of adding product tour like popups on that page to get started.

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.

It may be a good idea to move the story text closer to the code. On a large monitor, I have to move my eyes quite a bit and it feels disconnected.

+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.

Agree. Other than that, I really like this as a concept and can't wait to see where it goes from here. Will be keeping an eye on this for sure.

Even on a small monitor I'm missing things because my eyes have to check two different places to see if they changed.

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.)

Good point. Will add keyboard support.

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.

Thanks. There is step forward / backward icons next to play. Maybe should just kill play?

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.

That's my feeling yes, but I would check with other people, too!

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.

ya, starting to think play is more distracting than helping.

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.

Noted. Will do.

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.

Glad to hear it, looking forward to seeing it.

so, what if my code has changed, will an old story matches the new code?

a related project you might be interested in https://ourcodestories.com/

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)

Reply on news.ycombinator.com