stashapp / stash

An organizer for your porn, written in Go. Documentation: https://docs.stashapp.cc
https://stashapp.cc/
GNU Affero General Public License v3.0
8.79k stars 778 forks source link

[RFC] Refactor main navbar #1297

Closed WithoutPants closed 3 years ago

WithoutPants commented 3 years ago

This is the current navbar.

image

This is as narrow as I can get the Window before it has to collapse to a menu button. With Audio and Text items in the roadmap, plus Playlists and such, we're going to run out of room in the navbar. We need to think about reworking it.

Some design considerations:

Possible designs:

This would mean a loss of vertical real estate which I'm loathe to lose.

Said sidebar is collapsible to it's icons, with the More > button only accessible when not collapsed. On most widescreens, we'd probably be losing less proportional real estate horizontally than vertically, and definitely less when collapsed. It would mean that some of our screens would need to be redesigned (the scene detail page for example).

WithoutPants commented 3 years ago

Belley has suggested an extension of the group - the groups, items and order should all be user configurable - meaning one could group some things and not others. We would provide a default grouping, but the user could completely customise it.

WithoutPants commented 3 years ago

Other suggestion, having like 2 navbar that can be switch in the bar with a button like :arrows_counterclockwise:

  • 1 will be the default, with video, image, metadata group.
  • 2 will be a favorite bar or quick access, it will only have button that you set in the interface settings, so i can choose Scene, Tags then only these button will appear in this bar. Of course the bar (and button to switch) will don't appear if the user never set his favorite "section" in the interface settings. Maybe having the choice to choose which navbar you want as default. (So you don't need to click on switch button everytime)
CosimoVestri commented 3 years ago

As to the sidebar idea:

It would mean that some of our screens would need to be redesigned (the scene detail page for example).

Why?

I hope you don't mind some input.

WithoutPants commented 3 years ago

At the very least, we'd need to adjust the proportions of the sections of the screen. I suspect that with a full menu sidebar, the left scene details sidebar won't look very good next to it.

CosimoVestri commented 3 years ago

If the sidebar is collapsible to icons and is collapsed by default, it wouldn't be too bad. Extended, however, it almost certainly would be an eyesore.

Clarification: Eyesore is poor word choice. What I mean is that it would encroach on the content to the right, assuming the entire page slides right with the extension. Another option would be to have the sidebar in it's extended form above the content.

CosimoVestri commented 3 years ago

As to the switchable navbar:

  1. Any prior art/proof-of-concept? Nothing similar springs to my mind.
  2. What would that look like in the mobile view? How would that translate to a mobile interface?

As to the configurable groups, images, order:

  1. Customization, especially of order is very nice. That does seem to add a touch of complexity, though.
  2. If groupings or custom groupings (I am imagining drop down menus, correct me if I'm wrong), what would that look like in the mobile view? Drop down menus are generally frustrating in a mobile view (three actions/clicks/touches to reach an item).
WithoutPants commented 3 years ago

Another consideration: the duplicate checker and filename parser should be accessible and grouped under the Scenes item.

If groupings or custom groupings (I am imagining drop down menus, correct me if I'm wrong), what would that look like in the mobile view? Drop down menus are generally frustrating in a mobile view (three actions/clicks/touches to reach an item).

I would have them in a collapsible (under) group that would be open by default.

Anon247 commented 3 years ago

This might be a nice starting point for a simple but effective sidenav implementation. Shouldn't be too difficult to add an option to collapse the navbar when on desktop. I do believe a sidenav would offer the best simplicity and flexibility for effective navigation and customization across all screen sizes.

CosimoVestri commented 3 years ago

I would have them in a collapsible (under) group that would be open by default.

Oh, okay.

Another consideration: the duplicate checker and filename parser should be accessible and grouped under the Scenes item.

While great to have accessible, how prominent do these need to be? Since they aren't going to be used all the time, would they be somewhere like this:

Screenshot 2021-04-13 182141_LI

WithoutPants commented 3 years ago

While great to have accessible, how prominent do these need to be? Since they aren't going to be used all the time, would they be somewhere like this:

This is a good point. Perhaps somewhere on the scenes page is more appropriate. The current home for Filename parser and Duplicate Checker (settings) isn't the ideal place.

CosimoVestri commented 3 years ago

I do believe a sidenav would offer the best simplicity and flexibility for effective navigation and customization across all screen sizes.

They are easy to implement. As far as sizing goes, one option would be to use media queries to determine if A.) the viewport is wide enough for the extended menu expands to the right (pushing the rest of the page content to coexist) or B.) the viewport is sufficiently narrow that the extended menu should be drawn atop the rest of the page.

