"Labels" dropdown UI/UX

[aendra-rininsland]

The single most frustrating thing I've encountered managing the XBlock queue has been the UX on the "labels" dropdown.

1. On mobile it's like a 3-tap interaction just to make the labels field visible and focused. Is it possible for the field to always be visible, maybe placed near the existing labels so it feels like more of a Tumblr-esque "tags" style of interface?
2. Most 3rd party labelers don't care or can't use most of the options in the "Labels" drop down, they only care about the labels they define in their service record. Most items in the dropdown should be hidden by default. If nothing else, the custom labels should be moved to the top of the list so they don't need to use the search field.
3. The category labels in the dropdown are pretty superfluous and use a lot of vertical real estate
4. The search field uses a lot of vertical screen real estate and is less necessary if only custom labels are show by default.
5. There's no way to focus the labels dropdown without clicking on desktop. Tabbing to it is useless, because doing so and typing a label name causes the other keyboard shortcuts to fire, possibly hiding the label dropdown again.
6. The initial interaction with the field is currently always useless, there's nothing usable in this screen for me without scrolling or searching. Improving that will do a lot to improve moderator efficiency.

[baatl]

I don't think it'd be going to far to say that there's a broad consensus around this among the operators of moderation services emerging right now, that the biggest shortcoming of Bluesky's labeling system as currently designed is its overfocus on the idea of labelers providing the same types of moderation as the Bluesky Moderation Service.

In general, both Ozone and the in-app reporting flow ought to be largely rethought around the idea of labeling services that fill in each others' gaps, much more than services providing a redundant effort to BMS (even Aegis's labels often don't clearly overlap with Bluesky's upstream definitions.)

While I do understand the thinking behind letting labelers offer a "second opinion" (or "second-guess") of each other, I believe that ought to be significantly de-prioritized in the UX both for Ozone and bsky.app, and the overall priorities of the underlying design considerations should be reoriented around better facilitating these differences between services (for instance, letting labelers specify their own reporting flows).

[baatl]

But yes, a big part of that is that there's way too much of a focus in the design of Ozone's current UX around the bureaucratic structure of Bluesky's mod team: rather than the action panel starting with a dropdown listing nine different possible actions (roughly eight of which I will never use), it would make more sense to present a button for every label my service provides (with maybe some kind of grouping, once that concept is surfaced in the design), plus another button for "Punt" that opens the dropdown of Acknowledge vs Escalate vs Comment vs Divert vs Appeal vs Takedown/Mute/whatever (do community labelers even have the ability to issue takedowns?)

[baatl]

Having just reviewed the user guide, I'd like to dial back some of what I said about the set of actions being "too bureaucratic": I still think there are problems with how flat the UX of the dropdown is (and could probably produce a mockup of a more natural arrangement/flow), and that Takedown/Divert/Email ought to be disabled if the service isn't configured to take those actions, but I do appreciate the ability to file tags/comments, and the distinction between Unresolved/Escalated/Acknowledged (though I think this should be presented more like a radio state attached to submitting a potentially-empty comment than three different types of "event").