[WIP/RFC] Scene details page styling #4699
Conversation
WithoutPants
added
improvement
|
As requested, some feedback. EDIT: I'm not sure why I made here instead of Discord, sorry. Some visual alignment "issues" with performers that have long disambiguation. The same is true if more than 3 icons are applied to the card. Both "issues" are potentially alleviated with horizontal alignment.
The date is now displayed in American English format instead of YYYY-MM-DD which are used in other areas of Stash. Ratings with decimal system looks a bit weird to my eyes. I like the History tab removed/moved, but it might not be obvious that it's still accessible by clicking on the O Counter or Play Counter count. The only direct cue of that as is alt text with different background color being an indirect one. In my opinion, URLs and Stash IDs should be moved to the Details tab. They are not generated from the file and are applied to the scenes, not individual files. The caveat here is that I don't know how URLs will be handled in the future, with #3530, but as it stands they are applied to the scenes at the moment. How is resolution handled if there are multiple files attached to the same scene that have different dimensions? Could we include the frame rate next to the resolution? It would please some people, and it shouldn't be an issue to those people that don't care about it. Could we have an optional toggle in settings for the studio image to be replaced with text (similar to how it's done with scene cards) and moved to the details tab? I know some people really like it, but having it moved to the details would allow to also display not only the studio, but the parent that studio is part of. Crude example |
|
Hey, I really loved seeing this update WithoutPants and as ever a big fan of Qx's design work. My original intention for the History tab was to consolidate all the date data in a sort of vertical timeline and I agree with everyone now that the stripped back implementation with just the O/Play Dates is not such an awesome feature in itself. Part of the value in displaying all the dates I think is just as this curious collection of data, not something you would necessarily be driven to go click on another tab to check. If the history was better visible at a glance when checking a scene, users would get some of that value, be that in triggering memories of watching that scene in some other condition or else being able to better contextualize themselves within the passage of time. I want to argue now that we should just be consolidating everything from File Info and History into the main Details view. I think incorporating the Movie tab here is a great step already towards cutting these panels that scatter so much related information across different panels and clicks. I worked on a mock up image after thinking through how all that consolidation would look, to try and satisfy everyone’s wants. It makes the sidebar more busy but if we implement the ability to expand and collapse the individual sections, users could customize it to their liking and thus wants satisfied. The only thing I'm personally checking the File Info panel for is to click the Stash ID and to open the file or folder on my desktop (using a Firefox add-on 'Local Filesystem Links' to be able to open the Path link directly or open Windows Explorer to the folder containing it) So, I would love it if both the Path and Stash DB links were available on the main Scene page to save that extra clicking around. I noticed DogmaDragon also mentioning here about moving the URLs and Stash IDs to Details. If we took those links out of the File Info panel it starts looking very thin. The Dimensions property is repeating the resolution info that we have at the top now. Then if we were to move frame rate there as per DogmaDragon's other suggestion, we are left with
I thought to first move the File Modification Time to hang out with the Created At & Updated At values. If we add the File Created Time here, currently missing from the file info, this would balance this ‘dates’ section nicely. If you take 'File Modification Time' away from the list it sits in, you'll see it was a significantly longer text than all the other properties and pushing the alignment of the values a tab or two further to accommodate it. That does provide a lot of extra space for the display of the small values associated with the remaining info. I’m worried it would be difficult to have two values on the same line, but that’s what I’ve gone with in the mock-up for now. I think there’s a lot of wasted space when keeping each value to it’s own line, and yeh, they’re all seemingly between 3-8 characters long. I would capitalize the codecs as it looks cleaner and that is how they are referred to in their documentation. I don’t see much value in all of these fields, but for those who love the File Info properties, I was able to find space to add the Audio Bitrate which was also missing, and balances the presentation of the values here. The two hash values are naturally grouped together but still a bit detached from everything else and I wasn’t exactly sure what to do with them. I was thinking that the hover-on explainer that a PHash is a Perceptual Hash really doesn't add a lot of value, knowledge or explanation here and makes it stick out weirdly from the other properties, so maybe that could be removed? Once a user has hovered over it once, they know what a PHash stands for (even if they have no idea what that means) so it seems unhelpful for the word here to be forever be in this tutorialised state. So that leaves us able to group the dates together as I had originally thought would be cool - the earliest date is at the top - the release date (and you know there’s some space up there to add a production date alongside it sometime maybe). Then traveling down from top to bottom through the File Created, File Modified, Scene Created, Scene Modified dates takes you on a journey that leads to the personal history dates. The old History panel functionality would always need to be the last section on the sidebar here as it both could stretch on very long for a scene with 5000 plays, while other times be taking up valuable space for a user whose majority of scenes are unwatched. Keeping the play and O buttons persistent at the top alleviate the need for most to check out the history, but it’s still important that it’s there and grows more important over time. I accidentaly spent the whole day thinking this through and making that mock up, so I hope some of it is usable at least in inspiring something or other. I figure there is some issue adding an editable section with the dates to the main Details panel if that was sort of designed as read-only, but if we include the option to hide/show sections here, maybe it’s ok? I was considerate of echo6ix's preferred organisation of the data but I'm not sure that a purely logical division of scene and file data is necessarily the best for the users. All that info sort of becomes one and the same on this Stash page and every user will have their own perspective on what info they find valuable and not. Sorry for the wall of text (and I just cut it in half so I hope I didn’t lose much in the way of reasoning) Few other things. The links section I think could easily be removed if we used buttons for them all,say next to the scene title similar to performer’s urls, twitters, etc. I changed Movies to Movie but it still looks a little odd to me. Some other text like ‘Featuring In / Now Playing’ might be better. The O/Play dates would ideally be displayed from oldest to newest to keep this unconscious chronological journey as you take in the info top to bottom. Not super important right now and.I guess we are still extending how that section looks later. Maybe we can add a descending/ascending type button. I gave it a little touch up in the mock up, let me know what you think. Little unrelated, but can you fix it so every time a user adds an O date to a scene it also adds a play date? I’ve racked my brains and can’t think of a way someone could honestly add an O to a scene without it being played at the same time. Oh, I added a NEW! Bit of text to display next to the date for when a file had been modified, it would also work when a scene had been updated. It could be useful to have some user notification reminding them they swapped a 720p scene for a 4k maybe, but maybe it’s nothing. Ignore it anyway lol. I wasn’t really planning on coding this, it was just a visual mockup thing but I wanted to share my philosophy and sort of design thoughts that you can adapt or discard as you like. This message was obviously too long for Discord but I’ll be available for discussion there |
|
Had some organising to do so took the oportunity to test this branch out. Some feedback based on trying it out for a few days:
File Info
I'm not sure about the order of information. Specifically Studio Code, Director and Movies being at the bottom is weird. IMO they should all be higher. I'd suggest Studio Code, Director, Details, Tags, Movies, Performers and lastly Created At/Updated at. My reasoning: Studio Code is important, for JAV it's arguably as important as the title. I can understand some don't use Director but I'd personally put it above performers like in the Edit tab. All my scenes have performers/tags but not all have movies. Having it hidden below means you have to actively check (which as above, can be quite a way down!) and can't see at a glance.
More generally, with losing a little bit more vertical space, the whole section it starting to feel really cramped. Having collapsible sections would help but ultimately it's only ~450x600px on desktop. An option for the studio to be text inside the tab like like DogmaDragon suggests would be a massive improvement but doesn't solve it for people who like the studio header. I don't know what the solution is here. The example LG screenshot is much less claustrophobic but I wouldn't want to lose the player... Maybe allow the player to be shrunk/collapsed? Overall some great changes, thank you (though I really hope File Info can survive now there's two less tabs!). |
|
For tab consolidation, instead of pulling out the file info and history tab, along with the movie tab, perhaps we could also pull out the gallery tab. Those two tabs alone should eliminate the overflow issue. I'll also link this concept I posted in the theming channel, which was followed by some good suggestions https://discordapp.com/channels/559159668438728723/1196910630460985544/1230675968297799791 |
I agree with CJ. I'd rather see the Gallery and Movie tabs removed (and linked within the Details tab). Keeping the File Info and History tabs. |
|
The Galleries tab displays every image in the gallery when only one gallery is linked. Are you proposing all those images be displayed in the main tab or the feature removed entirely? The former would be less than ideal, and removing that feature would be bad. |
|
My suggestion is that on the details tab, we would have some indicator similar to movies that would link directly to the gallery details page. The indicator could just be a detail item that reads
Where, via CSS, we would simulate stacked images that users could slide through one by one via the widget or blow up to the full screen and slide through using the lightbox. I'm personally fine with the former, but the latter would be nice. To be clear, I am fine with merging the history and files tabs (just not pulling them both out). In doing that, we would need to find a more suitable name for the new tab. Pulling out the gallery tabs is another suggestion towards the goal of tab consolidation. |
|
I should have clarified something. I say removing it is bad solely on the basis that it removes a feature. It's too bad there's no way to gauge what features the user-base is using. If no one accessed the entire gallery via the gallery tab, then removing the feature maybe wouldn't be bad. |
|
I can't speak for the whole user base on the value of that tab, but I am (as far as I've seen) the biggest collector of galleries here. I rarely use the galleries tab for anything other than just getting access to the galleries page. The biggest thing the gallery tab currently has going for it is the ability to immediately view all gallery images without using the pagination, but that feature will make its way to the gallery page at some point. It's never great to have to take a feature away, but sometimes that can't be avoided in cases like this, where the number of features is more than the restate can handle unless we consider a complete redesign. |
|
This is relevant to the tablist navbar. How the Github UI deals with overflow on navbar.
I think the only nav-item that would need to change to accommodate this version would be |
|
I just lost a whole essay I wrote here, so I'll be 'brief' for once (lucky youse!) edit: Just wrote a longer essay instead Losing the Galleries tab would be a major regression, it is important to have a space to display the images that users have connected to scenes directly alongside the scene itself. I am only just learning about the Galleries tab but it displays Images in a very aesthetically pleasing manner and it would be a real loss to cut it. Also, it may hurt a lot of users who put in organisational work, expecting the results to be displayed as they are now.
First, we're all agreed I think that it makes sense to move the Movie tab, as a single image, to Details instead. Similarly, the History tab is just displaying text, there's nothing unique here compared to the other tabs layouts. Above I said it could fit at the bottom of Details but thinking on it, that wouldn't work if you want to keep the Details panel 'locked'. Better then to move it to the bottom of the Edit panel. To better support that, I think you could move the Scene Cover Image from the bottom of Edit to the top of Galleries (Galleries is responsible for both Galleries/Images due to how they are so tightly connected so this should be the tab to handle all scene related images) This does not require a complete redesign, the History tab is not so pretty right now and it doesn't need to be that pretty when it's cut pasted into the Edit panel. (though I did present a prettier display for it in the image above you're free to take) We can shift these things around a little without having to redesign them so nicely, that can come later!
Yeh, you can't remove the Galleries tab based on this your use case though especially considering how extreme it is... Perhaps having so many Galleries is actually detrimental to using the feature? I am going to have Galleries with one or just a few images connected to a scene and would definitely be using that tab regularly if I had the images in already. It seems a waste of time now for me to assign images to scenes through the time-consuming gallery process if the end result is not even having them displayed together! Also, maybe the galleries tab is underused because it is super convoluted needing to create a gallery to attach a single image to a scene. After discussions on Discord I see that we are stuck with galleries as a necessary connecting link between an image and a scene, but it is still an undeniably tedious workflow right now in certain common use cases. This is a workflow process I'm sure can be improved upon in the future, and with a little less friction I think the Galleries tab would get more usage overall. I have also been thinking how the Galleries tab could be developed a little further, considering it is really the combined Images/Galleries panel owing to this mandatory connection. If we were to move setting the Scene Cover here from Edit, we could also have it as a space for the user to store screenshots of the video, similar to how the user can store clips of the video as markers. The Markers and Galleries could then be very complementary tabs. (Markers are so user-friendly and intuitive that it's kind of wild to contrast how easy it is to make a video clip compared to the multi-step process involved with attaching an image to a scene currently.) TL:DR; Galleries are a super essential tab, it is so weird to remove that tab before the more obvious candidates in File Info/History. Galleries tab has much potential for future utility! Also this is pretty important, removing this feature is going to hurt a lot of users in different use cases, who may not be talking on Discord, but still who could have put in a lot of organisational work in a time-consuming interface, specifically due to the ability to display scenes and images together as we currently have it with the Galleries tab. A lot of my organisational work is based around the aesthetics of the end result and to lose this great tab entirely, when it can be avoided and it wouldn't require such a large redesign is absolutely the wrong move. |
|
I'd recommend against merging the file info or history tab into the details tab. The details tab can currently have a lot of info packed into it and doesn't need any more. I think, ideally, that tab would directly represent the info provided in the edit tab. Perhaps an argument could even be made to consolidate the edit tab and the details tab if this were the case. Ideally, the file info and history tabs would be consolidated into one separate tab, which still provides a file count directly on the tab, indicating the number of files associated with the scene. I think this is the only indicator we have that tells users duplicate files exist when the user isn't actively searching for duplicates. |
One metadata tab to rule them allRelocating all metadata into one Metadata labeled nav item to rule them all imo is the simplest and most intuitive presentation. Yeah, it's a lot of info in one tab, but it can be cleanly organized and partitioned with headings. Headings can also be collapsible, and funky things can be done with CSS such as active sticky headings per section when scrolling. At the cost of losing a nav-item file badge counterI agree with CJ though in one regard. It creates a conundrum with History is playback metadata not file info metadataSo I'm okay if Relocating items between the tabsThe scene URLs belongs in the incumbent Better nav-item tab labelsWhile we're at it, lets use this opportunity to improve (synergy, consistency, and clarity) the nav-item tab labels.
|
I've been running my changes on my production server since last week, and it has been refreshing not being exploded with information every time I open a scene. Not having so much information that the tab overflows makes a difference, given the cramped space. Sure, throwing an accordion, like the one we have for filters where a section can be open at a time, could help prevent overflow, but you would effectively just be creating more tabs within an existing tab (and more clicks to access data that was previous immediately available), which I would opt to avoid if possible. |
You definitely have an advantage here as I haven't used the one metadata tab concept. But I'm okay with a dedicated If we can implement the Github ellipses overflow button, then I am actually totally fine with leaving things as is, including the dedicated history tab. The advantage to this approach is that it's not relocating existing items on the userbase, aside from when the overflow is triggered but that element is so ubiquitous in design that everyone can adapt to it. Plus we can already reorder tab nav-items, to place our most and least desirable items near the front and end respectively [role=tablist] {
display: flex;
.nav-item:has([data-rb-event-key$=-details-panel]) { order: -1000; }
.nav-item:has([data-rb-event-key$=-edit-panel]) { order: -995; }
.nav-item:has([data-rb-event-key$=-file-info-panel]) { order: -990; }
.nav-item:has([data-rb-event-key$=-queue-panel]) { order: 990; }
.nav-item:has([data-rb-event-key$=-filter-panel]) { order: 1000; }
}Probably an unpopular opinion, but the one tab item I always see as out of place is the |
|
I've already implemented Github's tab overflow on my branch. And yes, I think if we aim to achieve parity with the editable fields and the fields displayed on the details page, it would make sense to pull the edit tab into an actionable button. That would be consistent with the details pages, which were reworked last year. |
Studio logo and studio textThere's been discussion about relocating the studio image or having a settings option to toggle it in favor of text. But since we want to mitigate the amount of configurable settings I have a simpler proposal.
Fallback studio logoSecond, a lot of studios do not have logos to display, and they never will, such as studios that belong to content creator platforms. Visually I think it would be appealing if we display the parent networks studio logo as a fallback image when the studio logo is null. And the img tag's title property should have the name of the scene's studio.
This is kind of in line with many sub-studios using their networks favicon when they do not have their own. |
|
I think one Metadata tab is a fine idea and combining the Details with Edit would be preferrable with me as well, for sure. I really think Tabs should be dedicated for the display of information that does not fit in what would be combined as Details / Info (Metadata) / Edit (so Galleries and Markers and Queue all benefit from their own visual space to display Images, Markers and Thumbnails, Filters is awkward enough to require it's own space). File Info has one quirk that isn't even that well implemented (comparing two file's info) and History is just a bunch of dates. I think having fields collapsible in the Details/Info/Edit tab can let users decide what they want to see here so it needn't be so overwhelming at all. I don't think it's overwhelming and I'd prefer being able to just click on a scene and start editing the details I see there - having the scene rating now editable in that way is a real benefit already on develop. It should work like the Performers page right? Click to see Performer/Scene > All Editable Details available to view > Click Edit and start making changes there on the page. The File Info properties are not editable, but still belong integrated into other Details. As I've argued above, once we remove even more data from here such as the URLs, there is going to be a very small amount of unique information on display. I think I largely agree with the Metadata concept above, and I think that's what I was largely going with the mock-up I originally made but I'm still imagining it as a tab that would merge Details - File Info - History - Edit into one (no-one is clamouring for a dedicated History tab! it's really better integrated as I demonstrated above - people don't go out there way to look at playback history typically, it's info that is best just attached as an extra bit of context, and even better contextualised with all the other dates) :
You argue playback history is part of Metadata here but then move it another tab, and I'm still not getting it. Already the way Stash can update scenes to have files being replaced with identically named files (with different creation and modification dates), shows that we are really playing God here - everything we display should be to the greatest benefit, ease and customisation of most users... Sometimes I'm even disagreeing with scraped or even studio data - fixing a Scene Title due to grammar or it being very stupid to something I personally prefer it be called, sometimes using a different data like production rather than release if I find it, and then ratings and history are entirely personal anyway (ooh just realised we're missing a history of personal ratings now :P) I think I made a distinction between everything editable and not with the File Info section in the mock up here...
To accommodate multiple Files being attached, this drop down would be duplicated, right? e.g. a File Info (2) and then the options to delete/make primary etc. I personally would still be keeping this un-collapsed as I am not interested in the codecs or file size anyway, but after links and repeating info are omitted, and even with the inclusion of the hashes (I'm not sure, are both hashes file specific?), it's a tiny little thing not warranting a dedicated tab! The only thing missing if we merged the above mock-up details with Edit in the earlier mock-up is the Scene Cover thing, which I argued for in the last comment should be moved to Galleries anyway because Galleries is actually 'Images and Galleries' more accurately and should bear responsibility for all the Images related to a Scene. I'd even rename the Galleries tab to Images, make it a permanent tab, and make it easier for a user to add Images (singular/multiple) to the scene here in an automatically created Scene Gallery. This makes sense as it is otherwise the only tab that would pop-in and out of existence per scene otherwise. I did not even know this galleries tab existed some months or years after using Stash! Like the Markers tab, there should always be an option to Add Images (Screenshots or Uploads) to a Scene. TL:DR; As the creator of the History tab, I don't want a History tab! I only invented it that way in the first place when it combined more Date information, as it was going to be developed further as more of a timeline thing. Forget it! Just stick the dates with the rest of the Editable Details so they can be either un-collapsed for people like me interested in seeing it a glance when having a scene open or collapsed for people who don't care, so nothing need to be overwhelming. |
This has also already been implemented, although the studio text was placed and hidden next to the studio logo like I saw in a earlier concept. I don't mind moving it into the detail tab. |
|
Regarding the gallery tab, I'm thinking I'll add an expand button at the top right of the galleries listed in the details tab. When used, that button will pull up the gallery viewer, enabling the user to view gallery images like before (this gallery view will not contain the gallery card like the current gallery tabs does, as it would be redundant). |
Because I do not have experience using the one-metadata-tab interface and @cj12312021 does. I have no basis to provide substantiated feedback on how pragmatic it is.
Because the motivation for much of this was to consolidate tabs due to the tab nav-item wrapping issue. However, that is being addressed with a Github tab style overflow button. For me that solves the issue and tab consolidation isn't necessary other than maybe the
😂 @cj12312021 I am assuming the gallery card thumbnail in your image would inherit the styling from the stock stylesheet, and not your theme styling with the faux polaroid borders? Not that it isn't cute. Same question about the performer cards actually. The distinction between the stock stylesheet and your custom theme might not be clear to others. Thanks again for your continued work. |
When posting, I didn't have the time to launch my dev environment. The performer card in the stock style sheet would not look like the one in my image. It would look like the card seen in this video https://discordapp.com/channels/559159668438728723/644934273459290145/1233800090368475166 (basically a slightly slimmer version of the card people are used to) The gallery card would look just like it was in the image. The white border is necessary to establish some common ground with the fake photo behind the thumbnail. Remember, it is just a restyles gallery card, not a new component. Here is a video I posted earlier from the stock CSS: https://discordapp.com/channels/559159668438728723/644934273459290145/1232173300390694943. |
|
It's probably worth stating that the gallery tab will currently only show the gallery images when 1 gallery is associated with a scene. Once you associate a second gallery with a scene, you lose the gallery viewer functionality, and the tab will just display the gallery cards. My suggestion above will not have that limitation. |
|
The original intent of scene galleries I believe was to associate a related image set with a scene. Many studios will release an image set to accompany a scene - x-art is the immediate one that comes to mind. The intent of the gallery tab in the scene detail page is to allow browsing of these associated images while viewing the scene itself. Removing the Gallery tab as done in #4785 represents a functional regression of this feature. If we are to remove this feature - and I am personally against doing so - then a plugin needs to be made to provide the existing functionality. |
|
My current proposal does not suggest removing the gallery viewer functionality. As mentioned in #4699 (comment) the gallery view would be revealed per gallery from within the details tab rather than having a dedicated tab. As mentioned here: #4699 (comment), the dedicated gallery tab loses the gallery viewer function when more than one gallery is associated, effectively making the tab less useful. |
|
My latest push to #4785 contains the gallery viewer implementaion for the gallery cards in the details tab. A video of the implementation can be found on discord https://discordapp.com/channels/559159668438728723/644934273459290145/1235077086675341332 |
|
The first thing that comes to mind is it unnecessarily breaks the consistency of the grid card presentation which is the same throughout the app. The second thing that comes to mind is that it breaks the consistency of functionality with its corollary on the gallery details view page when a scene is associated with a gallery. Does it follow then that scene grid cards and the scene tab get a similar rework on the gallery page? Not sure I think that's a good idea. I love a lot of your uiux contributions but I'm just not feeling this one. :-/ To take what @WithoutPants said and turn it on its head, maybe a better approach is to leave the incumbent function of associated objects as is, but make a plugin that modifies the behavior and presentation to your design. |
|
I think this looks very sexy #4699 (comment) and I could defo live with it. I'm too noob to even realise the gallery tab was useless if there was more than one gallery, I haven't gotten that far yet. Sorry I'm not more experienced to give too valuable feedback or notice if there is some issue with it. I had not used the galleries tab before realising you were to remove it and then I suddenly had to defend the feature if it were the only image of images and scenes together) At least take all my notes as a 'new user experience' sort of angle. There's a slight side-track here regarding my recent confusion about 'why can't I assign a scene to an image directly but need to have it be part of a gallery first'. As it's fairly related to my whole recent posts. I'll bold the parts where it's relevant here. I think one way of making things easier could be solved by having each scene create their own semi-hidden-pseudo-gallery by default. This could be first populated with the cover image (so that the galleries is always visible on the scene details page) and then just be a place for users to dump any e.g. extra screenshots, wallpapers, custom art, bts/ related social media images, maybe 1 or 2 photos from the official image set. As WP says, galleries are designed for 'a related image set with a scene'. This has always been my interpretation but that leaves nowhere to assign wallpapers and other related imagery (see https://discord.com/channels/559159668438728723/644934273459290145/1233820696140976238) - I understand it's best to reverse engineer a gallery for this task then create any alternative way to connect scenes and images in the database as I understand. My issue is I don't collect these large photoshoots just 1 or 2 images. I really think there should be an option somewhere on the scene page to add an image from file or url or screenshot (as simply as we can add a marker, I think these features both share a parity whether concerning images or clips and should be bought together more harmoniously in the design), this is functionality I have seen from the start of much crappier software. Then this automatic scene gallery could be a place to store all that. One of the relevant points here is that the galleries tab should not be something that blinks in and out of existence as it does now. I did not know it existed, I have yet to assign any images to galleries to scenes as I got held up by the tedium of it all. Having a sort of invisible-pseudo-gallery always present as default, and using the Cover Image as the first image to populate it (or some placeholder if no cover image available) would be a way to draw users attention to the feature, I think - anything is better than it being hidden, I reckon. [sidetracking...] Then the improved workflow could have a user select an image in the Images window, then a new option to assign it to a scene based on a drop-down search of all scenes automatic gallerys. Maybe this is a plug-in thing, but I think assigning an image to a scene in a frictionless way is more of a 'core' thing that is relevant to any Scene details or Image details page discussion.
I am still making the argument that we should be eliminating the amount of clicks that users have to make to get relevant information. It's not just about that overflow thing, but a way to bring information like File Info and History more immediately visible when clicking on a scene. Then it does not need to be so overwhelming if each of the sections were collapsible as they'd be entirely customisable. |
I'm afraid I have to disagree with you here. The gallery cards are large, and multiple of them can be used. Presenting the whole card in this limited space would work against the goal of decluttering. Presenting any of the cards fully in this space doesn't make sense. We're not presenting the full movie card or performer card and shouldn't be presenting the full gallery card. The gallery tab currently isn't fully functional, so I don't understand an argument suggesting keeping it around. If your critique is about the gallery card style, suggest a new one rather than suggesting a revert to previously broken functionality. I don't mind removing the border and the fake image behind the image to bring the design closer to the movie card. My goal was to make identifying the gallery and the movie cards in this space easier at a glance. I agree that the scenes tab on the galleries page, like the movies tab and galleries tab on the scene page, should be pulled. Right now, my focus has been on the scenes page. |
|
Don't let me be the bottleneck. Remember, my involvement here started as an independent project that overlapped with WP's existing work. The original plan was for WP to borrow concepts he liked and discard the concepts he didn't into this PR. I offered to oversee the rest of the work if interests aligned. It's fine if they don't. |
tab list nav-item decluttering?I'm still under the impression that the impetus to consolidate the gallery tab and everything that flows from that was was due to tab nav-item wrapping: Which has been resolved with Github style tab overflow behavior. Therefore, there's no need to declutter the understanding the issue with incumbent gallery functionalityIf I understand correctly, I think your issue with the incumbent gallery tab functionality is the limitation to view images when multiple galleries are linked to a scene. Your aim is to provide consistent functionality in that scenario. This is worth addressing... within the confines of the proposing a gallery resolution with some of your changes in mindMy resolution here would be very unsexy:
My rationale is:
I wasn't aware of the specifics, but either way your time and work is much appreciated, including your critiques. I am just one opinion here. Just to summarize where I think everything's at Uncontroversial amendments everyone seems to be okay with
Proposals with mixed or lack of feedback
Alright. I have a ton of errands to do in meat space now. I hope this feedback finds everyone well.✌️ |
|
As I mentioned in https://discordapp.com/channels/559159668438728723/644934273459290145/1233800090368475166 I do not see the collapsible tab functionality as an excuse to ignore tab consolidation. I don't think it's ideal for tabs to overflow. CSS will not allow users to determine what enters the overflow first and what doesn't. CSS can only change the order in which tabs are displayed, not the DOM structure. The javascript that handles the overflow looks at the DOM structure. It knows nothing about the styles defined by a user. There is still the greater goal of aligning the details tabs with the edit tab, making the removal of the edit tab more seamless. |
|
Tab consolidation is fine if the items being consolidated are superfluous (such as
Agree, but sometimes unavoidable. This is a consequence of a lot of features in a confined space. It might be better to explore the relocation of less contentious items first. When there is a maximum number of tabs populated, the overflow is two items:
Unmentioned tabs items
My hierarchy of most worthy tab items for relocation:
|
|
You and I will just have to disagree about this. I’m personally pulling the gallery tab out. I’ll leave it to WP to make the call on the main repo. |
Inspired by @QxxxGit 's #4582, this is an overhaul of the Scene details page.
It includes the following changes:
DetailItemcomponents like the other (studio, performer) details pages.Filesfield has been added to the details pane, which has links with the filenames (basenames only). Clicking on these links brings up the file info panelMoviesfield has been added to the details pane and theMoviestab has been removedTODOs:
XL screenshots (side bar):
LG screenshots:
