[Feature] Performer Page Restructure

[elkorol]

Is your feature request related to a problem? Please describe. Currently on the performer page, there is a lot of wasted space. The performer image is to the left, the diver and hide performer image chevron and then to the right, the username, flag, social media buttons. Edit, Auto Tag etc buttons. The tabbed navigation buttons for details, scenes, galleries etc. And the rest of it to the actual gallery image/video container.

With the performer image not hidden, on desktop for me, it limits the contents of the gallery container to 3 columns. And below the performer image is a ton of wasted space. Imo it's better when the gallery container displays 5 columns, but I still like to see the performer image and I think clicking the hid performer image chevron to have more gallery columns is not needed and we could have both.

Describe the solution you'd like A restructuring the container div elements. Currently we have the div class of performer-tabs, which contains everything from the edit button down. I don't think it makes sense to include everything from the edit button down to be lumped in with the gallery grid container. But rather everything from the top, the username up until the element that shows the number of pages and total size of files, should be in a container apart from the gallery grid container. That way everything up until and including the element that shows the number of pages and total size of files, can be restructured and pushed to the right a bit. Allowing the performer image to always be above the gallery grid container, inline with all the other elements that are above it, allowing the gallery grid container to always to default to 5 columns, whilst still showing the performer image.

Sure it sacrifices the possible size of display for performer image but imho always having 5 gallery grid columns is better. Could possibly keep a chevron that upon clicking would move the performer image to where it is now with 3 gallery grid columns. So people can see the performer image in its full size.

Restructuring could also even add the possibility of getting rid of the details navbar element entirely and just always show the details of the performer, I've included 3 images, the first is just what we have now, the second is just a possible mock-up of a potential layout and the third is just another mock-up with the details nav tab removed and the details always showing. With the option to always show the performer details, there may be an issue with long details text that need truncated. Most details fields would be fine like this, the only one that would cause an issue would be the actual details field. Which can sometimes contain a lot of text. As this is primarily a request for a restructuring primarily for desktop usage. There are probably several methods to circumvent too much text if choosing to always show details. One would be truncating text and showing the rest as a hover able tooltip, which I don't really like. Another would be specifically for the details field, for its text to be in a container that is scrollable. Or show all details fields like, gender, birth date etc, except the one for text details usually description, and for that just have a read more link to that text. Which could popup perhaps in a div element.

Additional context Current Structure

Mockup Structure

Mockup with details tab removed and details always included on the page

[d3f113]

This may work with certain resolutions, but on mobile or tablet this won’t work

[echo6ix]

Conceptually I agree it's better to move the image and some basic details into a header, and have the page be a summary of cards for their scenes, images, galleries, etc. But there's just way too much going on in that concept that doesn't need to be there.

Conceptually you've basically created the ESPN player profile page. Notice they don't include every single piece of the player's biographical data in the header, only the most basic fields are displayed, and there is no redundancy (such as a gender or country flag, and then the name of the gender and country elsewhere). The rest of the player's biographical data is viewed on his bio tab (which is the equivalent of the incumbent performer page). Also, as mentioned above, the page scales a lot better to mobile views [try it on the ESPN link] when you don't try to throw everything and the kitchen sink onto the header.

[echo6ix]

Cleaner

The amount of detail columns in the header would scale depending on the size of the viewport, so it would work for a mobile viewport, just like ESPN's.

Edit: I just threw in a screenshot from the scenes tab into this mockup, and completely forgot to center it. Don't focus on that part of the image 😝

[elkorol]

That looks good echo6ix, much cleaner.

[echo6ix]

I've played with this concept some more and something I keep realizing with UI design is that it's really really really hard to pull off professional looking clean and useable UI as you add more data to the viewport. The thing I've noticed between professionally done UIs and amateur one's is that the latter just try to pack in way too much info all over the place.

You could probably even add a background image to the top header with low opacity to pull off an effect like this. I personally don't care for it, but I know there's a few people who like the hero image.

Or maybe move the overflow icon menu button down beside the other button for ux consistency...

Heh, the FontAwesome skull icon beside the performer's age if the death date field is populated.

This is what it could look like with the biographical details expanded. The background has a low opacity so you can sort of see the content behind it (in this case the performer tabs). The columns of the biographical details aren't symmetrical because if I could implement this I'd use the CSS flex property for each div with the bit of biographical data.

