Jump back to prior pause

[jasonLaster]

Users should be able to press cmd-z and jump back to the last pause location.

[jasonLaster]

From @Andarist

Its just a cheap idea for a bigger problem - there is an overload of information and categorizing them is hard work. Im jumping between distant call sites to inspect various things and writing a good condition for a logpoint is not always possible (or is time-consuming)

If i jump from some A to B and then i want to get back to A then it’s often hard for me to know which A should I rewind to - since I have a lot of As in the console

Cmd+z idea partially addresses this - but its not always the last pause point that i want. I exactly know where i want to get - its just that logged labels are the same for a given A and after a while i cant see which A i should click on

Another idea to solve this and some other minor issues - expose smth like $replay.hitCounter. I could use this bith for logs and conditions (the latter less often but at times i could use smth like this)

And also - the hit counter badge, like 4/20 -> make it contenteditable or smth so i could write which hit i want. Clicking on a timeline doesnt allow me to be precise and jumping one by one is tedious

[jasonLaster]

• on the backend, it's easy to inject some variables for the index, count
• i like the idea of letting you type 8 or 123 into the counter.

I wonder what we can do with comments to make them easier to bookmark interesting spots too.

[jonbell-lot23]

I like all of this.

There's no question that part of being in flow is jumping across multiple locations, so having some quick way to traverse back could be huge.

And the editable breakpoints idea is interesting. I would have thought that knowing the exact hitpoint out of 20 isn't particularly common, but you're saying sometimes it's helpful? If so, yeah, I think that sounds great.

[Andarist]

I would have thought that knowing the exact hitpoint out of 20 isn't particularly common, but you're saying sometimes it's helpful?

It's not as much about knowing the exact hitpoint - like, I don't need to know that information. It could aid me though to remember which one I should rewind to if I have a couple of logs like:

init 17  sdk.js:17 
init 17  sdk.js:17 
init 17  sdk.js:17 
init 17  sdk.js:17 
init 17  sdk.js:17 

Note that those can be interleaved with other logpoints and that is also a moving target because adding new logpoints can separate those more etc. So it's really hard to track the one that I'm interested in - it's partially because, even with conditional breakpoints and all, it's still hard to minimize the number of logs.

[jonbell-lot23]

Makes sense. Something I am always reminding myself of is separating "insight" from "implementation." (See also: Jobs To Be Done and the Milkshake Story)

So the key insight is solid -- let people traverse quickly through a lot of information. Whereas the implementation itself is harder to get exactly right and will take some experimenting. Thanks for the insights!

[jonbell-lot23]

March 15, 2022:

In the broad bucket of "it should be easier to jump around" we're doing a lot of little improvements. Just flagging that this is a discussion point that fits into that bucket.

[jonbell-lot23]

Hello! This issue has a pending PR so I want to summarise it for everyone. Paging @Andarist !

--

The original insight: it's hard to distinguish print statements

@Andarist pointed out that "in the console we get all the logpoints for a given line - but its hard to distinguish between them." There are a lot of ways to handle this, but that's the core insight.

1. Implementation idea: control-Z to "undo" and jump back

Anderist pointed out the flaw of this: "Cmd+z idea partially addresses this - but it's not always the last pause point that i want." He reiterates that the issue is having lots of logs and not knowing how to get to the right one.

2. Implementation idea: allow jumping directly to a hit via an editable textfield

We did this about a month ago, yay!

3. Implementation idea: optionally show counter labels in the console

Anderist also said: "Another idea to solve this and some other minor issues - expose smth like $replay.hitCounter. " We explored this in this PR.

Design recommendation

Cmd-z is not recommended

Command-Z means "undo." If you type something in the console, then type something into the filter, then rename the Replay, command-Z will back out every one of those changes, which is a standard pattern in modern software. If we use command-Z, we'd need it to work seamlessly with standard command-Z behaviour. I don't recommend it.

Option + right/left arrow is not recommended

Option + modifier key is also a reserved action. On Mac, it jumps someone forward a word at a time in any text area. This means any time our cursor is in a textfield or text area, we'll be working against the grain of how textfields work in all modern software.

Command-[ can work

Command-[ is what browsers have always used to mean "go backward," which makes it a compelling choice. This means we'll be working against the grain of every keyboard shortcut-using browser user because we're suppressing core system functionality. (e.g if you come from stack overflow to replay, then press command-[, nothing will happen and that will be confusing to some people.) But in the gray area of web apps, that's a reasonable tradeoff.

[manavagr1108]

Hey Everyone! The pending pr was opened by me. That's why I feel, it's my responsibility to complete it. Here's my suggestion that I would like to propose.

Implementation Idea: ( its a combination of Implementation 2 and 3 )

• While we watch the recorded replay, we have a tab called Replay Info and it has two sections Info and Events. I was thinking to add another section called Current Events or Pauses ( we can rename it if we want ) and also renaming Events to Video Events so that it doesn't confuse the user.
• Inside Current Events we can have it similar to the Video Events section and update the section as the user pauses in that section and name them pause1, pause2, pause3 ..... in this way it would be easy for him to track back to his previous pause.
• We can also allow the user to rename the pause for his future use.
• Along with this we can also allow the user to navigate the user between these pauses using the shortcut keys cmd+[ and cmd+].

[jonbell-lot23]

Thanks @manavagr1108 ! Those ideas definitely address concerns we've had in the past, and it could work really well!

That said, I am concerned about feature creep. Here's what I propose:

• Let's ship this PR with command-[ and command-] and make sure it works really well.
• Then, as a separate PR, it'd be great to see the approach you're describing in a different PR.

How does that sound?

[manavagr1108]

Thank you @jonbell-lot23. Sounds cool to me. Glad that I could resolve the problem. Sure I am more than happy to implement this feature.

1. So I will update this pr with cmd+[ and cmd+] also I will try to make sure it works well.

2. I will start working with the second PR as soon as the previous PR is shipped.

[jonbell-lot23]

Thank you! And I want to be clear: I'm not sure if this second proposal will necessarily ship, but it'd be great to see how it feels. If it does feel good, this would definitely address a long-standing issue!

[manavagr1108]

No worries @jonbell-lot23, I will try to make sure it feels great to use. Also sorry about the late reply.
Please do check out this comment on my pr. This needs your assistance to proceed further.