[RFC] Refactor main navbar

[WithoutPants]

This is the current navbar.

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:

• 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.
• the navitems fit into categorical groups. Scenes, Markers and Movies would fall under a Video group, and Images and Galleries would fall under an Image group, and the rest could go under Metadata.
• saved queries are in the roadmap and should ideally be accessible from the navbar.
• we should consider that on desktops, there is a lot more horizontal real estate than there is vertical
• we should ensure consistency between desktop and mobile views

Possible designs:

• on desktops, group navitems into the groups mentioned above (Metadata probably wouldn't need to grouped). The groups would be implemented as a hover dropdown button. Pornhub does something like this, as does xhamster:
  
• we could potentially save some horizontal realestate by increasing the height of the navbar and placing the icons above the text, with a squarer button - like how Sonarr/Radarr do it:
  

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

• move the items into a clickable menu like how the mobile view is currently. I'd rather not do this since it adds an extra click to all those top-level objects.
• move the items into a sidebar. Plex has this, for example:
  

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).

• show only the first x items that will fit and put the rest into a More... menu button. Menu item configuration would then be order as well as inclusion.

[WithoutPants]

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]

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

• 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]

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]

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]

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]

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:

3. Customization, especially of order is very nice. That does seem to add a touch of complexity, though.
4. 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]

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]

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]

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:

[WithoutPants]

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]

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]

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

And expanded:

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

[WithoutPants]

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

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]

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:

• "Videos" is a dropdown for markers and movies. Clicking videos itself takes you to scenes.
• "Images" is a dropdown for galleries. Clicking images itself obviously takes you there.
• "Performers" is a dropdown for studios.
• Tags should be it's own button with no dropdown.

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]

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:

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.

[spincity07]

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]

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]

@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]

@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]

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]

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

• Overall: What does the top nav need to include, content-wise? What is "top-level"? What can be part of a submenu?
• Desktop vs Mobile: Differences in navigation (IMHO should be treated like an entirely different issue, taking cues from the desktop.
• Navigating around Stash generally: Does putting all the 'main sections' on a top nav best serve how people use the app?

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:

• Video Content: Scenes
• Video Content Container: Movies
• Image Content: Images
• Image Content Container: Galleries

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)

• Performers
• Tags
• Studios
• Markers (only relevant to Scenes)

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]

Also possibly an opportunity to add filtering by alphabet #1129

[CosimoVestri]

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.

[echo6ix]

Just expanding on my prior posts with some wireframes.

To summarize:

• It's not a radical change from the current paradigm. Main nav bar items can still be clicked. This concept would add a flyout on hover.
• Each main menu item and sub-menu items could be customized (added, removed, reordered) to accommodate everyone's preferences
  • Custom menu or sub-menu items can be renamed and can link to different pages or saved filters. For example, if someone wanted a Clips sub-menu item, they could add it with a URL pointing to a saved filter for their clips.
• The following wireframes would just be my personal preference of how I'd organize a stock layout to consolidate similar items together. Don't get hung up on order, placement, or categorization since the end-user could alter all of this. They could duplicate the existing main nav bar if they wanted using this paradigm (important for users that don't want the existing main menu interface to change).

Videos

• The complimentary filters section corresponds to its sub-menu item.
• When hovering over the Scenes sub-menu item, the right side of the flyout displays the saved filters associated with scenes.
• When hovering over the Movies sub-menu item, the right side of the flyout would display the saved filters associated with movies, etc

Images

Categories

... (catch-all menu item)

Performers

Settings > Interface > Main menu settings

• The default action signifies what happens when the main menu item is clicked. In the below example clicking Video main nav item would direct the users to /scenes.
• Sub-menu items can be edited using the vertical ellipses option (inside a modal window)
• The order column allows the user to manipulate the order of the menu items

Modal window when the vertical ellipses edit option is clicked

Notification icon

Top horizontal nav bar with notification icon and drop down flyout. This could be a good location to show a history of toast messages and the current status of any ongoing tasks. More details about this concept fleshed out here #2871

[DogmaDragon]

I quite like this. Most importantly it offers user flexibility, while still keeping it consistent with other navigation on Stash.

The only disadvantage is probably for mobile users, but that applies to all horizontal navigation.

But I would not add the filters as a complimentary sub-menu element. Few problems with it I can see:

• Not limiting filters visible would cover half or more of the screen for people that use more than 1 or 2 filters.
• Limiting filters to x visible results defeats the purpose of easy access and it's an integral part of finding what you need quickly.
• It's too slow. Having to hover on 2 different elements just to get to the filters is slower than the current popup system.

[echo6ix]

Fair points.

I should have explained my vision of the complimentary sub-menu element better. I didn't intend for it to be full-fledged UI for navigating the entirety of saved filters, but merely a glimpse at relational content. I also didn't intend for it to be exclusive to filters either, but I didn't want to go overboard with the concept on the first iteration. The inspiration for this is PornHubs main menu flyouts. You can see the different kind of at-a-glimpse ideas that could be done.

The only disadvantage is probably for mobile users,

Completely ripping off PornHub here because why reinvent the wheel. I think they did a good job addressing this. The main menu becomes a hamburger menu on mobile viewports opening a flyout sidebar that omits any content from the complimentary sub-menu element.

Limiting filters to x visible results defeats the purpose of easy access and it's an integral part of finding what you need quickly

If I understand correctly this could be addressed with an integrated scroll bar when there's overflow.

[DogmaDragon]

Yeah, I agree that for mobile vertical menu sidebar is the most optimal.

I'm still unsure about filters. If they are not replacing the current system, but just duplicating part of it wouldn't it be better to just make it more robust as its own element and not integrate it into navigation?

I personally don't like dropdown navigation, so I can't really offer any insight, but I think it's flexible enough to implement most of the suggestions offered here and still leave room to keep it simple.

[echo6ix]

I'm still unsure about filters. If they are not replacing the current system, but just duplicating part of it wouldn't it be better to just make it more robust as its own element and not integrate it into navigation?

I don't know the answer to that, but I knew not everyone would be fond of it.

In my settings concept, each sub-menu item has a corresponding complimentary item dropdown form. I wanted to imply that the user has options to display it or not for those who dislike that section. This could probably be done more explicitly with a toggle that disables it for the entire menu item.

Edit: Updated image. Added curly brace markup

[echo6ix]

Another aspect of the main nav bar is the right justified section housing the icons. We could clean up a lot of clutter by moving icons into an overflow menu, which is a common practice in many mainstream UIs.

We can even consider adding context dependent options into the overflow icon, such as the New button on performer/scene/tags/studio pages, as well as non-filter related toolbar options (Grid view, list view, tagger view).

Advantages

• Menu items, such as the New button don't have to be as condensed in the dropdown menu. We have the real estate to write New performer or New tag or New studio. Probably more user-friendly imo
• Reduces clutter, relocating items into a well-known logical location (people know to look into an overflow icon, hamburger icon, etc for options).

Mobile view

• These items would be relocated to the mobile hamburger menu in the above post and located in their respective cards.

[echo6ix]

Moving the search input form into the main nav bar

EDIT NOTE: This concept was created before the introduction of the new modal accordion filter. If I had to redesign the above I would remove the filter elements for a button that opens the filter modal.

• Compact/minimalist concept
  • Search form integrated into the main nav bar
  • Upon clicking the search icon the input form expands, and end-user can begin typing
  • Requires the same amount of clicks to use as current search form
• Tried-and-true search concept
  • Used on various mainstream sites including xHamster
  • xHamster and other sites also include the content type drop down selector (scenes, movies, tags, etc)
• Incumbent search area overflow icon relocated to the global contextual overflow icon on the top right
• Allows for searching without navigating to specific section by using the content type drop down selector
  • Default content type would change based on the section of Stash user is viewing
• Filter flyout is also included in this concept. I know @WithoutPants is considering refactoring the filter UI
  • This would basically be the incumbent filter functionality relocated to a different area
• On mobile viewports the search functionality would be moved to the prior post's hamburger fly-out menu

Overflow drop down menu

• Overflow items currently in filter area can be relocated here
• Usage of nested items to prevent potential overcrowding

[echo6ix]

Active tasks notification icon

Currently the Stash settings icon rotates during an active task. But in my concepts the settings icon is moved to a drop down flyout menu via the overflow icon. To visually indicate there are active tasks we can turn the notification icon into a spinner.

[echo6ix]

Mobile viewport

• Ubiquitous and intuitive mobile design
• Tried and tested based on PornHub's mobile hamburger menu

Bottom nav bar

• Hamburger menu
  • Contains all the elements from the main menu
• Notification icon
  • Same as desktop version
  • Bell icon becomes a spinner when a task is active
• Search icon
• Overflow menu
  • Same as desktop version

Main menu container (hamburger menu activated)

• X icon to close main menu
• Main menu components
  • Presented using accordion menu
    • Each main menu item is within a togglable (collapsible/expandable) container
    • Expanding one container, collapses all others
  • Main menu items containing no sub-items are not togglable, therefore no toggle icon
  • Sub-main menu complimentary items are NOT displayed in mobile view (because space limitations)

Default view - no main menu items are selected

Video main menu item selected

[echo6ix]

I think one of the strongest aspects of my navbar concept is the global overflow menu.
Advantages:

1. User-friendly. UI consistency. Similar to MacOS/Gnome's global main menu, the navbar global overflow menu is always in the same location. Only the contents of it change depending on context (location of Stash). The user knows they can always refer to the same location for items, rather than features being scattered in different locations on different pages.
2. Consolidation = less clutter. Consolidating all overflow menus and as many other items as we can into a global overflow menu reduces visual UI clutter. Less clutter = user-friendly. Items organized into one location = user friendly
3. Simple location to display keyboard shortcuts. Keyboard shortcuts are an obscure feature that I'm not sure many users are aware of. The overflow menu is an intuitive location to display keyboard shortcuts adjacent to their item descriptions. See more below.
4. Development friendly>. The dev(s) do not have to consider where they're going to add access to a secondary class clickable UI items. They can always be slotted into the global overflow menu.
5. 3rd-party plugins. This could potentially make the integration of third-party plugins into the UI easier/safer. We could denote a specific location in the UI where plugins are to be placed: Overflow menu > Plugins > ...

Navbar overflow menu on a scene page

Scenes overflow menu relocated to navbar global overflow menu

Here's an example of bullet (1), where the page location would be http://localhost/scenes/{scene-id}

Scene buttons relocated to main navbar

We can also play around with the idea of relocating icon buttons into the navbar to further declutter the UI and streamline the UI/UX.

We use a subtle vertical line to partition the contextual icon buttons (in this instance the scene buttons) from global icon buttons (search, notification bell, overflow icon).

Navbar overflow menu on a studio page

Here's an example of bullet (3), the display of a keyboard shortcut beside a overflow menu item.

We can also consider collapsing some groups into a fly-out menu. In this example it's the Views items