replayio / design Goto Github PK

Tracking the proposed changes here: https://www.notion.so/replayio/Hats-overview-c8fb98b59d744d5197cc7096fcb6e519

• Print statements
• Network monitor
• Comment panel

Background

While exploring Design Library 1.5, it was clear that we have three different changes, which I've split into three GitHub tasks:

• Add details pane to library
• Add filters to library
• Create CI-specific library

The pause line in dark mode is a bit too subtle. Also, not sure if the "flash" is noticeable in dark mode.

https://discord.com/channels/779097926135054346/957390059714281482/967760989095350272

I thought this was a bit awkward. Might be good to re-write the text in a way that doesn't assume the team name is a person name.

Discussed in replayio/devtools#6531

Developers need things to be keyboard accessible, and one of the first steps for this is making sure tab support is great.

Design POV:

Link to Figma

I discussed with @ryanjduffy and @jasonLaster in person, here's the summary:

• There should be a spot to show enterprise logos at the top. Notice how I made the background white -- that's because this is typically what ends up happening on enterprise installs. Transparency is often too much to ask 😂
• If you are part of multiple orgs, we'll have a little menu to switch between orgs
• Notice how everything in the sidebar is on the same level, not indented. This is by design. We're trying every team as a peer to each other, and not showing a single unified "org view."
• Notice the different icons (we can pick different icons later). Standard teams will have a certain icon, test suite teams will have another, and things like My Library and Shared with me will have another.
• "Shared with me" isn't strictly part of the org information architecture but it's a thing we should expect in our future

It seems like we'd be more consistent if the button did not have a border

The dark theme hover background somehow doesn't show the same rounded corners that the light theme does.

@oliverdealb said

"on call with Dyanboard CEO yesterday, he raised a request to be able to switch a setting in his Team so Replays are always shared by default. He mentioned Loom has a nice shortcut (cmd + shit +L) which makes it much faster to share recordings and have all of them available in the library. think this would be a nice feature for Team or Org plan settings?"

Jon says:

I don't understand the exact details yet, but yes. This sounds great and is a real pain point.

Jon note to self: we also need the ability to select a bunch of items and make them all public at once

We do a pretty good job with this basic accessibility feature of HTML but we're missing it in some spots.

Jaril gave me a customised login screen for onboarding. Now it's time to customise it!

Right now this happens:

1. 500+ limit
2. User has to know to go to Focus Mode
3. User drags one side in
4. User drags the other side in
5. User clicks away to commit
6. User tries again

This should be replaced with two things:

1. Messaging about Focus Mode (I thought we did this already but maybe not)
2. A single click that applies focus mode to the point you're paused on

Here's the original issue we filed for this

In this screenshot, we say "check the console" but it's not clear what we're referring to:

We are working on our Rainbow Console design, but this issue addresses a more immediate need: our onboarding process needs a way to make this line more clear.

@jonbell-lot23 heads up

We're currently making progress on helping the user understand the replay's current loading state in #40.

To recap:

1. Replay should communicate progress loading regions
2. Replay should communicate progress buffering the video

This is good and we should move forward here. There is also a larger progressive loading project which we can call insta loading.

tl;dr
Brian recently added support for creating a replay session for a partially uploaded recording. He added it to support the cloud-dev flight recorder, but it can also be used to help users view replays as soon as they click save in the Upload screen.

What changes

1. Replay would need to communicate the current uploading progress. We actually would know the replay duration, so this is probably fairly reasonable.
2. Replay could also communicate if there is a failure loading a region. Today we kick users to the error modal, but showing the right most portion of the replay timeline after the crash as red might be less jarring to users as they could continue debugging prior to the crash.

Prioritization

We can give this time to bake on the design/product side and implement it when we're ready. My best guess would be June/July. The obvious user benefit is that we could open replays pretty quickly.

Insight

It's easy to lose track of console logs. Originally we were going to set a solid background colour for all of our print statements. (Old issue here) But something many of us have discussed for ages is the ability to highlight rows and add emojis to help find a needle in a haystack. So we're going to build that.

Next steps

Jon Loom video explaining the details

Figma link

When people hit their 500 hit limit, there are two main ways to handle it:

• Set a conditional in the print statement window
• Use Focus Mode

Unfortunately, our conditional button is too subtle for people, and most people miss it. This ticket is for Jon to think up ways to make it more clear. Adding to the 500 hits error message is a good start, and there are also visual things we can do to the button itself.

Suggestions

• Next previous buttons could use a fill which would be more consistent with other buttons
• The summary body could be white which would be a tad lighter
• The edit mode footer should just show the condition button. This will make it more discoverable
• #21
• #10

