-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Labels" dropdown UI/UX #77
Comments
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). |
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?) |
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"). |
The single most frustrating thing I've encountered managing the XBlock queue has been the UX on the "labels" dropdown.
The text was updated successfully, but these errors were encountered: