search

stashapp / stash

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

[RFC] Proposal For Configuration Section Refactor #1549

Closed jeremymeyers closed 2 years ago

jeremymeyers commented 3 years ago

### Scope Rework the config page for better organization.

Long Form

As #1548 is moving scrapers to its own page, I think it would be good to take a look at the configuration section overall.

My suggestions are as follows:

Separate pages into collapsible sections, expanded by default

(like this: https://www.codehim.com/bootstrap/bootstrap-vertical-menu-with-submenu-on-click/ ) Screenshot 2021-07-02 16 57 22

Move stuff around

(in no particular order)

Content Section

The purpose of the Library section is to show configuration settings related to WHICH CONTENT IS INDEXED OR NOT INDEXED

Library

System Section

The purpose of the System section is to show configuation options and settings related to BACK-END SETTINGS

Paths Menu

Logs Menu

Maintenance Menu

Indexing Section

The purpose of the System section is to show configuation options and settings related to THE INGESTION OF CONTENT

Playback Section

The purpose of the Playback section is to show configuration options and settings related to VIDEO PLAYBACK

Playback Menu

Conversions Menu

Users Section

The purpose of the Users section is to show configuration options and settings related to USER LOGIN

Appearance Section

The purpose of the APPEARANCE section is to show configuration options and settings related to USER INTERFACE

Interface Menu

Extensions Section

Plugins Manu

The purpose of the Plugins section is to show configuration options and settings generated by PLUGINS

echo6ix commented 3 years ago

I think you have the settings page organized well.

Settings Layout

My only suggestion here would be to rename some headings to make them more specific, and some of these might seem pedantic and subjective so I apologize in advance. For example,

Settings GUI

I think everything in the settings page should be filterable with a filter-on-search type mechanism that a lot of settings pages have (Chromium, Visual Studio Code, etc). And that's part of the reason why I suggested to make headings more specific.

I tend to favour a Material Design ui, like the new Microsoft Edge settings page (and to a lesser degree the Chromium or Chrome settings page)

Desktop layout Screenshot 2021-11-25 034945

Mobile layout Screenshot 2021-07-09 001901

jeremymeyers commented 2 years ago

@WithoutPants thoughts on this? I can give it a whirl if you like.

WithoutPants commented 2 years ago

That looks fine. I don't think there's any support for theming beyond setting the custom css content.

echo6ix commented 2 years ago

I've done my best to organize the structure of the settings page. Please contribute any modifications or suggestions.

Settings structure

The settings tree will use the follow structure:

Use this layout as a visual guide to the structure where,

Primary headings

Sub-headings

Sub-heading items

Primary settings order

A work-in-progress

Settings tree

The settings tree is just a semantical reference of most of the settings to help us organize sections of the settings. If we're going to refactor the settings I strongly suspect we need a basic reference point for the different sections and their items.

A work-in-progress (sorted alphabetically by primary heading)

Notes

WithoutPants commented 2 years ago

From Fonzie on Discord:

We don't need to split up Settings and Tasks, and we also don't need a 3-level deep Settings tree where you spit up the two desktop page-long Interface in 7 different sub-trees so that "Editing" with its current 6 lines ends up on its own single page. Using a sledgehammer to crack a nut won't make things better.

The sheer amount of information on these pages (with Configuration page maybe as the exception) isn't the problem or that the current 9 nav-items are too many. The two big problems are the spacing between the sections/form-groups within the pages so you don't really get a sense when one section ends and a new begins, and that everything is too vertical cause the design does a poor job of using the width of the page. (Plus #3: quite a few options are poorly explained.)

From an early survey result we know that a large majority mostly access Stash from Desktop and only 5% Mobile Only. So I can't figure out why seemingly most design ideas are mobile first desktop second, and/or try to copy a solution from & for browser settings rather than one from & for website settings.

image

echo6ix commented 2 years ago

we also don't need a 3-level deep Settings tree...

Is that referencing the settings tree in this thread because I don't understand how the criticism is applicable.

If so, I'm not sure the commenter understands the purpose of the settings tree is just a semantical representation of all the settings to help us organize them. I was going to write it in YAML but I thought it would be clearer for most people the other way. If we're going to refactor the settings, we need to compile a list of the main categories and most of the items, so we can decide if we won't to consolidate, split, purge, or shuffle sections, and at least the settings tree gives us some a basic reference point.

It's not a literal tree UI, and I guess I may not have been clear enough in the structure section where it defines primary headings are left column, sub-heading cards are right column, and the items are contained within the sub-heading cards. The images he references use the exact same "three level deep" structure I outlined:

<h1>Preferences</h1> <----------- Primary heading , displayed on the right, "level 1"

<h2>About Preferences<h2> <----------- Sub-headingc "level 2"
<p>Item 1</p> <----------- Item, displayed on the right, "level 3"
<p>Item 2..</p> <----------- Item, displayed on the right, "level 3"

<h2>People You Follow<h2> <----------- Sub-heading, displayed on the right, "level 2"
<p>Item 1</p> <----------- Item, displayed on the right, "level 3"
<p>Item 2..</p> <----------- Item, displayed on the right, "level 3"

Gonna be brutally honest. Those pics as a guideline are hideous. I don't know any modern app with simple and intuitive UI/UX that is using an archaic message board Web 1.0 layout as its inspiration. That is literally a step backwards, like 15 years in the past backwards. There is a reason iOS, Google's Material (Chromium, Android, etc), Windows 11 settings, some Linux DEs, are all using a "three level deep" card layout for settings.

The card layout solves the "two big problems" precisely -- since each sub-heading group lives on it's own island in a card. i don't think another visual layout exists that conveys to the user "this group of items here on this card are all categorically related to one another and separate from the other sections that live on the other cards", so I'm confused at the criticism or maybe just misunderstanding what it is directed at.

I'll see if I can build a wireframe later, and I'll edit my prior post to make it clear that the settings tree is just a semantical reference.

7dJx1qP commented 2 years ago

I think "System" is a better name for the "General" heading.

I would also move it down on the list. I don't think any of the settings in that section are modified that frequently, if at all. Library paths are most likely to change, but I think it's something that happens occasionally if at all. If someone setting up stash for the first time sets their paths in the wizard, then I can see them not ever needing to even go to the system section.

If we look at browser settings, they even hide the System section under a collapsible "Additional settings" header. I don't think we need to go that far, but I don't think our equivalent of system settings should be first on the menu. It's not even the default tab if you just go to http://localhost:9999/settings. The default is Tasks, so it would make more sense to put that at the top.

echo6ix commented 2 years ago

@7dJx1qP All good suggestions

Here's a wireframe of what I'm talking about. Ignore the lack of items or how they're categorized, I just threw in a few to portray the gist of the UI.

Image attached below or clickable in a different window here

by6JTWovaLh3ccEuHmvCBn

WithoutPants commented 2 years ago

I think General is better renamed to Library, and that the Application Paths should be moved to a different panel (ie System). Application paths are not something that are likely to be touched very often, and mostly for exceptional circumstances. As mentioned above, I'd make Tasks first, then Library, then the rest with System near the bottom.

I don't think stash-box integration belongs in Services. Services implies stuff provided by the stash server (ie DLNA). I would say it better belongs in Web Scraping, though that title probably needs generalising as a result.

I like the wireframe posted above. My only addition there is that it needs to be clear in the interface when there are unsaved changes to the configuration. A floating save button at a bear minimum along with a warning if navigating away with unsaved changes.

echo6ix commented 2 years ago

My only addition there is that it needs to be clear in the interface when there are unsaved changes to the configuration. A floating save button at a bear minimum along with a warning if navigating away with unsaved changes.

@WithoutPants Just curious, why can't user input to all the form items be automatically saved in the background [source]. This would nullify the purpose of a save button.

echo6ix commented 2 years ago

Some other thoughts.

Renaming items

Consider the following:

CSS

Can we give classnames to primary headings, sub-headings, sub-heading titles, sub-heading descriptions, sub-heading items, sub-heading item descriptions, etc.

echo6ix commented 2 years ago

Just curious, why can't user input to all the form items be automatically saved in the background

Upon some thought, something like this would need to be disabled for the CSS section. The custom css should have its own save button, regardless of how the rest of the settings are saved. Here is my concept of the Custom CSS subsection layout.

Custom CSS subsection

To reduce clutter on the main settings page and to increase the usability of the Custom CSS input box, herein referred to as the CSS Editor, add an external launch icon that opens a new browser window specifically for editing custom CSS.

CSS Editor

Image: Custom CSS Subsection interface

Image: CSS Editor (standalone browser window) pNrPA82KHXUGD6KWv4DmMZ

echo6ix commented 2 years ago

I don't think stash-box integration belongs in Services. Services implies stuff provided by the stash server (ie DLNA). I would say it better belongs in Web Scraping, though that title probably needs generalising as a result.

@WithoutPants Agreed re: Stashbox and scrapers all categorized in the same top-level/primary section. The web scrapers and Stashbox both provide metadata to the users content. Therefore, how about we name the top-level section containing them Metadata providers. Kodi calls their add-ons section of metadata scrapers Information providers, but I'm partial to just Metadata providers personally.

Edited the settings tree to reflect suggestions.

echo6ix commented 2 years ago

Library subsection concept image library

A version where there are expand/collapse chevrons next to each library source. Each source would be collapsed by default. This could be useful for people who have a lot of sources.

wwuZqrkJCk9u9UjwYyK9e2 ce

echo6ix commented 2 years ago

Jobs queue concepts (I renamed it to tasks queue for consistency since they're referred to as tasks and not jobs throughout the rest of Stash.

Image: Tasks queue is inactive

tasks queue inactive

Image: Tasks queue active, scanning in process

tasks queue scanning

Image: Tasks queue active, auto tagging in process

tasks queue autotagging

echo6ix commented 2 years ago

Here's a version of the tasks queue that I think incorporates the old layout with new layout

nqj5aHJVusF9FQY9LY1Qrj

Edit: Consolidated the help icons in the Scanning options section to just one icon.

kermieisinthehouse commented 2 years ago

nqj5aHJVusF9FQY9LY1Qrj

This last one is perfect. It's only missing 'Save as default' for the options, and it's done.

echo6ix commented 2 years ago

This last one is perfect. It's only missing 'Save as default' for the options, and it's done.

How's that?

nqj5aHJVusF9FQY9LY1Qrj

kermieisinthehouse commented 2 years ago

We don't use switches anywhere else on Stash, but I don't think switching checkboxes to switches across our UI would be so bad. Bootstrap already has some.

I think this design is ideal, especially the collapsible options. We need to make a few more collapsible options across our settings to really simplify it.

7dJx1qP commented 2 years ago

The "Default scan options" button wording looks off to me. I think "Set as default", "Save as default", "Save as default scan options", or "Make default" makes it clearer. Looking at all the buttons in Chrome settings, they all start with a verb when they are buttons that do something.

The task buttons (scan, identify, auto tag) should also probably begin with "Start" as well. Personally, I'm used to the current labels, but I can see new users getting the same feeling about the wording as I did about "Default scan options". Eh, I think they're fine

echo6ix commented 2 years ago

I am not sure if using switches would be appropriate as a way to select items in grid view. For that section I'd leave checkboxes, and use the switches in the Settings pages, provided the Settings page instantaneously saves changes the user makes. I made the concepts in the assumption that changes would be auto saved, but should have clarified that.

Switches should never require users to press a button to apply the settings because a switch is a toggle button. When you require users to press a submit button, you confuse them because it’s not what they expect.

You should only use switches on settings that need to take effect instantaneously. If a setting requires a button press before it can take effect, you should use a checkbox instead.

A checkbox does not apply the settings at an instant like a switch. Instead, it’s has a submit button and takes effect after the user presses it. Requiring a button press allows users to review their settings before they commit. This requirement helps prevent accidental activation errors.

Source: https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

WithoutPants commented 2 years ago

I agree that if we move to switches then we should auto-save for everything [edit: in settings specifically].

jeremymeyers commented 2 years ago

This last one is perfect. It's only missing 'Save as default' for the options, and it's done.

How's that?

nqj5aHJVusF9FQY9LY1Qrj

love this and would just suggest that the task queue have both a noticable visual differentiation (as it is showing actions taking place rather than options being set) as well as a notice that the actions will continue even if you navigate to a different page.

7dJx1qP commented 2 years ago

Will the tasks queue still show the output of the current running task? I like seeing the task output for the currently running task, but it can be hard to cancel other tasks, because they're constantly getting shifted up and down by the current task output. I suggest making the output for the current task collapsible.

philpw99 commented 2 years ago

Loving this conversation ! Great concept !

echo6ix commented 2 years ago

I may have made a mistake with all the text input boxes. Because the aim is to have the settings page instantaneously save changes, I think text input boxes will require an Edit/Change/Add type button that opens a small modal window. I noticed that's how the Chromium based browser do it.

Example:

nqj5aHJVusF9FQY9LY1Qrj

Clicking apply in the modal window would then apply the change.

WithoutPants commented 2 years ago

One alternative would be reset and confirm buttons on the text fields to reset/apply the field value. Also note that for some fields we'll need to group them into a dedicated dialog - for example, the authentication username/password setting should be atomic.

echo6ix commented 2 years ago

Will the tasks queue still show the output of the current running task? I like seeing the task output for the currently running task, but it can be hard to cancel other tasks, because they're constantly getting shifted up and down by the current task output. I suggest making the output for the current task collapsible.

@7dJx1qP Yeah, that's why in my concept wireframe the status of the current task, it's output/progress, and it's cancel button are all on the same line. However, that means the output will need to be truncated for long filepaths. But it's up to the devs if that's how they implement it.

love this and would just suggest that the task queue have both a noticable visual differentiation (as it is showing actions taking place rather than options being set) as well as a notice that the actions will continue even if you navigate to a different page.

@jeremymeyers Hmm, what would you suggest? Different card color maybe? A more visible icon indicator?

I took inspiration entirely from Chromium based browsers. Their Settings > About pages do not have any user options to change, but only show information. For example in the below image where it says the browser is up-to-date, when it is performing a task (downloading), the icon iirc turns into a download spinner, shows a percentage, and has a different status message. Almost par for what the tasks queue concept does.

nqj5aHJVusF9FQY9LY1Qrj

7dJx1qP commented 2 years ago

Yeah, that's why in my concept wireframe the status of the current task, it's output/progress, and it's cancel button are all on the same line.

One line isn't enough for task output. This is what I see when I currently see when I run a scan: image The number of lines is constantly changing and I think it depends on the number of threads that are in use

echo6ix commented 2 years ago

Oh, I must have misunderstood then. My Stash scans only use one thread so I've never seen that before.

jeremymeyers commented 2 years ago

Yeah, that's why in my concept wireframe the status of the current task, it's output/progress, and it's cancel button are all on the same line.

One line isn't enough for task output. This is what I see when I currently see when I run a scan: image The number of lines is constantly changing and I think it depends on the number of threads that are in use

it could be one progress bar for current task completion progress and a second one on a new line for overall queue completion, though that introduces math and would maybe require some assessment of what is in the queue before starting...

Though also I kind of feel like a queue is maybe not the right framework? It is a list of active and pending actions, each of which can be launched individually. Am I wrong in saying a queue in this case would more often be a "stack a bunch of tasks and then hit a Start button and have them all go"

7dJx1qP commented 2 years ago

No, I think conceptually it is a queue. You can start a bunch of tasks and they are queued up with one running at a time.

The issue I'm pointing out is that if a task that's running has multiple threads, it will log the output of each thread right below the task, and the lines are constantly changing and shifting any other queued tasks below it up and down.

These three screenshots shows task output at different points in time of a scan task (with 7 parallel threads) with two other tasks queued. Sometimes there's no thread output if they aren't doing any work, and you can see the other queued tasks below. Other times the whole area will be filled with thread output because they're all doing some work and you won't see the other tasks unless you scroll down. The number of lines changes many times in fractions of a second. 2021-11-29 21_36_51-Settings _ Stash - Brave 2021-11-29 21_36_26-Settings _ Stash - Brave 2021-11-29 21_36_39-Settings _ Stash - Brave

I think there's a few ways this could be addressed: 1) Move the thread output to a separate section above or below the list of tasks 2) Make the thread output section collapsible 3) Make the thread output section a fixed height regardless of how many lines of thread output there are. This would stop the rest of the tasks in the list from constantly shifting up and down 4) Separate the current task + thread output from the rest of the queued tasks, so the current task thread output won't prevent you from seeing the rest of the queued tasks.

jeremymeyers commented 2 years ago

Will the tasks queue still show the output of the current running task? I like seeing the task output for the currently running task, but it can be hard to cancel other tasks, because they're constantly getting shifted up and down by the current task output. I suggest making the output for the current task collapsible.

@7dJx1qP Yeah, that's why in my concept wireframe the status of the current task, it's output/progress, and it's cancel button are all on the same line. However, that means the output will need to be truncated for long filepaths. But it's up to the devs if that's how they implement it.

love this and would just suggest that the task queue have both a noticable visual differentiation (as it is showing actions taking place rather than options being set) as well as a notice that the actions will continue even if you navigate to a different page.

@jeremymeyers Hmm, what would you suggest? Different card color maybe? A more visible icon indicator?

I took inspiration entirely from Chromium based browsers. Their Settings > About pages do not have any user options to change, but only show information. For example in the below image where it says the browser is up-to-date, when it is performing a task (downloading), the icon iirc turns into a download spinner, shows a percentage, and has a different status message. Almost par for what the tasks queue concept does.

nqj5aHJVusF9FQY9LY1Qrj

not to muddy things up here. I get what you are saying about the Edge update section and would just suggest that that is fulfilling a different need (i.e. an update of the entire underlying platform one is using, which would require a restart and is kind of a binary process (either its done updating or its not and no more granular detail is provided) as contrasted by our use case which is "show the current status of tasks the user has selected as well as how much other stuff remains to be done"

Yeah i would put it in a different color or maybe even make it fixed position on top so that the scrolling starts right above "tasks queue" in your wireframe

echo6ix commented 2 years ago

I think nitty gritty details like this are gonna come down to user preference. 🤷

Yeah i would put it in a different color or maybe even make it fixed position on top so that the scrolling starts right above "tasks queue" in your wireframe

Fixing the position might work well on large viewports, but laptop screens and mobile viewports it might be a bad idea. Not sure.

Since the Tasks Queue is the top element in the column it would be pretty easy to use a pseudo-class (eg. :first-of-type) in custom css to change the color of the card to whatever you think is appropriate.

I'm currently looking at my TrueNAS dashboard to see if there's anything similar. It does have a Task Manager of sorts (itemized tasks progress with pct% indicator), but it is utilized as toast content when you click the task icon in the nav bar. Fwiw I think something like that is being added to the nav bar, just not sure how interactive it is going to be.

QxxxGit commented 2 years ago

Custom CSS subsection

To reduce clutter on the main settings page and to increase the usability of the Custom CSS input box, herein referred to as the CSS Editor, add an external launch icon that opens a new browser window specifically for editing custom CSS.

[...]

IMO, I think it's fine to keep the textarea as-is until a long term solution for easily installing themes comes to fruition. Most people are going to edit CSS in an application of their choice anyways i.e. VS Code. Would just be unnecessary work, IMO.

Other than that, I think switches are the way to go. I think they'll look better/modernized than checkboxes on mobile too. I also really like the new layout echo6ix conceptualized. It's clean.

echo6ix commented 2 years ago

It's more about design consistency tbh. Text input forms, especially mutlivalue ones should get a modal window, otherwise i think we're gonna need a save or apply button after every text input item since the global save button is being deprecated. I mean, the CSS Editor would be just another window, it doesn't have to be decked out with line numbers, alternate line coloring, and syntax highlighting. It can be pretty basic for the first iterations for the reasons you suggested.

echo6ix commented 2 years ago

Here's another mistake I think I made in my concepts. In every image showing a caret or chevron meant to expand/collapse icon, I incorrectly used an up caret/chevron to indicate the content was in a collapsed state.

Wrong usage of expand/collapse icons

Correct usage of expand/collapse icons

jeremymeyers commented 2 years ago

I think nitty gritty details like this are gonna come down to user preference. 🤷

Yeah i would put it in a different color or maybe even make it fixed position on top so that the scrolling starts right above "tasks queue" in your wireframe

Fixing the position might work well on large viewports, but laptop screens and mobile viewports it might be a bad idea. Not sure.

Since the Tasks Queue is the top element in the column it would be pretty easy to use a pseudo-class (eg. :first-of-type) in custom css to change the color of the card to whatever you think is appropriate.

I'm currently looking at my TrueNAS dashboard to see if there's anything similar. It does have a Task Manager of sorts (itemized tasks progress with pct% indicator), but it is utilized as toast content when you click the task icon in the nav bar. Fwiw I think something like that is being added to the nav bar, just not sure how interactive it is going to be.

I mean this is outside the scope of this discussion but at some point possibly adding a footer bar to communicate information might be valuable?

kermieisinthehouse commented 2 years ago

Closing as the settings page has been refactored, and released in 0.12.0. Great work on the design!