[RFC] Renaming and presentation of all tagging/scraper components and related labels

[echo6ix]

Scope

To enhance the user-friendliness of all tag related component labels and presentation.

Goals

• Concise and relevant labels a non-technical user would understand
• Avoid technical jargon such as "fragment" and "scrape"
• Mitigate ambiguous strings and presentation
• Enhance the labels with icons when appropriate

Items of interest

This RFC will consider the efficacy of the following labels, strings, and icons

• Scrape All
• Tagger
• Tagger tags icon
• Scrape with...
• Scrape by Fragment
• Scraper Query
• Scene Scrape Results
• Identify
• Auto Tag
• Scrape with spyglass icon
• Unrelated to the above tagging related components but possibly contributing to confusion is the word Tags found in the nav bar and throughout Stash

Proposal

To ELI5 the goals of the above functions we could accurately say they all share the same purpose: to import metadata.

These functions import metadata in different ways, from parsing predefined keywords in a filenames (Auto Tag) to perceptually analyzing content and matching hashes with corresponding content on a stash box (Scrape by Fragment, etc). Some of these processes are user-guided (Tagger, Scrape with..., etc), and some are unguided processes for fast batch processing (Identify, Auto Tag).

Starting from general to specific, the logical semantic hierarchy they all share in common begins with importing metadata. Much like good communication flows from general to specific and uses hierarchies to organize data, we can do this on the UI using the interactive visual elements and meaningful labels.

Currently, some labels exist as islands on their own. They context that would add meaning to their purpose. I am suggesting any action related to importing metadata should flow from a heading or button label that reads Import metadata. With import metadata as the primary context, it blatantly adds clarity to the user what the primary and subsequent labels/functions will do.

Current label	Current icon	Proposed icon	Proposed label	Example
Scrape with...		file-arrow-down	Import metadata...
Scrape by fragment		fingerprint	Analyze or Scan
	spyglass	spyglass	Lookup
Tagger		file-arrow-down	Import metadata
(Tagger) Search		Spyglass	Lookup
Identify		fingerprint	Batch analyze or Batch scan

Proposed Scrape with... replacement

• Does not add extra clicks
• Improves consistency. All communication pertaining to the process is contained in the modal. Currently null results for a Scrape by fragment function is returned in a toast message, while null results from a Scraper query is returned in the modal.

Proposed Tagger replacement labels

• Lookup and Analyze labels should have corresponding icons on their buttons

Auto tag replacement

Using the word auto tag adds confusing with the existing term tags

Auto tag remains the most difficult label to replace concisely. Some suggestions include

• Filename parser - Scene filename parser was originally suggested, but "auto tag" parses more than just scenes. Parser can be considered tech jargon, but this might also be considered an advanced feature.
• Import metadata from filename or Match metadata to filename - This is the least concise but the most accurate. This choice should be accompanied with an icon, such as folder-magnifying-glass
  • The label would be used in the settings cards and in overflow menus
  • The icon would be used without the label on the studio, performer, and tag pages. This shouldn't be concerning considering this function is due to receive a warning modal dialog

Auto tag and Identify replacements in the settings

• Identify --> Bulk analyze
• Auto tag --> Match metadata to filename

• Having two distinct cards for each function divorced them from their semantic hierarchy and context was not ideal
• In this example both functions are consolidated into an Import metadata container

Onboarding

If implemented, a simple onboarding process would be necessary on first-run and help docs would require updating. Onboarding would require screenshots demonstrating the new button labels and their functions.

Edit

• Added Scan label for Scrape by fragment. More accurate per suggestion.

[scruffynerf]

I still object to the combining of "paths" of 'Analyze' and 'Lookup'. Unless you are going to change the entire way Scrapers work, this is not viable. Those are distinctly different things and combining just pushes the problem one level down, leading to the user being unsure they mean, just like Scrape and Search do today.

