Scene details page styling

[cj12312021]

This pull request is parallel to #4699. @WithoutPants as I mentioned, I initially started this work as a separate thing and only later pulled from some of what you've already done in your pull request, so for now, it was easier to create this as a separate pull request. Feel free to pull parts of this into your PR or this PR can replace yours.

Tab consolidation here, for now, was done by only pulling out the gallery and movies tabs. At a later point, we could look into merging the file and history tabs. The info details, tags, performers, and galleries tabs, by default, will have a limited container height to keep its contents from consuming too much space. In cases where the height of the container is limited, a show more button will be available to expand the section. The content fields in the details tab use a flexbox so users can rearrange the order via the order CSS property.

[WithoutPants]

Can you please enumerate the changes made here and provide example screenshots? It's difficult for me to determine what is changed, and screenshots help illustrate the changes for others who can't/don't want to build it for themselves.

[cj12312021]

Sure, I can do that in a bit. The pieces are currently scattered over Discord as I progressed, so it would understandably be difficult to follow for anyone who wasn't already tuned in.

[cj12312021]

Updates currently made in this branch

Synchronization between Scene, Gallery, and Image details pages and other details pages

• The Scene, Gallery, and Image details pages have a background image toggle that behaves the same as toggles on other details pages.
• These pages sit right on top of the nav bar, removing the gap that used to live in between
• These pages now also specify an ID on the child div in the main container-fluid element, which should help with styling. IDs were also added to each tab across the pages to also help with styling.
• The details tab uses the DetailItem component for each field displayed in the tab. The data here lives in a flexbox, making reordering the data easy via CSS.

Tab updates

• Tabs on the Scene page will now collapse into an overflow button similar to this gif posted in Discord: https://discordapp.com/channels/559159668438728723/644934273459290145/1233444325522673764. Ideally, the desktop page would not be designed to rely on this, given that the width of the tab area is not variable, so we have more control. This was mostly designed for mobile users.
• The movies tab was pulled, and movies now exist directly within the details tab. For the most part, the slimmed-down style of the movie card is consistent with [WIP/RFC] Scene details page styling #4699. The only difference is that vertical space was saved by removing the title div below the image. Given the small width of the card, much of the title will typically be cut off. The title is also typically in the movie image, so I opted to display the title instead when hovering over the image.
• The galleries tab was pulled, and galleries now exist directly within the details tab. The design of the cards here is very similar to the movie card above it, with some tweaks to make the two easier to differentiate at a glance (images are provided below). The gallery viewer for each gallery can be accessed by clicking the expand button at the top right of the card. Associating gallery viewers per card addresses the previous limitation where the gallery viewer was only available in the gallery tab if one gallery was associated.
• A GalleryLink component was created to display the gallery card on hover, similar to the TagLink component. This component is also provided in the galleries sections, but it is hidden by default. I initially left this here to provide an even slimmer alternative for users who want to save vertical space but also want the ability to view the gallery cards. I'm on the fence about pulling this.
• The Details, Tags, Performers, and Galleries fields collapse data once they reach a set height. At that point, the Show more toggle will be available to reveal more information.
• The performer card is still too large, in my opinion, but it is slimmer than it was before. The size of the image is slightly reduced. The age as of scene text is shorter to just say {age} in this scene. The popover buttons are hidden by default to save vertical space.
• At echo6ix's request, I created a hidden element that contains the scene name and text that the user could swap to via CSS in place of the studio logo. Based on an initial concept he shared, this currently lives in the header area but was later proposed to be moved into the detail tab. I have yet to make this move (this is moved now).
• The | character used between the frame rate and resolution was swapped with the • character

Mobile improvements

• The gallery detail page has been improved, so users don't have to scroll through several images before getting to the details. A Show Details button hovers at the bottom right side of the screen, which users can use to space between the details and the images see https://discordapp.com/channels/559159668438728723/644934273459290145/1231719941074456576

Screen Captures

Setting options (it looks like the Image toggle is bugged and says Movie in the image) (this is fixed now):

Desktop Page:

Movie Card:

Mobile Page:

[cj12312021]

I'm thinking I'll refrain from pushing any more big updates to this branch until the direction of the content details pages is clearer. The following are my core motivations for pursuing this work:

• Tab consolidation that keeps the details tab consistent with the editable fields on each page while ensuring the tabs don't overflow on desktop.
• Better organization of details provided in the details tab. This is arguably the most important page in Stash, and the details tab is the first tab users will see. This page mustn't appear cluttered.
• Some synchronization of design between these pages and the performer, movie, tag, and studio pages.
• Improved mobile view for galleries and scenes.

In continuing this work for the core Stash repo, I'm flexible to make tweaks and adjustments that align with those motivations.

[DogmaDragon]

I think in details page, collapsing/expanding sections would be a better approach than using "Show more".

Similar to how Settings page does. It would also be more consistent with Performers details page rework.

[cj12312021]

In Qx's concept, it started with the arrows, but there was feedback that the arrows weren't as appealing when used in details tab. I think the arrows worked well in the settings sections because groups are clearly outlined and contain elements of various types (buttons, paragraphs, spans, etc), which isn't quite the case here.

In the performer/studio/tags details page, the groups didn't need to be clearly distinguished because there was just one large group, which the button expanded and collapsed,

The show more/show less button helps to act as a separator between the different groups. It also happens to be placed right where the user's eye would be if they were going through the displayed details and wanted to see more. And the button clearly explains exactly what will happen when pressed.

[DogmaDragon]

My concern is mostly about not being able to see all the details without clicking "Show more" several times. I don't think details tab is a section where truncating make sense. By its name, I want to see all the details.

Qx's arrow was overly big, but it can be minimized to look better. @randemgame example
.

[cj12312021]

The common complaint about the scene/gallery page is that it attempts to pack in too much info into such a small section, which is why putting some limit on the max height of each section made sense. I can understand some users may never have been concerned about the density of the info provided in that section and would want to see everything by default. It probably makes sense for the Show all details UI toggle to apply to this page as well.

Going back to the arrow discussion, I do think that implementation is much less intuitive here. The placement at the top is not intuitive in terms of how the eyes parse the information shown (as the user reads the details they shouldn't have to adjust their eyes up to hit the button and then adjust their eyes back down to continue), and the placement to the left makes it awkward if that section is small enough to where it doesn't need to be collapsed. Perhaps it was expected that the arrow would just always be there, even for small sections, and the sections would effectively just show all or nothing? But I don't think that a user would ever want to see nothing in any of those sections. In most cases, they want the info. They just don't want it to take up the full height of the viewport.

[cj12312021]

The show more/show less button is only present when necessary (for abnormally long sections). When it isn't present, the placement at the bottom makes it very easy for the user to ignore that the button wasn't used for the section.