Query page redesign

[WithoutPants]

With the sidebar PR now merged into develop, I’ve begun looking at the list toolbar.

When looking at the overall design of the query page, I’ve tried to identify the information and functions that should generally be accessible at all times on the query page. These are the things that users will likely want to do at any time, and should not require scrolling to access.

My proposed design draws a lot of inspiration from bang and Plex.

Here is a screenshot of the current prototype:

I believe the current filter should be readily visible and editable, so I placed the current filter in a sticky toolbar, with a button to show the edit filter dialog. This meant that I could remove the edit filter button from the sidebar, which simplified its design.

Toggling the visiblity of the sidebar is something that I think should be quick and easy to do, so I placed this in the right-most part of the toolbar. The New button does not belong in the top nav bar, so I elected to move it into this toolbar. I don’t think it’s a significantly high-use function, but it didn’t feel quite right putting it behind the overflow dropdown, or putting it outside the toolbar. The Play button returns - this seemed like a popular function, and other similar apps have the same function, so it makes sense to include it here.

I elected to go with minimal styled buttons, since I found regular buttons distracting.

This shows the top of the page, which includes the results summary, and access to the sort by, page size and display mode selectors. The zoom selector is accessible under the display mode selector.

This shows the top toolbar when scenes have been selected. The current filter information is replaced with information about the current selection, with quick access to select all/none, play, edit and delete functions.

Finally, what’s not shown in these shots is the pagination control, which I’ve stuck at the bottom of the screen. This means that paging is also available at all times, but at the bottom of the screen rather than the top and bottom of the page. It never really made logical sense to me to have the pagination at the top and bottom, but I also didn’t want to have to scroll a heap to access the pagination information. There’s not a heap of applicable prior art around this; many sites/apps use infinite scrolling rather than paging, and any that do are aimed more toward discovery and browsing, so page controls tend to be at the bottom of the page.

There will need to be some further decisions to be made about the styling on smaller viewports. We will need a button to close the sidebar on mobile viewports since the sidebar button won’t be visible while the sidebar is open. On smaller viewports where the sidebar needs to overlap the content, we might need to consider moving the sidebar to the right side on the screen so that it doesn’t overlap the filter/selection info on the left.

I’d love to get some feedback on this design so that I can proceed. Let me know what you think.

[feederbox826]

Looks great! My 2c for pagination:

I do use the top pagination bar quite a bit and I find it helpful when scrolling past large spans of media when combined with the “Scrape / Search All” queries but it’s a bit of an edge case. Having them at the top keeps it consistent, since the pagination buttons pop up if the page ends early

[CJ13]

I am overall very happy with this. The main thing that stood out to me before reading through the summary was that the play button initially appeared to be an arrow that users would use to scroll through the tag pills. This probably isn’t a big deal, as users like me would quickly learn what the button is. It might be worth styling the filter pill area somewhat if it overflows to make it clear where the area starts and ends.

I am very happy to see the “New” button on the nav bar being moved down. That was one of the first things I started experimenting with after running the sidebar branch.

I have always felt that pagination belongs at the bottom, even going so far as to hide the top pagination on my server; however, I understand that some users appreciate it at the top.

I’m looking forward to playing around with this later.

[QxxxGit]

Hit the wrong reply button lol

@WithoutPants

I believe the current filter should be readily visible and editable, so I placed the current filter in a sticky toolbar, with a button to show the edit filter dialog. This meant that I could remove the edit filter button from the sidebar, which simplified its design.

If this means the filter button that displays the edit filter dialog is always displayed, I’m all for it. Since I updated last night, I realized I prefer the sidebar closed and wanted a button to open the filter dialog without the extra click.

These changes are definitely looking good, especially the change with the “New” button. I’ll keep an eye out here for updates in case you need testing for further feedback. Great work WP

[WithoutPants]

Thanks for the feedback everyone.

I’m going to try to break this up into small PRs so that this work doesn’t balloon into one giant PR with various issues.

First up is the display mode selector.

For reference, this is what I had above. The display mode selector is on the bottom right of the image below:

There’s a couple of design decisions I need to examine and get feedback on. Sorry if it’s a bit stream-of-consciousness.