Figma

Proposed

Current

Background/the problem we're trying to solve

We have made many improvements to our timeline over the last year, and this is the next step forward. These items should be as clear as possible when using our app:

1. Where the playhead currently is [good]
2. What regions are ready to play quickly [misleading]
3. Messaging when things are slow/laggy/not ready [bad]

Details: What regions are ready to play quickly

We currently use a slightly different color in the style of Netflix or YouTube to say "this region is fully loaded and ready to go. Click here and everything's gonna work great." But it doesn't. It is often slow.

Proposed fix: we need better messaging here.

Details: Messaging when things are slow/laggy/not ready

It's possible to click into a portion of the timeline and not get a meaningful explanation about what's going wrong.

Proposed fix: we also need better messaging here.

Proposed plan

1. First we should ship https://github.com/RecordReplay/devtools/issues/6671. Let's get that out as designed, then we can build on that foundation.
2. Once that's live, we need to think about how/where we're going to message stuff. Coming soon.

The design that we'll probably land on

• Mousing over the loading indicator on the bottom right will light up indexed regions in the timeline
• Mousing over the play button on the bottom left might do something -- stay tuned
• When we know things are slow, we'll put a spinner on the playhead indicator (aka clown nose)
• You should be able to click absolutely anywhere, loaded or not. Just a matter of messaging.
• Mousing over the loading clown nose might show a tooltip that shows progress.

Other considerations

There's more thinking to do around unloaded regions. (See tickets below) Stay tuned for that.

Resources

Ticket: Difficulty using player when parts of recording are unloaded
Notion: Josh, Brian, Jon notes

https://discord.com/channels/779097926135054346/966563248776282133

@jonbell-lot23 I'll let you edit/fill in the details!

From @bvaughn
https://www.loom.com/share/bde37fcb2aef4a52988afb81b34718b3

From @jasonLaster

• I think the console comment interaction could be useful in the network monitor as well
• I also think we should have a comment button on the request/response panels as well. Discussed it in my 9min goliath of a talk, but adding more contextual comments will be a theme

From @jcmorrow

• I agree with your instinct Brian, for context the reason it is not there is, I think, because not every request shows a fast-forward/rewind button (unlike console statements), so the "FF or rewind, click again to leave a comment" flow does not work reliably
• but I like the idea of keeping that interaction where it works, and otherwise jumping straight to comment
  so if it's "if ff is possible, first click fast-forwards, second click comments" and "if ff is impossible, first click comments" that could be an annoying interaction
• I don't remember actually discussing this the first time, but I suspect that was the thinking

From @jasonLaster

• yeah - you definitely need selected in those cases.
• I think the experiment I'd run would be:

1. if has a point, show ff/rew in general and comment when paused there
2. if no point, show comment