I think this also translates well to other pages, such as the tag page (and the studio page would be similar, as there's not much detail going on either) ...

The top header might take up slighter more vertical space the incumbent design, which might be a concern for people on laptops or large tablets. This can be addressed by scaling down the top header as the user scrolls down and changing it completely into a sticky header with minimal details. There's several designs that use this feature.

[elkorol]

I'm liking what I see a lot, the only thing I'm not sure about is having the Submit to Stash, Edit, Auto Tag and delete buttons hidden under a menu. I can understand for mobile but as I'm mainly a desktop user, and have the space I would rather it at least for desktops just have the buttons render like they are now.

Would it be possible for Stash to render those parts specific to the device that's requesting the page? Or at least have Stash render both and hide the ones not to be used with CSS specific to the browser and device being used?

My only niggle with them being hidden in overflow, is for the extra clicks, and most so for the delete button, which would now require three clicks to do.

I don't know if this would be appealing but what about getting rid of the edit tab and button altogether.

Just have it when a user taps the relevant field text for it to subtly change to an input box. Which could update the data on an interval after the last keystroke is received or an event to navigate away from the current page. So you could edit and you wouldn't even need to click save.

The only downside to that, not having a save button, would be accidental deletion of data.

[echo6ix]

@elkorol

I personally prefer the overflow button, but this is what it would look like without it.

I don't know if this would be appealing but what about getting rid of the edit tab and button altogether.

The problem with that is in my concepts the biographical section is only showing fields that do not have null values -- to reduce clutter.

But this is all hypothetical since I'm just doing this concept for fun and I highly doubt it will ever get implemented unless the dev somehow falls in love with and discovers time to do it.

[elkorol]

Here's hoping the dev falls in love with it then. Visually I do prefer the overflow but if I'm in task mode rather than browsing mode, I would prefer the buttons to be shown, otherwise hidden.

[echo6ix]

Removing the "show more" line reduces the vertical space of the header and removes a bit more clutter. Instead we could use an expand/collapse chevron by the performer's name to achieve the same effect.

A version with the performer avatar on the left.

And a version that displays performer aliases because apparently I overlooked that.

And a version with the disambiguation value.

A version of the edit performer page.

(Saving real estate by moving the clear image and set image buttons onto the avatar which is a more intuitive location imo).

[elkorol]

I keep liking the changes you are making, thumbs up from me, for this to be implemented : )

[WithoutPants]

Don't forget to consider the layout for small devices as well.

[echo6ix]

I did start mocking up mobile version concepts, I just need to complete them. They're pretty straight forward and more similar to the incumbent design, but I'll make some variations too.

[echo6ix]

@WithoutPants

Mobile views

You will notice in the mobile views that the order of some items are different

• The buttons are directly beneath the rating stars in the mobile view and not the desktop view. I think we can accomplish this by using the css order property, one set for mobile viewports, and another for desktop.

Collapsed mode

In this view the default performer page would be in collapsed with minimal performer info.

• Chevrons (expand/collapse button)
  • Expands or collapses the performer "details" info
  • Consistent with Stash's use of the same chevron to expand/collapse areas
• Overflow button
  • Use of overflow button to contain Autotag, Submit to Stashbox, Delete, and other potentially future options.
  • If this is undesirable, an alternate option could be to use icons instead of strings on the buttons to reduce the width they occupy. Edit = pencil icon, Delete = trash icon, etc.

Expanded mode

In this view the all the details are displayed. Each filed and its value would be a flex container similar to items in a grid view.

Notes

Other information relevant to desktop and mobile views

Social media icons, performer link icons, and performer related icons

Social media icons and performer link icon are all the same color. This is important so performer related icons, such as gender (and potentially any future inclusion of badge icons) can be another color (related to the Stash color theme) and will stand out.

[echo6ix]

After considering the design of stacked performer names (first name stacked on the surname), I realized that distinguishing between the first name and surname using CSS is not feasible due to the presence of spaces within some first names.

Updated views

• Performer name is displayed in one container unless it is too long whereby it would wrap
• Disambiguation and alias field have an opacity of 80% to better differentiate the text from the main heading (the name)
• Placement of social media icons and other icons. I am using slightly different placement for mobile and desktop views.
  • Desktop views has the icons directly under the avatar. Excess icons would wrap when greater than the width of the avatar container.
  • In mobile view the icons are also beneath the avatar insofar as they are the last element of the performer fields, including the buttons, and are left justified. Therefore, they are not constrained by the width of the avatar container.
  • I've moved them to other areas and one thing I have discovered is that they do not look well beside the rating stars and should not be beside the performer name.
• Age field hovercard (for desktop and mobile). Continuing with the less-is-more theme here, I believe displaying only the age is sufficient, rather than the date of birth too, to reduce visual clutter and cognitive load for the user. To strike a balance between providing data and maintaining a clean streamlined interface, we can display the birthdate as a mouseover hovercard on the age field.