Here’s what I have right now:

And here it is when clicked:

The zoom slider only shows when Grid is selected.

Chevron

I can’t decide if the display mode selector button needs a chevron to indicate a dropdown list.

Here’s what I mean:

The chevron makes it clear that the button is a dropdown list, rather than some unidentified button. It does add a bit of width to the button though, and I liked how clean it looked in the original image. I note that plex has a chevron next to its display mode icon, so there is prior art there.

For the purposes of this PR, I’ll leave the chevron in for now, and we can always remove it if its deemed unnecessary.

Zoom slider

@WithoutPants

The zoom selector is accessible under the display mode selector.

I threw this out there quite casually, but it should be examined more carefully.

The zoom slider takes up a bit of real estate, and I personally find I don’t use it very often. It wasn’t a big deal to me to plonk it behind the display mode dropdown. However, I may not be in the majority, I could foresee this being a controversial decision. I note that Plex keeps the zoom slider visible at all times in the sticky toolbar.

There’s probably room for it next to the display mode button, I’m just leery of cluttering up the toolbar. I think if it does make it into the toolbar, I might restyle it to be a little more subtle.

Is this something that’s worth polling the community about?

Sticky toolbar

This is unrelated to the above PR. At the moment, only the first row of the toolbar is sticky at the top of the viewport. What are your thoughts on having the second row also always visible at the top?

It would allow quick access to sorting, page size and display mode. I think these functions are somewhat less frequent than those on the first row, but it might be frequent enough to outweigh the loss in content real estate.

[QxxxGit]

I tried thinking of how I would initially react to the lack of chevron, and I came to the conclusion it’s probably best to keep the chevron. Without it, to me, it comes across as a usual toggle between list mode and grid mode. With more options, it makes sense to have the chevron especially if you’re going to add the zoom slider in there.

Personally, I think the second row doesn’t need to be a sticky toolbar due to the less frequent use.

[CJ13]

Chevron

I think it would be best to keep the chevron. Users have been taught to look for dropdowns when they see the chevron. Throwing a curveball here would create unnecessary friction. Users always have the ability to hide the chevron via CSS if they can tolerate this twist for a cleaning look.

Zoom slider

I think the way you’ve integrated the zoom slider is well done and fits pretty well. When the grid view is selected, the slider is usable. When other views are selected, the slider will remain visible but be disabled and styled appropriately to indicate this. Looking at the screenshot you provided, it doesn’t take up much real estate at all.

Users with screens of varying pixel densities will find the slider useful for managing the scale without needing custom CSS for each device. I suppose it comes down to whether it’s worth disappointing those users to reduce the cost of maintaining that feature. From my perspective, I haven’t gotten the impression that maintaining that feature has been particularly expensive, especially with my perspective that you hit the nail on the head with the current design. I recall you got quite a bit of positive reactions to your post a year back during the earlier sidebar conversation where you first proposed that display menu design.

Sticky toolbar

I don’t think adding an additional sticky layer is a good idea. On the details pages, that would make a total of 4 rows that are always visible (nav bar, mini details header, 1st toolbar, 2nd toolbar), all eating away at screen real estate.

[smith113]

It’s a bit unfortunate that longer tag names get cut off; harder to pick the right tag (see screenshot). Would it be possible to make the sidebar resizable?

[CJ13]

The sidebar width should be adjustable using CSS. This Discourse topic probably isn’t the place to have this discussion though.

[smith113]

Well, I was hoping that it could made draggable to resize it, which is probably ontopic here?

[CJ13]

I’ve been under the impression that the goal of this topic was to seek feedback on the coming toolbar updates proposed in the original post. It seemed to me that feedback on the recently merged sidebar work might be better served in the Discord feedback channel. My concern was that your post might veer the conversation away from the toolbar feedback requested here.

Know I was not intending to take any shots at you here. I’m just trying to keep the load manageable as WP is back to doing development work.

[smith113]

I apologize, I misunderstood what this thread was seeking feedback on

[WithoutPants]

I haven’t been thrilled with the user experience with the scrollable filter tag list, particularly on desktop environments. I’m going to explore some other ideas.

I’m considering having a maximum of three criteria visible, with the rest behind an indicator showing x other criteria.

