What do you think: could the expanded/collapsed state be saved? Now if I have specific tags and performers selected, open a scene and come back scenes list view, all the options are collapsed with no visual indication which of those have some options set.

Proficient Stash users can determine the options from the standard filtering options though.

New updates from yesterday:

• sidebar now sits overlapping the content pane on smaller viewports. Adds a close button on these viewports and will automatically close the sidebar when clicking outside the sidebar.
• selected items now always show under the heading, instead of being hidden behind the collapse.

What do you think: could the expanded/collapsed state be saved? Now if I have specific tags and performers selected, open a scene and come back scenes list view, all the options are collapsed with no visual indication which of those have some options set.

Saving sidebar state in the browser is at the top of my todo list.

Placement of sidebar toggle and sidebar specific buttons

@WithoutPants are you open to taking inspiration from ChatGPT's sidebar UI/UX? Specifically the placement of the toggle and other relevant primary buttons, which are placed at the top

• Toggle button is fixed (top right), regardless of sidebar being enabled or disabled
• Fixed toggle button allows for notification badge for sidebar specific items (as per animation). Stash may not have a use for that now, but the possibility is there for the future.
• Top of the sidebar (left justified) is a good potential placement for other fundamental buttons

What is the plan for this feature? Will it be merged to develop now that 0.28 has been released?

I'm already used to rely on this so I cannot imagine using Stash without it. Great work on this!

Thanks @bob123491234. These should all be addressed now.

I'm back to testing again now that my system is back online.

I noticed that the sidebar is also enabled on the secondary list page. Earlier conversations indicated that the secondary list pages would not use the sidebar. Has the stance on this changed? I don't think the sidebar works as well in that view. My eyes have a hard time focusing on the sidebar with the details header remaining in my line of sight. For it to work in this view, I think the details container needs to be scrolled out of view as soon as the sidebar is expanded. Also, the expand/collapse sidebar button is currently bugged in this view. The button's position shifts each time it is engaged.

The core of my issue here may be actually with the sidebar button remaining isolated at the top left of the sidebar. It feels even more off in this view, given the list is not at the top of the page. This may just be something I address locally.

the expand/collapse sidebar button is currently bugged in this view. The button's position shifts each time it is engaged.

The bug I mentioned in this view would still need to be addressed.

It's difficult to adequately address the above feedback, if I understand correctly, because it's based on a subjective impression, which is 100% valid for you, don't get me wrong.

But I think we can mitigate subjective back-and-forths by identifying the goals of the design. I don't know what those are, only WP does, but I suspect one of his goals might be to prioritize an intuitive beginner-friendly sidebar design? There are objectively good and bad ways to achieve that.

Like ChatGPT's UI and other web apps using this exact sidebar design, it addresses that goal by

• using a recognizable sidebar button label of a literal sidebar icon
• using a commonly expected, logical, and convenient location. Sidebar button near the sidebar, and it remains static there regardless of toggle state
• using a commonly expected behavior (toggle button open, toggle button close)

It's very boring, predictable, but modern. It's not reinventing the wheel, which are all good things for addressing that design goal

@echo6ix, the policing you are attempting to do here is unnecessary. The root of my earlier question was based on feedback we had received on previous revisions of this work. As far as I was aware, this sidebar work was only planned to be supported on the main list. Based on that feedback, the presence of the sidebar in the secondary list could have been considered a bug. The various issues I have seen with the side in this view would have supported the idea of this being a bug. In my second post, I concluded that its appearance in the secondary list may have been intentional due to my noticing that Bang also uses the sidebar in its secondary list. I assumed this because Bang has been stated as a source of inspiration here. With that being the case, I proceeded under the logic that the sidebar secondary list was likely intentional but pointed out that there are bugs in the view that would need to be addressed. The originally stated bug being the one I highlighted here:

the expand/collapse sidebar button is currently bugged in this view. The button's position shifts each time it is engaged.

That, however, is not the only issue. There are several other aesthetic issues that still need to be addressed, many of which can be seen in this screenshot:

With that aside, let's not pretend that the suggestion made here won't come down to subjective aesthetics. Your suggestion to have the sidebar button pinned to the top left was an aesthetic choice.

@echo6ix I should clarify that the reason your message irked me, yielding the response I gave, was because my message was not addressed to you. Yet, you stated your ignorance in understanding my message and proceeded to "address" it on WP's behalf to minimize the feedback you didn't understand. I should also be clear that I have never stated I disliked your sidebar button. The feedback I've given about the button placement never suggested removing or relocating it. The feedback has only been around relocating the elements around that button.