Mobile views

Collapsed performer detail area (default view)

• Social media URLs hovercard (for desktop and mobile). Above concept demonstrates a tiny mouseover hovercard for a social media field with multiple URLs. Currently not applicable to Stash, but this functionality would be inspired by StashDB capability. Consolidating multiple links for the same social media platform is a more efficient use of space.

Expanded performer detail area

Desktop views

Collapsed detail container

Edit view

• Utilizing UI/UX best practices for form fields^best (this is all true for mobile views as well)
  • Using a wide one-column design for fields
  • Placing labels above, not beside fields
  • Do not use labels as placeholder text inside fields (placeholder text is to guide format)
  • Do not hide helper text on icon tooltips
  • Group fields logically based on theme
  • Desktop attributes only
  • Sticky display of group headings/labels on the side of the view port
    • Group headings are anchor hotlinks that scroll to appropriate section quickly.
  • Active group label gets bold
  • When scrolling down the page, the performer details header collapses into a small sticky heading

Biographical data group

Physical attributes group

• Multi-value hair color field
• Drop-down breast type field: null; natural; augmented
• Measurements field split up into their constituent components forces a consistent standard
  • Cup size is drop down with fixed values. See live example.

Scrolling down to aliases group

As the page scrolls down the header transitions into a small sticky header with basic performer info. The left side column containing the group heads reaches a point where it becomes sticky too, and the new group category, "aliases" becomes bold.

For brevity, this obviously does not contain all the fields, and the order of the groups and fields should be decided. My first go at it would be:

• Group heading: Biographical data
  • Field: Name
  • Field: Disambiguation
  • Field: Gender
  • Field: Birthdate
  • Field: Date of death
  • Field: Gender
  • Field: Ethnicity
  • Field: Nationality
• Group heading: Aliases
  • Field: Alias 1
  • Field: Alias 2
  • ...
• Group heading: Physical attributes
  • Field: Height
  • Field: Weight
  • Field: Hair color
  • Field: Eye color
  • Field: Tattoos
  • Field: Piercings
  • Field: Breast type
  • Field: Measurements
  • Field: Penis attributues
• Group heading: Career info
  • Field: Career start
  • Field: Career end
• Group heading: URLs
  • Field: Insta
  • Field: Facebook
  • ...
• Group heading: Tags
  • Field: Tags
• Group heading: Settings
  • Field: StashID
  • Field: Ignore Autotag toggle

Custom group headings and tags would utilize the css order property. This might make it easier when custom fields are implemented. User custom fields could either get a custom group heading or they could be placed in core group headings.

[echo6ix]

Reducing potential clutter in the UI by minimizing the display of the disambiguation value

Disambiguation is important when distinguishing non-unique strings (performer names). However, its significance diminishes when presenting a comprehensive profile, specifically a performers avatar (a highly unique variable). As a result, I propose treating the display of the disambiguation value as an additional performer field and not a heading. This would effectively increase cleanliness of the ui reducing the amount of large heading text that needs to be displayed. It also affords more room for the name heading in the event that it needs to wrap on smaller viewports.

Mobile

User preference for measurements to reduce yet more visual clutter: "Metric and imperial"

While certain users have a "more is more" mentality and would prefer to display both metric and imperial units, this ultimately displays more data than necessary. This dual presentation is redundant and contributes to increased textual content within the UI. To follow the theme of reducing visual clutter, as other apps/sites do, we can introduce a localization interface setting where users select their preferred units of measurement. Note: This user preference would exclude the performer edit page where metric units may be necessary for input.

Revising the sticky "header" to be compact

I am not sure I adequately defined what a sticky header is in the above posts. A sticky header refers to the behavior of a web sites or mobile apps header when scrolling down a viewport, where the header shrinks in size and remains fixed at the top of the screen. It is important as it provides continuous access to essential navigation elements or data, ensuring easy and convenient user interaction or access to info throughout the page.

The prior sticky header concept above was a bit chunky to accommodate for the performer's avatar. On smaller desktop viewports, such as laptops, it takes up quite a bit of real estate. The following concept uses a more compact sticky header, and I think this version also incorporates better into the tag and studio pages.

Note a sticky header would be for desktop viewports only. I don't think they should be displayed on mobile.

Version with a dark background color

The user has scrolled down the page and the performer header collapses into a compact pinned header with a dark background color. Content flows underneath it.

Version with no background color

The user has scrolled down the page and the performer header collapses into a compact pinned header with no background color. Content flows underneath it.

[echo6ix]

I think this can be closed. It was made to influence https://github.com/stashapp/stash/pull/3946