[UX] Design video experience for playing outside a focus region

[jonbell-lot23]

Today, the playhead stops when you reach the end of a focus region. We're moving to a design where it won't stop there, so we want to think through the implications of this and make sure we have a design in hand for it.

Figma link

Design POV Loom: https://www.loom.com/share/e59795a2703b45eb8cf6116e075b6121

Visuals

[jonbell-lot23]

cc @bvaughn @jcmorrow @jasonLaster check out the loom above to see my design POV for how to handle the "video playing outside video region" UX.

[bvaughn]

@jonbell-lot23 Great Loom walk through! Left a few questions on the video:

1. What do we show above/below the logs when we don't know the number of logs that were hidden? (We might not!)
2. What happens if you click the text "your focus window" ? Is that a link that opens our doc about focus windows?

[jonbell-lot23]

1. Ah! Yeah, we can just use generic copy there.
2. I was thinking it would launch our standard focus mode (like pressing shift-f), thoughts?

[jasonLaster]

Love where this is headed as well

1. would not be opposed to adding right click with some simple actions (add comment, play to here, jump to focus start). I think there's little downside in being wrong and upside in experimenting
2. i wonder if there's value in adding the timestamp in blue on the right of the console focus overflow row? could see the argument both ways.
3. re focus vs debugging copy: Josh and I were discussing the term "Execution window" yesterday. Stay tuned 😉

[jonbell-lot23]

little downside in being wrong and upside in experimenting

Totally agree. And people are much more likely to request a feature they're missing than provide feedback about one they don't use. So I'm going to use a little verbal jujitsu here and say we both agree with the benefit of experimenting ... which is why I think it's important to not have these options yet and see who misses them.

My thesis is zero or nearly zero people will miss them, and I'd like to prove that out. Because there's big upside in experimenting, as you say. If my thesis is wrong, it's super easy to add the right-click later! Let's experiment for now.

[jonbell-lot23]

(Closing this for GitHub iteration tracking reasons. We're at a good place with the design, so now we're in discuss->code it up territory)

[bvaughn]

Couple of edge cases I'm thinking through:

Scenario	Solution
What do we show if there are too many messages to fetch them all? We can't show the number of filtered messages before/after because we literally won't know.	Based on previous messages on this thread, I think the plan is for us to show a generic message like, "There may be some logs before/after your debugging window."
What if we've focused and still there are too many messages to send?	I assume we show the above header/footer message along with the existing "There are too many console messages..." warning.
What should we show if we can't fetch all messages for the entire recording (so we don't know the number of trimmed ones) but the current focus region has no logs?	I assume we should just show a single row that says something like, "There may be some logs outside of your debugging window."
How does filtering fit into this? If the user types in the "filter output" box (or deselects logs/warnings/errors) we may filter existing messages in a way that isn't related to focus mode.	I think the filtered before/after message should stay the same, but the count should be updated to reflect only messages that match the current search/filter criteria.

[jasonLaster]

@bvaughn agreed with you'e assumptions. For historical purposes, it would be easier to read this as a table w/ a Q and A column.

[bvaughn]

There is one more awkward edge case.

Scenario

Solution

What if we have loaded all of the messages in-memory, but the backend has unloaded some regions after the user assigned a focus mode. (We filter out messages that are outside of loaded regions, presumably because we can't support things like object inspection?) In this case, we know how many messages we've filtered out due to unloaded regions– but they aren't necessarily before or after the visible logs. They might be right in the middle.

By default, we just won't show a count for these messages except for the case when all messages have been filtered out, in which case we could include their number in the single row we show.

It might be less confusing for us to render these messages in a partially disabled state (so you can't inspect for example) but at least they'd be visible. Alternately, we could render a little inline "loading" indicator or something. This would make our filter count messaging more consistent / less confusing.

cc @jonbell-lot23

Edit – We won't encounter this scenario anymore because we will no longer filter messages under that condition.

[jcmorrow]

but they aren't necessarily before or after the visible logs. They might be right in the middle.

We should double check this, but I don't think the backend will ever unload regions in the middle of a recording. Or at least... if that can happen... then so many things will be broken.

[bvaughn]

It's not in the middle of a recording. It's outside of the (current) focus region– but if we're dragging around a new focus region, we update what we show in the console as you refine the region, which might include logs that are in (not-yet-reloaded) regions.

The thing is, these logs might be in the middle of the new, pending focus region, so it makes no sense to show either an "X hidden before" or "X hidden after" message.

[bvaughn]

We've chatted over VC and decided to just show the logs in this case 👍🏼 Feels like a better UX for me (after trying it locally).

[bvaughn]

It's not clear to me under which circumstances a user would see this message:

I don't think we allow users to set breakpoints (or step to them) outside of a focus region. That's part of the point of "focusing"?

[jonbell-lot23]

I don't think we allow users to set breakpoints (or step to them) outside of a focus region. That's part of the point of "focusing"?

@bvaughn that was a quick sketch from chatting with @jasonLaster so I don't have as strong a handle on it as Jason does. I think you'd get here by:

1. Not being focused and setting breakpoints
2. Focusing to a point where breakpoints aren't shown

But that's just my guess