Toward a mobile-first perspective on Stash, starting with markers

[speckofthecosmos]

Stash has been built desktop-first and made responsive enough to work on mobile. Significant work has gone into that responsive layer over the years — credit where due. But the UI's mental model is still desktop: hover states, dense grids, multi-column layouts, keyboard modifiers, AB-loop for range selection. Mobile gets a working version of the desktop paradigm; it doesn't get its own.

I'd like to open a conversation about shifting that on specific surfaces where the desktop paradigm fits worst. Small, incremental moves; each one stands on its own merits; nothing forecloses the desktop experience.

The surface I'm starting with is markers.

Why markers first:

• Markers are inherently short-form content. A marker preview wall behaves like a consumption feed — one video at a time, autoplaying, scroll to the next. That's the pattern mobile apps are built around (Shorts, TikTok, Reels). The desktop grid doesn't serve this pattern well, and mobile-native interactions (vertical scroll, visibility-based autoplay) serve it much better.
• Users are already consuming markers this way ([Feature] Add ability to define Clips/Sub-Scenes from Scenes #4594, Include short "Scenes" (pre-clipped files) in the Marker browser by tag #3917, Marker Preview Generation Options #5783, Ability to create a playlist from multiple markers #2647 describe variations; my own earlier comments on [Feature] Add ability to define Clips/Sub-Scenes from Scenes #4594 walk through one workflow). The app is being stretched toward a shape it wasn't designed for; bringing it a little closer to that shape is a positive-sum move.
• The individual changes needed are narrow. Raising a preview cap, adding visibility-based playback to a wall view — these aren't architectural shifts. They're targeted fixes that happen to unlock a mobile consumption pattern as a side effect.

Two concrete starting moves:

1. Make maxMarkerPreviewDuration configurable. Current behavior silently truncates marker previews longer than 20s, which breaks any consumption pattern where the marker is the clip rather than a teaser for the scene. Making the cap configurable unlocks the pattern without a schema change or any forced behavior change for users who want bookmark-style short markers. Filing as its own issue; will link here.

2. Enhance mobileWallLayout (the CommunityScripts plugin I maintain) with IntersectionObserver-based play/pause so the scroll wall doesn't try to autoplay every video simultaneously, and rebrand the display name to scrollFeed so users find it when looking for feed-style consumption UX. PR open at [mobileWallLayout] Add play-on-visibility and ordered loading CommunityScripts#704.

Those two together cover ~95% of the "markers as clips on mobile" use case I originally described in #4594 — without needing the schema-level discriminator I initially proposed there. (I'm course-correcting on that thread separately.)

I'm bringing this up here because the preview-cap change on its own reads as a small bug fix. It is — but it's also the first move in a direction I'd like to keep making. I'd rather start that conversation now than have subsequent mobile-focused PRs feel like they arrived without context.

What I'd value from the community:

• Mobile frictions worth naming. If you use Stash on mobile and there's a specific moment that feels wrong, drop it in. Even without a solution, knowing where the friction lives informs where the next small move lands.
• Perspective on the direction. Is mobile-first (on specific surfaces) something the Stash community wants? Is there a reason to keep it explicitly not?
• Anyone else interested in contributing mobile-first work, so it doesn't all have to come from me.

No timeline pressure. The preview-cap fix and mobileWallLayout plugin enhancements will move on their own issues regardless of how this Discussion evolves.

[speckofthecosmos]

Adjacent thought. Once marker durations are meaningful (post cap-fix), sort-by-duration on the marker wall starts making sense. Probably its own PR. Main open question: how should markers without explicit end times sort? Treat as the default 20s? Sort to end as 'unknown'?

[speckofthecosmos]

Patch build for #6855 is live at https://github.com/speckofthecosmos/stash-marker-cap-patch for anyone who wants to try the cap fix before it merges. Multi-arch images on ghcr, rebuilt nightly against develop. Running it on my NAS now.