Apologies, my communication around this feature has been split between here and the dev-diary posts on Discourse.

In here, I discuss the goals for 0.29 and the sidebar stuff. In here, I talk about the sidebar stuff in the secondary views.

The summary is that yes, I'm looking at having the sidebar support on secondary pages. I intend the edit filter dialog to be reworked to be more of an advanced filter editor, with the sidebar being the place for more immediate (and simpler) filtering.

For most of the page layouts I don't see a huge issue having the sidebar. The exception will be the gallery page, which currently has a left docked pane. The short-term plan will be for this page to not have a sidebar, but I do think that the gallery page should be redesigned to be more like the performer detail page.

All that said, I think it might be worth holding back on the secondary page changes and address them separately in another PR. It's only going to further delay getting the broad strokes of the sidebar functionality merged, and it has its own design issues that will need to solved.

I appreciate the clarification. I've been out of touch with discourse these days. I agree the sidebar can work on the secondary list pages; we may just need to rethink some of the design choices that were made below the header area. I'll withhold remaining commentary on the secondary list pages until that work starts.

I hope you will forgive my broken promise to disengage with commentary on the secondary list. Some of the fixes here are so straightforward that pushing them out to a second PR and leaving users on the dev build to bear with the issues in the meantime doesn't feel right. I'll make this as painless as possible. I've provided a video that highlights some of the issues. I also provided the CSS to address the issues and another video showing the improvements. 20 seconds into the last video, I captured an issue that was not addressed in my CSS. That will likely require additional consideration that may be out of the scope of what you want to address here, so I've left it alone.

Before Video: https://discord.com/channels/559159668438728723/644934273459290145/1360401979611807929

The CSS:

.detail-body .sidebar {
   margin-top: -15px;
}

.detail-body nav {
    border-bottom: 1px solid #394b59;
}

.detail-body .tab-content {
    padding-bottom: 0;
}

After Video: https://discord.com/channels/559159668438728723/644934273459290145/1360402000772075650

These are only suggestions.

Here are a couple more things to be aware of:

The studio filters seem to be the multi-select filter that doesn't use the green plus on the left side. I've noticed this for a while but was never sure if this was intended:

Currently, the alignment of the toolbar is slightly off due to the sidebar button on the left side, which occupies 37 pixels of horizontal space. There are a few ways this can be fixed, but the simplest way may be to add 37 pixel (.375rem to be exact, this is the unit used on the button) right padding to filtered-list-toolbar:

I want to document a solution for the Include sub-studio content toggle button placement issue with the sidebar I mentioned 2 days ago. The suggestion is to move the toggle to the same line as the nav tabs for the sub menus. I think this placement makes more sense as it better illustrates the impact the toggle would have.

Here is the CSS used to put this together, although it probably shouldn't be implemented with just CSS.

#studio-tabs-tabpane-scenes {
    position: relative;
}

#studio-tabs-tabpane-scenes .item-list-header {
    position: absolute;
    right: 15px;
    top: -43px;
}

.detail-body nav {
    border-bottom: solid 1px #394b59;
}

I've been running this branch on my prod system for over a week now with some of the UI corrections I mentioned in my most recent posts. I have to say that I've been very happy with this work and plan to hold on to it until it eventually makes its way into the development branch.

Credit where it's due; placing the filter button to the right of the search input was a good call. When I suggested moving it to the button below the other filters, I made that suggestion, thinking that the window the button opens would only house the remaining filters. Which I later discovered was not the case. Since the badge-pill this button uses tracks all active filters (including the ones directly in the sidebar), it does make sense to me for it to appear before all the filters.

I think the implementation of persisting the sidebar state and autofocusing the search input when the sidebar is open works well in addressing some of the concerns people have had about moving the search input. There is still the issue that users currently have no way of knowing when a search filter has been applied to their list if the sidebar is closed. This problem should probably be addressed at some point, likely by adding a filter tag for the searches.

I've been enjoying these changes now for a few weeks and there is no going back for me so I'll be waiting for this to be merged until switching back to develop branch. Can't wait to get these changes included as well: https://discourse.stashapp.cc/t/dev-diary-10-04-2025-making-sidebar-filtering-even-better/579

I intend to merge this branch in the near future. The broad strokes of this feature are stable enough, and I think I've addressed the issues reported. I intend to revisit the sidebar button as part of redesigning the filter toolbar, which is what I'll move onto next. I'll also look at adding the search term to the filter tags.

Minor visual bug

On focus filter button border is getting clipped.

I just noticed the feedback here was never addressed in the main repo. I really think it would be worth addressing this disjointness on the Studio page before release.

Current:

Expected: