Replay 4000

[corywatilo]

As a follow-up to #24561, I've created a series of wireframes that brings some UX improvements to replay, borrowing some of the concepts originally proposed under the PostHog 3000 moniker, including an improved filtering experience.

so tl;dr: yo, new replay layout ideas!

It includes some global concepts, but designed in the replay UI since it's one of the more visually complex products. In other words, if it works here, it should work across other products, too.

Some of the highlights:

1. Collapsible panels/resizable layout with saved workspaces
2. Contextual settings (within panels)
3. Better playlist saving/recalling
4. More native responsiveness
5. Improved filtering UI

Default view

By default, you'd have some list of recordings that load. Undecided if we should keep it as most recent (assuming we solve the issue of loading incomplete replays) or something like recordings you should watch for some reason we've identified. (Or it could also load the thing you last set of filters you had open.)

The filters pane would be able to grow in height, but would probably have a max-height set on it so the list of recordings don't start too far down the page or outside the viewport.

It's not ideal for the player and activity timeline to stack, but this is intentionally designed as a less-than-ideal scenario (a more narrow viewport, and nav with labels which is something I'd like to improve upon soon).

Also note that Waterfall is included as a panel now, vs being an either/or situation. If you consistently want to look at waterfalls, just collapse the panels above and it will live above the fold.

Collapsible panels

Borrowed stolen from Adobe's UI is the concept of collapsible panels that, would free up space when all components in a column are collapsed.