I do not look forward to answer the question "what is the difference between Analyze and Lookup" as any easier to answer to Scrape and Search. At least with Scrape and Search, people understand Search as an idea, but Lookup doesn't even have that benefit.

I appreciate the effort above and even agree with the idea of renaming and some consistent changes...

But Tagger would still be lost in the shuffle.

Tagger needs to be Upfront, not just an icon. It's lost now, and new users can't find it. It should be Labeled as a Primary choice, even if we just add Text to the icon (as previously discussed.)

[echo6ix]

Thanks for the feedback.

I do not look forward to answer the question "what is the difference between Analyze and Lookup" as any easier to answer to Scrape and Search. At least with Scrape and Search, people understand Search as an idea, but Lookup doesn't even have that benefit

Lookup and Analyze

Just for the record, these two labels were directly influenced/lifted from MusicBrainz Picard. I am purposely not trying to recreate the wheel, but appealing to popular apps and their familiarity with the same or similar functions. If we want to be user-friendly we're going to have to sacrifice technical dev level accuracy of terms. Yes "analyze" isn't technically correct for anything other than using StashID, does the user care? Nope.

Lookup (search, find, and other synonyms of search)

• Lookup is a direct copy of Picard's button label. Does effectively the same function.
• Using a Search label as you suggested would possibly make more sense than lookup. Keep in mind, the Scraper Query function should be named Search everywhere it is used, now and where ever it is implemented into the UI in the future. This might cause some confusion in of itself because we have other elements using the string search. Using Find instead of lookup or any unique synonyms of search would be great.

Analyze

• Picard uses the word Scan for the same function as Stash's Scrape by fragment (which may be optimal but I avoided it because we already use the word scan in a lot in other areas prominently). I would totally endorse using Scan instead of Analyze if it's meaning is more encompassing. But going forward I'll refer to it as Analyze just to avoid confusion.
• Definitely copied their fingerprint icon for this function

The use of tooltips

I use some apps for work that follow good UI design principles, but there are still areas of the UI and functions that I am unfamiliar with. Principles that help me understand what those unfamiliar elements do are the context in which they are grouped/placed together with similar items, and tooltip labels.

Lets look at what Picard uses as button tooltips for these functions and what Stash can use.

Analyze

• Picard tooltip for "Scan"
  • Identify the file using it's AccoustID or fingerpint
• Stash tooltip idea
  • Identify content using its StashID or attached URL

Lookup

• Picard tooltip
  • Lookup selected items in MusicBrainz
• Stash tooltip idea
  • Manually find content (using scrapers?)

Example tooltip on hover

or alternatively if Scan is a better label than analyze

---

I still object to the combining of "paths" of 'Analyze' and 'Lookup'. Unless you are going to change the entire way Scrapers work, this is not viable. Those are distinctly different things and combining just pushes the problem one level down, leading to the user being unsure they mean, just like Scrape and Search do today.

I think I understand what you mean and it is due to my failure to incorporate that Analyze would also import metadata using URL scrapers if I am understanding correctly. I simplify overlooked including them in my explanation, ironic considering I've contributed several 😅

It doesn't really change anything though in the concept. Incorporate this into the button tooltip, and move away from the label Analyze to something like Scan or a synonym of scan. 🤷

Grouping them together on the Edit pages is still important because we're going from their general purpose (to import metadata) to their specific process of how they do that -- scanning their StashID, using a scraper, manual search, etc -- on the self-contained modal. If that is not simple and hand holding the user I don't know what is? It's also fairly logical.

---

I still object to the combining of "paths" of 'Analyze' and 'Lookup'. [...] Those are distinctly different things and combining just pushes the problem one level down

They are different functions initially, and I did clarify that, but they share the same goal (to import metadata) and ultimately get to the same destination.

Emailing someone and calling them are distinctly different things, but they serve the same purpose (to contact someone), hence why email addresses and telephone numbers are universally grouped together within "Contact" details on both print and electronic mediums. The same principle applies here using the "law of similarity" design principle^law. Other common examples include open file, save file, save as, delete, all typically grouped together in a file operations umbrella. The examples of this principle are endless.