WithoutPants commented 3 years ago

Some prototype screenshots. Here is a collapsed sidebar, shown with the scene details page: image

And expanded: image

It's hard to show with these screenshots, but it really feels like it's encroaching on screen space when expanded.

WithoutPants commented 3 years ago

Top navbar with line breaks below the icons (with an increase in the icon size, which doesn't impact the vertical footprint):

image

It saves some horizontal space, and doesn't impact very negatively on the overall UI. This might work well in combination with the other navbar ideas.

QxxxGit commented 3 years ago

Personally I'd separate desktop and mobile navigations. It's more work but that's the nature of front end unfortunately.

For desktop I'd keep it simple. Top nav bar with some items being hoverable:

This solves the additional clicks concern by making it hoverable and itll free up space.

Mobile navigation should probably go with the sidebar. Pressing the menu icon expands the sidebar which overlays the content on the page. The sidebar can list the navigation items as they exist now as there is more vertical real estate to work with.

ghost commented 3 years ago

For mobile I think we should consider a bottom navbar. This is significantly easier to use one-handed compared to sidebars and top bars. Both Youtube and Spotify use variations of this:

image image

Space is of course limited in any horizontal menu, so I would stick with the most used pages like scenes, performers, search. The rest can go in a toggleable sidebar.

I also think we need a dedicated search page accessible from the nav that will search all entities. Then we could have a Netflix-style 2d result list with entities listed vertically, with horizontal swipe for the results of that entity.

echo6ix commented 3 years ago

Hello, broken record here. I suggest emulating the porn tube sites instead of reinventing the wheel. If we're to group items like a tube site in the desktop navbar I think it would look like this:

Imo I think you should keep this on a top navbar as it is now, though I'm not sure it is necessary to keep it fixed. I would avoid using a navigation sidebar. I think search, saved queries, and other shortcuts should be reserved for the sidebar. Xhamster, ebay, and Amazon have good implementations of search oriented sidebars that let you refine your queries in the sidebar (and a place to show future relevant content)

Sources of inspiration Pornhub, Xhamster, https://babesource.com/ , Amazon, eBay

venturevoom commented 3 years ago

Thanks for giving this a revamp. Since Monitor Real Estate can be quite valuable, i would prefer a collapsable/expandable menu on the left, since most monitors are widescreens.

But i would get rid of the top bar to salvage some extra pixels. image

CosimoVestri commented 3 years ago

@InfiniteTF Bottom bars do look nice on a phone, a little less so on tablets and desktops. Since there's already a hamburger menu for mobile devices that might be superfluous. I do like them, though. A lot of apps with those bottom bars have some secondary menu area.

@echo6ix One's still limited by available real estate. I'm not sure tags and studios are sufficiently similar to group together. And what about possible addition of text and audio content or some other future media type? More space utilized then as well, so one is stuck with the same problem. Search refinement sidebars are common and useful, but that still leaves one to have a completely different approach for smaller screen sizes. Though, I can't think of many control schemes where that wouldn't already be the case.

@venturevoom That horizontal portion might just be in the proof of concept/mock-up, to be excluded in the implementation.

@WithoutPants the encroachment by the sidebar is significant. One alternative is to have the sidebar always collapsed and expand over content on hover. Using the horizontal hamburger approach on mobile still makes sense in this scenario.

echo6ix commented 3 years ago

@CosimoVestri There are currently 9 primary menu items. My example reduced them to 6 in a PornHub style navbar. Studios could have it's own primary menu if it doesn't fit elsewhere, and that would bump the primary menu items to only 7.

Also if you remove the icons that accompany the text menu items there would be room for up to 10 primary items at least (not that 10 is needed), but it would reduce the look of clutter. I get that icons "look cool", but they're redundant and unnecessary when the text menu item is already present.

And what about possible addition of text and audio content or some other future media type?

Per my example, text would go into the ... primary menu item, and audio could also because they're niche items among the community. I've been following Stash since it started and can count on two hands how many times either has been requested (one of those times being myself); they're not even among the top +1'ed items here on GH. The ... primary menu item would be a suitable catch-all menu item for future expansion of items that don't fit into any other primary menu category.

Search refinement sidebars are common and useful, but that still leaves one to have a completely different approach for smaller screen sizes.

I think this is pretty simple. Inspiration can be taken from eBay's excellent ui/ux design here. On small view ports the search navbar can change into a search icon on the top right navbar -- when clicked it has the same UIUX functionality of a hamburger menu with more than enough real estate to filter queries and more. Heck a search sidebar could even have the option of being pinned and unpinned on larger desktop viewports like was done on PV.

Just a random thought. I get that Plex looks cool and all but imo it's using UIUX concepts that better suit TV size viewports. If that's really important to the community there should be an issue request to support large viewports or to have a "big picture mode" like Steam.

echo6ix commented 3 years ago

Also here's another suggestion to the PornHub style navbar I proposed.

we need to maintain single-click navigation for at least the most used buttons. I know that I will be bothered if I suddenly need to do two clicks to go to Scenes, Performers and Studios.

In my example, the primary drop menu items are:

Let the user define in the settings where the default single click of Videos and Images will navigate to. If someone exclusively uses Markers more than Scenes, they can define the url of Videos to navigate to Markers.

spincity07 commented 3 years ago

My vote is to keep the nav at the top. Every video site i can think of, xxx or otherwise, has only a top nav visible by default on the video page. This is so the video can have maximum width and no side distractions. Any side nav on the video page is usually just a slide out via a hamburger, or below the video line.

GloveNinja217 commented 3 years ago

I figured I'd add something here that is somewhat related, but can we get an option to set the homepage when we open Stash to something other than the overview/stats page? Like to have it default to scenes, or galleries?

CosimoVestri commented 3 years ago

@echo6ix You make some good points.

I get that icons "look cool", but they're redundant and unnecessary when the text menu item is already present.

On this, I completely disagree. I can produce many journal articles on the importance of using symbols to communicate. (Here's a non-academic article: https://www.nngroup.com/articles/icon-usability/). Crucially, they provide larger touch-targets and ease in conveying ideas with respect to language localization.

Generally speaking: Using only an icon is less effective. Using only text is acceptable. Using both is most effective.

Per my example, text would go into the ... primary menu item, and audio could also because they're niche items among the community. . . . The ... primary menu item would be a suitable catch-all menu item for future expansion of items that don't fit into any other primary menu category.

Which brings us to @WithoutPants mentioning customizability. Some users only use certain media types and would desire their preference to be available on the top-most menu category.

As to Plex: I'm not going to say that's the model to follow. But it is designed for consistency and usability on multiple viewport sizes. It isn't the absolute best choice for any particular of them, but it is workable for a lot of them. Jellyfin does something similar. The Windows 10 start menu does something similar. Requiring multiple unique interface schemes often requires modifying each of them every time a new functionality is implemented.

(Upon re-reading this comment before posting, I feel I need to say that my intent is not to antagonize you, @echo6ix. Forgive me, if you would.)

echo6ix commented 3 years ago

@CosimoVestri I skimmed through the link provided. I think my point was misunderstood or communicated ineffectively. I acknowledge the utility of icons in a UI. I also think good design uses them sparingly where necessary to avoid clutter -- in our use-case of a website top nav bar where we are paring down the menu to only 6 items I find them redundant, causing visual clutter (I would change the Stash text label item to the Stash logo btw lul) -- even the cited link doesn't use icons along side the text labels in their top nav bar.

But that's just my opinion as a nobody, I'm not a designer or anything. The likelihood of the icons being removed is probably null anyway.

(Upon re-reading this comment before posting, I feel I need to say that my intent is not to antagonize you, @echo6ix. Forgive me, if you would.)

No worries I didn't take it as such.

echo6ix commented 3 years ago

Ok guys, imo here's more reason to use a PornHub style top navbar with dropdown submenus: I think the layout is more conducive to incorporating future ideas/concepts/additions.

I've already alluded to this in my first post, but it's become very apparent to me now that I've been downloading a lot of short clips lately (and it's painfully obvious that we need that #671 quick filter shortcut feature enhancement) that the dropdown submenu on a top nav bar would be the best placement for quick filters such as 'Clips' or whatever other quick filters people want quick access too.

jeremymeyers commented 3 years ago

Seems like it might be valuable to separate this out into a few challenges

My UX brain suggests that this might be a good time to do some user testing/surveys.

In any case (and kind of as @WithoutPants said, There are several types of areas being served by the main nav:

and then (if I'm reading correctly)

METADATA (content describing the above content). This is putting aside the part where you can view associated content per metadata)

My solution would be several fold

1) Instead of a "hide/show" functionality in the config for the sections, switch over to a "show by default/show in overflow" model

2) Add "breadcrumbs" functionality

3) Go to a two-row top nav. This would allow for additional space to put functionality that exists on every page (e.g. the search/filter area, which also needs a refactor) as well as more space Top row (major navigational changes): config, donate, "shown" section with either horizontal expander on click (a >>) or a "more..." dropdown, "Random" button (or "Discover" button once that part is built). Second Row (content more specific to your current location: breadcrumb ("Home > Scenes > {scenetitle}" or "Home > Tags > {tagtitle}, etc), Search/filter group.

I'm not 100% sure of the designations but I think this would be a good start.

jeremymeyers commented 3 years ago

Also possibly an opportunity to add filtering by alphabet #1129

CosimoVestri commented 3 years ago

So @jeremymeyers, I've got some thoughts inspired by your comment.

1.

Also possibly an opportunity to add filtering by alphabet #1129

This seems great.

2.

As to your breakdown of items, if Markers is METADATA, then I'd say Movies is also such. Movies items are not themselves content items. They merely link to Scenes which are content items.

However, considering how both are oftentimes used*, I would say that both of these belong together with Videos as a category.

3.

Add "breadcrumbs" functionality

I like this. It reminds you of where you are in context perhaps a bit better than simply a heading. Some might find it superfluous; however, I like it.

4.

This would allow for additional space to put functionality that exists on every page (e.g. the search/filter area, which also needs a refactor) as well as more space

The search/filter area doesn't appear on content item pages. This breaking it away from the "page navigation" structure does make sense.

5.

As to Desktop vs Mobile, responsive design is generally the way to go rather than completely separate interfaces. If it's broken down into two separate interfaces, then there needs to be an explicit switch to a mobile interface. This also means that there would be an increase in development workload. Both interfaces would require reciprocal modification every time functionality is added or changed.

Implementation of responsive designs often requires some sort of "mobile first" design thinking.

6.

As to terminology, I'd say "Metadata" is fairly accurate; however, it is not layman friendly. An alternative should be developed that makes more sense to non-technical users, should they exist.


* I imagine that both are ways of finding content items. One goes to a Movie page to find a Scene content item. One goes to the Markers page to find specific content within a Scene content item. Hopefully my explanation of this makes sense; I'm not sure if I'm expressing myself clearly.

That is to say, there must be a designation that there is a difference, and preferably some way to choose between the two.

Stash is not exactly one of those solutions that is friendly to people who don't have some intermediate knowledge about computers. It probably never will be. It may not be worthwhile to consider this in design, but that's just speculation.