Here’s a rough idea:

I imagine mousing over the component would show the rest of the criteria in a tooltip.

On smaller viewports we’d probably elect to have the full list at the top of the page, rather than stickied.

Any thoughts?

[DogmaDragon]

@WithoutPants

I’m considering having a maximum of three criteria visible, with the rest behind an indicator showing x other criteria.

I think that’s a bad user experience. Being able to quicky modify the filters by just clicking on them is a huge quality of life. It directly opens that filter instead of needing to scroll through the list of all filters again. I understand it being used for overflow, but it should fit as many filters as viewport allows and only then the overflow hidden.

[CJ13]

I think the scrollable overflow would be good to have here. Perhaps your dissatisfaction was with the scrollable overflow implementation you were trying? The slick list I pulled in for the front page would be perfect for something like this. If you recall the discovery tab work I put up the PR for, it actually uses the slick list to handle the overflow for those pills, and I have been very satisfied with it.

Here is a screenshot:

Like on the front page, each press can reveal as many more pills as you want. There is also the option to make the list scrollable for supported devices.

[CJ13]

I don’t completely dislike your idea of using the popover to handle overflow, either. I imagine the pills would still be editable with a click from the popover menu. Scrollable pills for filters are just a popular solution I see being used in scenarios like this these days.

[WithoutPants]

Thanks for the feedback.

@DogmaDragon

Being able to quicky modify the filters by just clicking on them is a huge quality of life. It directly opens that filter instead of needing to scroll through the list of all filters again. I understand it being used for overflow, but it should fit as many filters as viewport allows and only then the overflow hidden.

The functional aspect definitely needs to be considered. I agree that what you describe is a regression on existing behaviour.

Here’s an example of a long query list without truncation as you describe:

Keep in mind that this is the sticky toolbar, so this is visible while scrolling as well. To me, it’s far too cluttered and presents too much information.

My counter-suggestion would to keep the full filter list at the top of the page. When the page is scrolled, it collapses into a truncated list in the sticky toolbar per my earlier idea. This means that there isn’t any regression on the existing behaviour.

And yeah, the intention was for tags in the overflow popover to be clickable to edit the extra criteria.

@CJ13

I think the scrollable overflow would be good to have here.

This is possible, but I’ve had a great deal of trouble trying to get the sizing correct when having the buttons on the right. I can’t get the flex box to grow to the maximum size and have the overflow work correctly. I need to set a manual maximum width. We can of course do this, but we’ll need different sizes for different view ports. We’d also need to settle on an appropriate maximum width.

I personally think its a better user experience to be able to expand all the other criteria at once rather than have to scroll through a list with a narrow viewport.

[PPP]

Would display: grid give you more options/control over flexbox?

[CJ13]

In a desktop environment, it would be rare for users to actually hit the overflow. When they do, it would be rarer that they need more than two pages worth of that width to house the remaining pill. It would typically just be one button press to view the rest of the pills.

Mobile devices are more likely to hit the overflow. However, for them, I’d argue a scrollable bar would be a better experience than the pop-over, which I feel was really designed for desktop usage.

I’m not sure the clutter argument is viable in this case. The user doesn’t meet this page to a bunch of pills by default. They specifically requested a verbose query, and as Dogma pointed out, they would value and expect to be able to easily and visibly keep track of their active filter. I also didn’t see anything visually unappealing about the image you mentioned felt fluttered. It didn’t appeal cluttered to me. It appeared neat and organized.

I know you cited Bang as an inspiration; note that they’ve implemented a scrollable bar. PornHub also uses a slick list styled scrollable bar as well. See image below:

If you have a branch available and are open to it, I can take a look and see if I can help with the issues you were having with the scroll implementation. At the very least, it would be good to make the filter list easily patchable so we can provide a slick list implementation.

[QxxxGit]

Definitely agree that the long list looks rough but I also agree with CJ that in most cases people aren’t going to use that many filters. I think having a mix of CJ’s scrollable bar proposal with your 3 criteria visible at one time will work fine. As long as these elements don’t exceed 1/3 of the toolbar on desktop it should look pretty clean like your original proposal with “+9 others” and “Clear”