Here's an example where I've closed the filters and results pane, thus making it possible for the main column to reflow in a way that allows the player and timeline to live side-by-side. (Also notice how the recording section's layout changes when given more space. I designed this all with the idea of taking a ton of advantage of CSS container queries, which is especially fun/easy to implement in Tailwind.)

We should also be aware of the aspect ratio of replays, too. So if a recording is significantly landscape-oriented (likely by looking at the aspect ratio), we should try to intelligently configure the layout so the viewer doesn't load in a tiny window on the page.

(How do we decide which layout to load? Likely based on the first recording, though it could potentially be configurable to shift automatically depending on the recording.)

Full screen viewport mode

@daibhin mentioned he likes how Grafana allows you to place your mouse over a graph and use a keyboard shortcut to expand the graph so it takes over the full viewport - almost like a modal, but quicker/easier to toggle, and significantly better than flipping to full screen mode (on a Mac) which always annoyingly takes a couple seconds because it has to enter its own "Space".

Similarly, we could activate this mode with this button for a more focused view.

Panel interactions

One of the global patterns I'd like to implement across PostHog is the concept of panels that have options and settings directly accessible from within them. This was inspired by VS Code's Status Bar that contains a smorgasbord of settings:

Having something like this makes the interface feel very powerful and developer-friendly. But here we scope settings to the specific panel where they're relevant.

Preview panel

Let's explore the bottom row in the preview panel.

• Some settings can be toggled on/off, and are indicated by regular text or bolded, colored text
• Some settings can open menus to display multiple options

In replay specifically, I added a few fun options to improve the experience:

• Playback duration in speed selector. There have been times where I speed up a recording and suddenly it's over and I'm on to the next one. Showing the updated duration based on speed would clear this up.
• Show/hide device/viewport. Why not give an option to show the literal device and browser, giving a more realistic view of how the user experienced the session? On a desktop viewport, we can wrap the recording in a simplified mockup of the user's browser.
• Show on timeline. Lets you specify which types of events you'd like to see on the timeline, so you can quickly identify key moments.
• Overlay when scrolling. When scrolling to where the preview pane is no longer in view, the preview can pop over on top of the rest of the content on the page, similar to YouTube.
• Inspect (which lets you interact with the DOM)

One other thing: I think we should either toggle mouse tail OFF by default, otherwise (and/or) redesign it. Maybe we can do a gradient (from black @ 100% to black at 0% so it actually looks like it trails off). As is, it just looks very stock rrweb and cheap.

Here's an example with two settings changes:

• Device ON OFF
• Sizing option: Shrink to fit Scale to fill, which offers a larger view of the preview with a scrollbar:

Results panel

In the case where there are more settings than can be displayed, we can truncate them and move the extra items to a hamburger menu:

In the results pane, specifically, the options shown here are:

• Visitor summary. This shows the display option to generate a "smart name" for anonymous users where we'd typically show the distinct ID, if no other specified display names have values.
• Relative. Toggles the timestamp between relative, local time, and anything else (like UTC).
• Autoplay. I debated whether this should live in the player or here, but opted for here since it's intrinsically linked to the "playlist".

Saving & sharing

These options live in the recording overview panel. I've combined the saving to playlists/notebooks in a single place.

Also: I think we could consider renaming Playlists to Folders. For some reason it's hard for me to wrap my head around the concept of adding a recording to a playlist. (Playlist is something recreational, whereas a folder is a place where important things can be stored. Small change, but I think it just simplifies terminology.)

Layout settings

Another concept to steal from Adobe Creative Suite is the notion of layouts.

Watching a recording in a support context can benefit from a different layout than observing a playlist for a feature flag or rageclicks.

I imagine we'll want to be able to offer different layouts to solve different problems, and to allow users to configure and save their own.

Bonus: Query params (to set layouts) could be interesting. If I'm clicking a link to watch a recording from my support tool, if those links have a param like ?layout=support, it could open to a dedicated view for that use case.

Filter experience

But the biggest improvement (as originally outlined in the original PostHog 3000 proposal) is the filtering experience, with two main improvements:

• More condensed way of seeing applied filters
• Unified pane for applying a filter, with contextual menus based on the selected filter

Here's the default filters we currently apply for replay:

@raquelmsmith had asked me to consider the What to watch options in this UI redesign, and I've added them here under this Open menu, which would support applying saved filters and opening playlists.

Saved filters vs. playlists

I propose we introduce the concept of saved filters, which differ from what I think playlists should be:

• Saved filters apply a set of filters that update the results automatically
• Playlists save the current, static list of recordings where the results don't automatically update based on new recordings coming in
  • I had also considered only having playlists but adding an option for "Static" vs "Dynamic" lists, but I think this is better as saved filters is a pattern we can use across the app.

Presets

(The name could use work – I don't really like "Template" either – but) the idea here is you can quickly apply a set of filters that we've created to solve popular use cases.

It's essentially saved filters under a different name. But I chose to keep them separate so they're more visible in the UI and not buried under a submenu.

Selecting a preset applies the template of saved filters where you can fill in the blanks with the required fields.

Here it added:

• Select feature event which is basically a custom label on an event input
• URL contains

In both cases it uses the contextual unified filter pane which lets us apply a filter entirely with keyboard navigation. (Type, tab, type, tab, Cmd + Enter etc.)

Timeline

Here's what the event/console/network/doctor timeline could look like:

There are a bunch of improvements to cover here.

• Event grouping by window. On the left side you can visually see which events happened in which window.
• Verical seek bar/play head. The idea is the dot will travel down the page, in sequence with the player's seek bar. You should also be able to click any point in the vertical timeline to jump to that spot in the player.
  • Related: I think we should consider changing the primary action on clicking an event/line item to navigating to that part in the replay. I know @pauldambra's use case is the opposite (where he wants to expand the line item by default), but let's let the people decide!
• Inactivity periods. There are times where users are consuming (reading) a page and don't trigger any events, and the only other thing that happens in between is mouse movement. I calculated these periods of inactivity by looking at the inactive periods PLUS the active time between events. In these particular wires, it tells me the user was likely actively reading the page, not just looking away from their phone.
• Autocapture definition. You'll see on undefined autocapture events (here, the clicks on photos) that there's a Label this event link – a great spot to encourage users to define actions.
• Image thumbnails. As the creator of the site I'm using in the wires (real data!), it's actually super valuable to see a thumbnail of the image the user clicked. It helps tell the story of what they were doing, without having to actually watch the replay (because I know which images appear where).
• More things below...

Filtering within a panel

There are a few ways we can do filtering options to limit information shown in the feed.

Inline toggle options

Here we have the four inline filters we can toggle on/off. (This is the same as the full wire above.)

I think in this case, it's okay to leave them in the top bar. But there may be other cases where they should be handled differently. Here are a couple of alternate options:

Menu

Same pattern we already have in other places.

Inline options

Chrome Inspector has a pattern for toggling on a pane that appears inside.

We could do the same here.

Any way we do it, I strongly feel we should default only events and console to ON.

• Seeing network requests gets very overwhelming
• Console feels useful enough because looking at this level of details usually means you want to know about errors

Regardless, it should remember your filter settings and load them up next time (unless you reset your workspace).

Line item details

I've also made a few improvements for looking at the details of an event.

• Label event callout.
• Tabs for properties, DOM, JSON. I've had many times where I want to explore the thing that was clicked, but that information isn't available here. Adding DOM and JSON tabs (which are accessible from the Person view) are handy here. There's also a link to jump to the actual event.
• Filter/sorting/search/expand. All the handy things you'd expect to have in a developer console. The expand option might give you an overlay – or just a larger pane to see the details, as sometimes it feels claustrophobic to try to consume detailed information here.
• Hovering/clicking an image preview shows me some high-level details of the image.

But by far the biggest win (vs today) is removing the padding, borders, and space between line items.

---

And that's a wrap! Until tomorrow...

[ioannisj]

Don't know if these should go here, but we could also inspire from YouTube to enrich our track bar. These could work well especially for longer recordings.

Chapter for each page /screen

Show a histogram that highlights areas of low/high activity