(Hope it's okay for me to create an issue here as a placeholder for us to chat about something next week!)

I've been looking into https://github.com/RecordReplay/devtools/issues/6511 and https://github.com/RecordReplay/devtools/issues/5606 this morning, and I spoke with @jcmorrow a little bit to fill in gaps in my knowledge for when certain conditions might occur– and I came away with a pretty strong intuition that the timeline UI (as it exists today for public users) is maybe missing some pretty crucial information about "loaded regions" that might lead to some bad user experience scenarios (particularly as we move toward longer recordings).

Some timeline specific concerns I have:

• We already do a good job of differentiating between focused and unfocused regions (solid vs dashed line). I think we need to also clearly distinguish between loading and loaded regions. (If I'm viewing a recording and the backend unloads some regions– this has a big impact on what I'm able to do– and I don't think it's currently very obvious to the user (a) what happened and (b) wha to do to "fix" it.
• Our focus tool (the thing we use to zoom in or out) currently does some things that are surprising. (e.g. clicking outside of the focused region moves the region and there's no undo, e.g. I can't drag a region– i have to instead move the start and end ranges separately). This tool feels like something people are going to use a lot especially with longer sessions, so it seems important for us to make it as perfect as possible.

Another topic that shook out of those tickets and the subsequent convo between @jcmorrow and I was:

1. The concepts of "focused" and "loaded" are different. Focus is about user intent. Loaded is a technical constraint (e.g. we're loading this but it's not done yet, or we had to unload this because the recording is too large). They're also very closely related in the devtools in terms of the capabilities/data we have to display. I think it would be easy to mix the two together in ways that might be confusing to a user, and we should be intentional about when we lump them together and when we don't.
2. We should be consistent in how things that are outside of the "loaded region" get visualized, and how you interact with them (or don't) so that it's not confusing or surprising to users when they can't e.g. click on a network request in the Network tab.

Maybe we can brainstorm about this? 😁

cc @jonbell-lot23 @jaril

Background

We explored loading states here in Figma

Now we're narrowing in on something that can help us untangle loading from indexing in a model that's clear and understandable without being overwhelming

Proposal:

Here's a one minute Loom explaining how this could work.

Here are some visuals:

We know that in the long run, we want an Xbox/Playstation style "grab last minute" button. This is why we're doing 10 minute recordings and getting other foundational technologies moved into place.

Eventually, we'll have it working and need a design to visualise how it would all work from a user's standpoint. This ticket is to explore that.

Some errors are things that probably don't need further explanation (we turn the server off after 5 minutes of inactivity, you don't have permission, etc.). But lots of things could leave the user feeling a little helpless (e.g. "Something went wrong"). Especially in those open-ended cases, it would be nice to provide the user with an option other than "try again and 🤞 ". Probably some links to discord would be a good starting point, but there could be other stuff too! (I don't know if the design-discussion tag fits here but it seemed right, feel free to retag)!

Auto-generated from product office hours chat

1. Go to library
2. Go to team settings
3. Change someone from developer to user
4. Notice the dialog disappears immediately even if you're not done editing yet. That's because it's a menu but it should be a popover component.

Updated ticket description from Jon (May 17, 2022)
Our current share dialog has some issues that I'll describe in more detail later. Here's a Loom getting people up to speed on the history and what the design proposal is moving forward.

Original ticket from Ryan:
There be dragons in this dialog! Changing the value in "Privacy Settings" moves the recording to a new team or makes it public/private.

See also
Feedback from Ollie in this other ticket

i think we can just do user-select: none

Background

Focus Mode is missing some important stuff. Here's a loom proposing some good improvements.

Figma link
Discord thread

Details

• We have a new precision editor in the bottom-right corner
• We default the timeline to a smaller window, rather than requiring it
• We have save, cancel, and discard now
• It's possible to drag the window right and left by clicking in the middle of it
• At first the window follows your cursor, then when you click you can drag the gripper edges as before

“Please open a new tab and press the blue record button to record a Replay” is not what I should see after making a new team.

Ways you should be able to delete

1. from the replay
2. from the library
3. bulk delete in the library

We should have a NextJS site for displaying documentation about guides, components, theming, figma, etc. I'll be porting over my work from this case study to start and we can eventually move to the official DocGraph library once it's published.

• A background colour for each image, perhaps?
• Do we want a border? How do we handle a white background without a border?

• "Ready when you are screen"
• Our loading screen
• Onboarding doesn't yet have dark theme colouring

Travis is starting soon and there are things we can do to make that transition better

It's been a while, we should see how this experience feels. I should also document the steps so other people can easily do it.

The problem we're trying to solve

Focus Mode should be contextual. You should be able to be in a situation, right click on something, and automatically narrow the focus to that point. This is going to be a great feature.

Things we know

• It'll be a standard right-click iteraction
• It'll be used in multiple places
• It'll be rad

The best way forward

1. On the design side, I'm not sure exactly where we want to use this. I'll need help from the team defining entry points, so let's discuss that in the comments below.

2. Once we have the entry points figured out, I'll need help figuring out what options we want to see in the menu. "Focus here"? "Start point here" and "End point here?" We'll want to discuss as a group. I will bias towards fewer options, rather than a menu with too many options at first, but we'll see.

We need to add a skip button and make sure the flow is good.

We've had a lot of ideas around comments over time. Here are a few items to consider:

• What things aren't possible to add comments to? Should we add them?
• What if comments were a big text area, like a collaborative document?
• How can we add more data to comments?
• Can we be inspired by LookSee? (#2)

From this ticket

We already have this:

But it might be nice to do the same thing here, when someone tries to open a file:

Jon to design a way to make this work well with our system.

Inspired by this bug:
https://github.com/RecordReplay/customer-support/issues/74

Every failure in Replay should message itself appropriately (and if possible, it should automatically retry without requiring user intervention).

Users shouldn't ever be left staring at a broken Replay without some idea of what happened.

We'll be putting this in several places in the app:

• Network Monitor (a few different panes)
• Comment pane
• Print statement
• Maybe others, stand by

We need to consider some other stuff, like:

• How should it look when it's disabled?
• Jason had an idea to remove the button entirely from print statements if not paused
• We're also thinking about more contextual stuff, how does this play with that?

Auto-generated from product office hours chat