The other reason I grouped them together is these functions are found on the Edit page. The edit page's goal supersedes just importing metadata from scrapers. If there was a container or card strictly dedicated to scraping on the Edit page then it would make sense to have two distinct buttons initially. Again, trying to use the law of similarity here. Notice in my tagger concept that I do keep these buttons unmerged since the entire purpose of the Tagger page is already all about importing metadata*.

There's a calculated method to the madness.

---

Tagger

But Tagger would still be lost in the shuffle. Tagger needs to be Upfront, not just an icon. It's lost now, and new users can't find it. It should be Labeled as a Primary choice, even if we just add Text to the icon (as previously discussed.)

Onboarding. You can't expect users to be familiar with an app without some simple onboarding. Gmail does it when you first use it or when they modify/introduce a feature. I think Discord does it to a certain extent. Some MS Office products do it.

See https://github.com/stashapp/stash/issues/4336#issuecomment-1837249540

---

Edited to reference concept for placement and color of "Tagger" button

[DingDongSoLong4]

Tooltips are great, and I think many of these kinds of issues can be solved with an informative tooltip.

As long as the name doesn't cause the user to incorrectly assume what something does (for example, understandably assuming that the Tagger only adds tags to scenes, rather than all types of metadata), and as long as the button itself is discoverable and not hidden away (like again, the Tagger button, as mentioned), then the name doesn't have to fully explain all its functionality in two or three words. A tooltip can easily explain what is missing from the label.

As for the suggested "Identify content using its StashID or attached URL" (sidenote, whether this is StashID or Stash ID probably deserves clarification/discussion in a separate RFC as well): if we're using "Analyze" as a replacement for "Scrape by fragment", then this isn't an entirely accurate tooltip. When scraping from a stash-box, what is currently "Scrape by fragment" only matches using fingerprints (oshash, phash and md5). When scraping using normal scrapers (i.e. not a stash-box), then "Scrape by fragment" passes a "fragment" to the scraper which it then uses as input to match to an external scene. A "fragment" is a JSON object containing the metadata already attached to the scene, like name, studio code, date, url, etc. Strictly speaking, "Scrape by fragment" is thus incorrect when scraping with stash-boxes, since no "fragments" are ever used. However, I think it would be useful to 1. add fingerprints to the "fragment" passed to normal scrapers, and 2. also use other scene metadata (i.e. a fragment) when matching to a stash-box. This could improve matching on stash-boxes, and I'm sure some scraper could find a use for fingerprints. So "Scrape by fragment" is still okay when using a stash-box.

So a tooltip more along the lines of "Identify content using its existing metadata" would be more accurate, and more concise as well, in my opinion. Fingerprints could perhaps not be seen as strictly "metadata", so then "Identify content using its existing metadata and fingerprints" could work.

[echo6ix]

@DingDongSoLong4 Thanks for the clarification. I am not nearly as technically fluent as you, and I think my misunderstanding of some of these terms is proof in the pudding that simpler consistent terms are necessary (sometimes at the cost of being technically precise). I was the demographic we're trying to appeal to. I know what the buttons do in Stash through trial-and-error, and don't necessarily care what processes are behind it, even as someone who will make scrapers now. I guess it's a give-and-take sort of thing... less technically accurate and dumbing down the labels will appeal to a broader audience at the expense annoying users who are programmatically literate.

Analyze is definitely too specific. Perhaps Scan is better, as suggested in my above edit. The word scan is ambiguous enough to convey what's going on and can encompass what the tooltip is suggesting.

Tagger

I'm not sure how y'all would make tagger more prominent other than some minor tweaks in placement and reusing elements across Stash for familiarity

• Rename Tagger to Import Metadata (see above for rationale). This label is as unambiguous as it gets and remains consistent with the proposal for the edit pages. Consistency and familiar = good
• Use the same file-arrow-down icon that would be used with every Import Metadata button label, including the incumbent buttons that scrape individual URLs on the Edit pages. Consistency and familiar = good
• Give the button its own standalone toolbar button instead of being segmented with the view buttons
• Move the placement of the button to a more prominent area on the toolbar
• Change the color of the button? ~~Maybe? Does it need to be that prominent? Tagging files isn't the primary purpose of the view pages, it's just one of several, so this suggestion is very hoarder centric imo.~~

[echo6ix]

• Different placement of the Tagger aka Import Metadata button because maybe it is awkward being a prefix to Search
• Prominent color (imagine its using Stash's primary cyan)

I guess this actually isn't too bad and definitely stands out from the rest

[scruffynerf]

Add Tagger (or some other wording) to the icon. In previous discussions, it was agreed adding Text made it standout more.

[scruffynerf]

still not sure you are "understanding correctly", but I've given up on fighting people on explaining what a horrible idea this change to the UI to smush it all together is... So do whatever you want.

[DingDongSoLong4]

I like "Find", it's short and simple. Although "Lookup" is short and simple as well - I don't have a preference between them.

Scan is good, except for the issue that it's used elsewhere. How about "Match"? The thought process being it's using your scene's existing metadata (the fragment and fingerprints) to find a matching scene on the external platform (ie the stash-box or wherever the scraper is getting its data from).

And as for the Tagger, I've always thought that it didn't really fit as a "view", alongside "Grid", "List", etc at all. Its purpose is adding metadata, whereas the other views are for finding/filtering/searching through your content. I think it would be really nice to move all the "Taggers" (or whatever they end up being called) out of their respective scene/performer/studio pages, and into an entirely separate page, which would then have views/tabs for each Tagger "type". But that would be a much larger change, and should probably be a separate discussion.

For now, we can just change the button to make it more discoverable. There definitely needs to be a label - I don't think just the icon is good enough. As for the colour change, it definitely makes it stand out, but it feels to me a bit like the icon is "selected" in some way. There would also need to be some kind of colour change to show when it's actually selected as well. I think separating the button from the other "views", and adding a label, should be enough, without needing a colour change. There's also some relevant discussion regarding this change, and the Tagger in general, in #4220.

[scruffynerf]

thanks for finding the Tagger issue, yes, #4220 for the red button with text. Doesn't have to be red, doesn't have to say Scene Tagger, but that's what it needs as a concept.

[echo6ix]

@DingDongSoLong4 👍

Scan vs match

Putting myself back in the shoes of a new user, if I had to choose between Scan and Match I'd prefer Scan. Scan being a common verb through Stash was one of my concerns too, but also the context matters and the Scan label would appear within the context of importing metadata. If it was just a standalone scan button on the edit page hanging around the other buttons, then yeah, definitely would be problematic imo.

Tagger

I didn't know moving tagger out of the toolbar was up for consideration. I was trying to keep my suggestions as minimally invasive as possible. 😅

I think adding a label is good idea. I would never have suggested it because of potential pushback from users who already think the toolbar is overcrowded.

I think my strongest recommendation would be the name changes of all the aforementioned labels including tagger. Tagger and Auto Tag are too easy to equivocate with Tags.

[DingDongSoLong4]

Scan vs match

Fair enough. Scan is still good with me :+1:

I didn't know moving tagger out of the toolbar was up for consideration. I was trying to keep my suggestions as minimally invasive as possible. 😅

It isn't really, at least not here. I just felt had to mention it, since it is relevant to the Tagger discoverability issue.

I think adding a label is good idea. I would never have suggested it because of potential pushback from users who already think the toolbar is overcrowded.

It is a bit yeah - maybe on smaller screens the button could lose its label? Although meh I don't think it's that big of an issue.

I think my strongest recommendation would be the name changes of all the aforementioned labels including tagger. Tagger and Auto Tag are too easy to equivocate with Tags.

It's difficult to know without actually seeing it, but I feel like "Import Metadata" might look weird as a label on the button - it is quite long. I'm not saying to not change the name - "Tagger" is definitely confusing - but another single-word name or a shorter name would be really nice. I haven't been able to come up with anything though.

[echo6ix]

@DingDongSoLong4 I agree Import metadata is a long label, but it's also the most accurate to the best of my knowledge. If that label is going to confuse a new user than I suspect any label would confuse them.

Just staring at my screen here and I noticed the following long button label on GitHub:

Close with comment is longer than Import metadata

Point is, maybe sometimes a longer label is acceptable if it really nails the purpose of the button.

It could be shortened with Import details, but I think you're sacrificing utmost accuracy for a few extra characters, no?

[DingDongSoLong4]

Okay my bad, I didn't explain well enough - I meant the long label on the button could potentially look out of place given that everything else there is just icons without any labels.

Here's a very rudimentary mockup by moving some divs around, which I probably should have just done to begin with:

And it's not as bad as I thought - but it definitely doesn't need any more emphasis with a colour change.

I would prefer a shorter name, but I don't think we're going to find one at this point. "Import metadata" is great in every way except length, and length is realistically the least important criterion. It's definitely much better than Tagger.

[cj12312021]

We should consider how the text change will appear on a mobile screen. This stack of buttons already occupies a lot of space on those screens and isn't presented very gracefully. A wordy button would not help that problem.

I preferred the icon with text on hover.

[echo6ix]

@DingDongSoLong4 You could employ some superficial cosmetic modifications to save space on the toolbar

Search field

• Change the search field into an expanding search field
• The inactive length of the search field doesn't need to be so long. The search field could expand when it's active, meaning when the cursor is placed inside it, and contract when it is inactive. See https://mdbootstrap.com/docs/standard/extended/search-expanding/ (note their default search field is way too small but you get the point)

View buttons

• Consolidate the three view modes into a single button with a drop down indicator
• The active icon on the button would be the actively selected view mode
• Yes it adds an extra click but it's not uncommon. The Windows file explorer and some linux shell explorers have the exact same implementation for view modes

Zoom slider

• Change the zoom slider into a single button with a drop down slider
• Refer to universal volume sliders that require a click on a volume icon before the slider appears
• See above rationale. Also some browsers do this, such as Chrome (no slider, but they do have a popup control once the zoom button is clicked)

Mobile toolbar view per @Teda1's comment

• I'm afraid this is where button labels go away and only button icons are displayed
• Other option is to shove more crap in the overflow button, such as all the wall views buttons and import metadata buttons

It's not so bad when it's organized by similarity and partitioned with horizontal lines.

[cj12312021]

Perhaps we could take a page from Plex's book here.

It's cropped out in the image, but above this area, there is a magnifying glass that brings up the search textbox when clicked. Other sites, including Bang and Adultime, use the same magnifying glass for search.

[cj12312021]

It's unclear to me why we would break out Import metadata from the view group. It really Is just another view. It doesn't bring up the import metadata modal like on the scene details page. I think we shouldn't call it Import metadata for that reason to avoid misleading users who may expect the same window to appear.

[echo6ix]

@Teda1

Perhaps we could take a page from Plex's book here.

This looks good to me.

It's unclear to me why we would break out Import metadata from the view group

Personally, I am indifferent with regards to breaking it out from the segmented view group buttons or keeping it as. I can envision it working both ways, but the case to do so is as follows

1. To make the button stand out from the others. The claim is the button "gets lost in the shuffle ... new users can't find it"
2. You wouldn't use the Tagger view to browse, and you wouldn't use the Grid/List/Wall views to tag scenes - there's a clear logical distinction there, but they are all treated "equally" as views.

Reason 1. I don't know if this is true. It's unsubstantiated in any quantifiable way. It might be true, and it's not completely implausible, though I don't know. The Stash Discord has +2,000 users and I'm not seeing a torrent of feedback about it on Discord or Github that is proportional to user base size. It's plausible that just seems true due to sampling bias and negativity bias from the help channel. 🤷

Reason 2. For me this is compelling enough. While you are correct, it is another way to view scenes (view mode), the purpose is unlike the other views, the goal of that mode is for importing metadata.

I think we shouldn't call it Import metadata for that reason to avoid misleading users who may expect the same window to appear.

My reason for suggesting the label use the same name for the tagger button and again for the scrape with in the edit page is basically consistency, simplicity, and grouping similar functions under a familiar easy to understand umbrella. The feedback was that new users and novice users are really confused by the existing labels.

I don't see it as too terribly problematic because it's not uncommon for labels/icons to get reused through a UI within different contexts. For example, in Visual Studio Code, the manage label/tooltip and cog icon is used next to every extension to designate the extension can be managed/configured. The label/icon is also used more prominently on the bottom side bar of the app to navigate the various aspects of the app that can be configured.

[echo6ix]

This is off topic, but sometimes I wonder if a professional ui/ux designer will ever comes across my posts and think that guy has no $@%^ clue what he's talking about 😂

Translation: These are just my layperson opinions. Take with a grain of salt.

[scruffynerf]

Yes, they do.

[echo6ix]

lol. salty.

[cj12312021]

Personally, I am indifferent with regards...

Yeah, I don't completely agree that those 2 points are reason enough to split it out. I think the main issue was the ambiguity of the current button, which could be alleviated by using the suggested drop-down, which uses text instead of icons. In the drop-down, I suppose we could call it Import metadata view, but we could keep the name open for improvement.

This is off-topic, but sometimes I wonder if a professional ui/ux designer will ever comes across my posts and think that guy has no $@%^ clue what he's talking about 😂

Haha, I don't know what they would say, but I'm sure they would appreciate the effort you put into thinking through your suggestions.

[DingDongSoLong4]

@Teda1 On mobile specifically, I agree that we could shrink buttons down in the ways you're suggesting to save some space. The entire mobile UI needs attention - there are many things that can be improved - and that deserves a separate discussion I think.

As for on desktop, I don't think we need to shrink anything. The reason I didn't like the long label was because it makes for a big button, in an area where there are only small buttons, which looks at least a bit odd. But if we are going to shrink things, we cannot hide the Tagger behind yet another dropdown - it isn't "just another view", or it is at least fundamentally a completely different "view". Doing that would make it even more difficult to find.

As I see it, a "view" of a list should show the same content, but present it in different ways. Different views could emphasize certain kinds of item "attributes" and omit others, but fundamentally you should be able to perform the same actions from all the different kinds of views. In a file manager, for example, you usually have at least three different views: "icons" (a grid of entries, each with a large icon and a name, stacked vertically), "list" (a vertical list of entries, with different attributes in columns, like name, file type, and modtime), and "compact" (sort of similar to "icons", but the icon and name are now horizontally adjacent and the icon is much smaller, to be the same vertical size as the name). The exact names here will vary of course, but you get the idea. Each of these views is tailored towards finding a file/folder in different ways: "icons" is for searching by thumbnail, "list" is for searching by attributes, and "compact" is for searching by name only (or probably more to just be compact - "list" is just as good. I've never really used the "compact" view myself). But my point is that there is no action in one of these views that you cannot do in all of the other views as well. Yes, it may be easier to do certain things in certain views, but fundamentally you can still select, open, rename, delete, etc. from each view.

But the Tagger is not like this - you cannot scrape for metadata from the other views. As a matter of fact, you cannot scrape for metadata like you do in the Tagger anywhere else in the app, and submitting fingerprints to a stash-box is only possible in the Tagger. The Tagger is no ordinary "view". This same basic point is also made in https://github.com/stashapp/stash/issues/4220#issuecomment-1777461028.

I'm making the comparison to a file manager, because to me, the Scene List (i.e. the Scenes page) looks basically like one: it has a list of content, search, filters, sort, views, etc. This similarity means a new user would not expect a "view" to do anything other than "list in a different way". The Tagger does not "list in a different way" at all.

As for the claim that "the button gets lost" - yes, there's no real quantitative evidence, and going off of questions on Discord is of course biased in many ways. But @scruffynerf is probably the one who deals with the most new users, and while I don't always agree with his opinions on how to actually improve things, I think he has a good understanding of what is currently confusing to new users, and thus what we should at least consider changing.

[cj12312021]

It sounds like we both agree that the Import Metadata button on the toolbar looks odd.

My main goal for keeping import metadata grouped with the other views is to make it available in a way that feels natural and isn't out of sync with everything else. Sure, putting it in the view drop-down wouldn't make it immediately available, but I think new users would still find it very early in their Stash journey.

Whenever we are introduced to a new UI, we all do a bit of exploring to see what is available and what isn't. When a user opens the scene page and sees the views drop-down, they will click and immediately be presented with Import metadata view, which has a very clear meaning.

Some things are hidden in plain sight with the icons in our current implementation, which has yielded the problem new users have been facing.

[scruffynerf]

Once again, I'll just point out that when experienced users think they understand what new users are like, they are often quite wrong. Instead of speculation, maybe you should ask some new users to review your designs, and see (without giving them any guidance what they think. You'll be shocked.

[echo6ix]

I don't think the difference between Import metadata and Import metadata view is significant enough. It adds unnecessary specificity to the label imo. The gist I'm getting is we want to put emphasis on keep it simple and stupid,

On the grid view page: "Hmmm how does this app add metadata to all my stuff? Oh, I see a button label on the toolbar that says Import metadata and accompanying icon that's always associated with stuff to do with importing metadata, lets try clicking that"

On the edit pages: "Oh look, that import metadata button is here again. Maybe that's how I tag my scene from the cloud like that other page. It has the same icon too, lets try clicking that"

It can always be modified going forward if it fails... it's just a button label.

If the issues is new users aren't familiar with how the app works, then a clear onboarding process might do more to familiarize users with the fundamental buttons than any button label will.

Onboarding

This is the only aspect I didn't conceptualize

and so on...

[cj12312021]

Here is a quick mock-up of how the updated toolbar would end up looking. Of course, suggested improvements are welcome. I included the icon by certain buttons so the meaning would be clear when the text is removed on mobile.

[cj12312021]

I don't think the difference between Import metadata and Import metadata view is significant enough.

This is fine. We could remove view from Grid, List, and Wall as well for consistency.

[cj12312021]

Also, regarding the argument to split up import metadata from the other views, consider that only one of those views can be active at a time, which makes it necessary to keep them together unless the suggestion is to make import metadata a toggle that hides the other view buttons when it is active.

[echo6ix]

@Teda1

This is fine. We could remove view from Grid, List, and Wall as well for consistency.

Right, this is kind of how Microsoft File Explorer does it. Specifically, the View label is fixed so it doesn't have to be repeated on the label of each dropdown selection. Only the icon changes depending on the mode selected.

The pushback you'll receive is (1) this concept makes the tagger feature even less prominent than it is now, and (2) tagger should be distinct from the view modes.

But I definitely like the view mode dropdown. Definitely the way to go for view options regardless. If there are ever more view related options added in the future that would be an obvious location to group them without overloading the toolbar with more items.

---

Here is a quick mock-up of how the updated toolbar would end up looking.

Good

• I like the concept of consolidating it all to one row
• Lots of empty space to reduce visual load
• Similar functions are grouped together

Considerations

• To take influence from File Explorer again, you could consolidate the filter buttons into a segmented button
  • Filter button label opens the Edit Filter modal
  • Drop down arrow button opens the saved filter list
  • Consolidating these functions affords the option to group the button with the search bar on the left without making it crowded
    • That provides the option for a tagger (Import metadata) button in the middle, in the scenario where people don't want it to be grouped with the view modes

Cosmetic nitpick

• I know you probably hammered this out very quickly, but more vertical padding between the main nav bar and the toolbar pls :D