These are not-as-quick-as-I'd-like-but-definitely-dirty, and are based on our previous discussion about specification and workflows. It's been a while since that post, so I'm making this one for the pictures; in summary, there are two options for how to go about managing this.
In all cases, I should have used "Community control" rather than "Additional Privileges" but I... absolutely could not face going back and editing everything again when I realised, sorry. And in all cases I haven't provided complete lists of privileges/privilege bundles -- those exist in comments on the previous post, and will get put into the final composite spec properly. (I... am being pretty slapdash about this, sorry, but if I try to get everything Just Right at this stage what will actually happen is I'll spend the next six months hyperventilating about how y'all will kick me off the project if I use the wrong font and nothing more will happen, so this is a sketch for the idea of the thing, sorry.)
Also in all cases, there should be another header row under "non-members", but I ran out of steam, see above, sorry.
Option 1: tickbox matrices as far as the eye can see
This is the option laid out in the last post: replace "Administrator" and "Moderator" checkboxes with a "Community Control"/"Additional Privs" box, and an Additional Privs/Community Control page with a bunch of tickies (with "Administrator" acting as a master ticky, though that isn't illustrated here).
/communities/list gets an additional link (with better layout):
Edit Community Members gets a slightly different set of tickboxes:
And we get one new page, giving us a large matrix of tickboxes (which will be paginated, but which probably needs an extra couple of columns to get all the privs bundles in):
Option 2: Define community control roles
This was suggested in comments on the previous post, as a way of creating custom roles/priv bundles as required by the community. In addition to the Additional Privs/Community Control link, /communities/list would then also have "Manage Roles" as an option. Which members were displayed on the Additional Privs/Community Control page would again be controlled by the checkbox so labelled on the Edit Community Members page, as for option 1.
Defining roles ("Manage Roles") is currently envisioned to look like managing filters (nb per introduction this does NOT contain all possible privileges):
The check-box matrix would then be rather more manageable: Further thought is needed about what restrictions should be placed on assigning roles to *all* non-members (as distinct from assigning roles to *specific* non-members, who in the Edit Community Members page would have "Additional Privs" but not "Member" checked, as is currently the case with community admins who are not community members, and so on.)
Documentation
Priv bundles will need explaining. This could happen on-page, in dedicated FAQs, or both. (Probably both.)
... my "something else" is "I wanted to hit submit on the poll so I could see the answers easily and cocked it up by not noticing I'd selected a radio button because I have been staring at this screen for too long", whoops.
I think 2 is better for when communities scale up to many members - Alternity-size stuff probably needs and wants roles that they can assign and define themselves. With a set of useful defaults included that covers most use cases, small communities could also use roles effectively without having to spend time defining them.
I like the idea, where possible, to be able to assign blocks of permissions to roles, such that someone can receive full control over tags without having to assign individually "can add tags", "can edit tags", "can delete tags", "can rename tags".
That said, it still looks like the interface for assigning roles will be option 1, matrices everywhere. If there's a way we can help someone know where they are in the matrix at any given time, perhaps through some form of floating header for each role, I think that would be helpful to avoid mis-assigning roles.
As for assigning roles to non-members, it seems like a thing that should only be changeable by those with the power to change roles (admins and mods, maybe, get that by default), and that anything that involves either the members or non-members group checkboxes has a second page / pop-up saying "O Hai, this affects everyone. You sure about that?" to avoid a mis-assignment by accident.
Hm. Of the two I prefer the matrices, but that's mostly because I'm not a fan of the filter management UI. ISTR that Google Groups permissions settings are impossible to find, but made more sense to me once I found them. Something like:
Can Edit Style: [] Archivist [] Tag-Wrangler [] Administrator
and so forth, with the roles listed under the individual permissions and able to be selected.
^ provided by shortcipher. I think I am going to have to make another poll with this UI vs the filters-style UI; is it clear enough without me actually mocking up a DW-style version, do we think?
(So do I; trying to work out how much of that is because the current implementation of Roles in Google Groups is less how quartzpebble remembered them working. Like, I guess the Manage Roles page - in the Goog-style implementation - could be like the enormous Additional Privileges matrix, with Role names instead of usernames down the leftmost column and a way to add new Role names, but that still hits the issue of "checkboxes as far as the eye can see" aaaaaaand I can totally mock this one up fairly straightforwardly if you like? But basically, screenshot #3 with Role names instead of usernames.)
The more I look at it, the more I like the 'roles' type setup -- I think that will be more usable for people long-term (albeit with a slightly higher setup up-front, but still), and it will be way less overwhelming on the full-membership list, assuming comms only set up a few roles.
Really REALLY glad the screenshots are helpful for you :-)
Roles does make a lot of sense and I am super-glad to the users who suggested them and thrashed them out in comments on the previous post!
If we do it this way we also have (in future) the option of complicating things further/making stuff Yet More Granular, but if you're happy with this set-up and the majority of users are happy with this potential set-up and nothing super ground-breaking comes into comments here, I'm going to try to get this properly specced up (including actual lists of all the priv bundles x_x) and up on GHI byyyyyy early October, say. (And then maybe see if I can't get someone to implement it during the contributor weekend in early November. :-p)
I would really like a way to highlight Powers Not Assigned To Any Role, for troubleshooting/discovery purposes. Perhaps as an autogenerated role which can't be assigned?
So all powers are axiomatically assigned to Administrator; it's never the case that no community-management-human can do a thing. Does that address your concern, or are you specifically thinking that it's useful to suggest to every community that they want non-Administrator roles that cover every privs bundle?
Hmm. So if we go roles-based, every time you create a new role you'll get the full list of priv bundles in the Not In This Role column (and every time you tweak a role, you'll see a list likewise); plus there'll be a list/glossary of priv bundles hopefully both on the page itself (short version) and in a linked FAQ (longer version).
Which is obviously not to say you're wrong! Just that I'm still not quite grokking (which might well be me failing to recognise other's viewpoints because autism etc etc :-p) and it sounds like a fair bit of complexity for a thing I'm Not Grokking? I am perfectly happy to put it in the spec nonetheless if told to!
Ah! I am not thinking in a column in the grid, I was thinking a Not In Any Other Role group in the bundler tool, a group which doesn't show up in the grid.
I think I was unclear? I did mean on the Roles-defining page, and by "column" herein meant the "Role cannot:" and "Role can:" scrollyboxes in the fourth screenshot.
I guess what I *really* want is, some easy way for people to compare the contents of roles and figure out what's overlapping and what's missing. Maybe a third page, or another section?
(This is also probably a good time for me to explicitly mention that while I have Strong Opinions, I only get to make design decisions about spamwhacky stuff, and that's only unless D says different...)
as a User Experience Professional, I can confidently say that Sketch Format Is Great Stuff, to the point that adult people I work with who are getting paid for this go for tools that work up the sketchy qualities to the point of handwritey font/slightly woobly although ultimately straight lines, for the purpose of getting across that This Is Merely A Sketch, Do Not Paint This Bikeshed, to Engineering.
I like the roles approach (think I was one of those who suggested it), but I suspect it's quite a lot more effort to implement, since there's another layer of abstraction. This isn't a quick and dirty "use group filter groups for permissions" bodge. Which is probably a good thing, unless anybody is in a hurry to have this implemented Right Now.
I am intending to get one of the Adams I've dragged into dev to at least get *started* on it during the contributor weekend, on the grounds that I think "company cheerleading and cake" is probably a good place to work from in terms of this ever getting implemented :-) If I can persuade me_and that he's willing to do it I think he'd actually quite enjoy knocking it out, so!
The tickybox assignment of roles looks... dangerous, not so much for these (default?) roles, but in the case where a community defines a lot of different ones (or basically these but with very long names) for whatever reason. That matrix would get wider and wider and no more readable.
No real idea for a solution, just a feeling that drop-downs or a downwardly expanding 'More roles' feature might help.
Issue with dropdowns: Each human wants to be able to have multiple roles, if necessary.
Issue with Roles being listed vertically rather than horizontally: different behaviour to Edit Community Members page, plus current behaviour on ECM page is to have up to 100 users per tickbox-matrix page, and do pagination on the number of users not the number of roles. (This is also how the Manage Circle page works, approximately, albeit with slightly different layout.)
UI people, can you think of a sensible option for "x roles per page"?
(I suppose the other option is instead to duplicate the Manage Roles page again, only this time *actually* treat them like filters -- Roles in the Filters box, then "list of people with Community Control ticked who do not have this Role" versus "list of etc who do", but I think that would have the risk of being confusing and I... would prefer the matrix of tickboxes for my community management purposes, so. Announcing my biases to the world while thinking aloud at you, etc!)
I think that still has the issue on the Additional Privs page (if kept as a checkbox) that if a community designates, say, 20 different Roles, that'll be a very wide matrix. There's the option of putting an arbitrary cap on the number of Roles that can be defined, but honestly I kiiiind of feel like if community administrators want eleventy billion different Roles then to some extent they can deal with that not being presented super gracefully when it comes to assigning them?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
no subject
no subject
no subject
I like the idea, where possible, to be able to assign blocks of permissions to roles, such that someone can receive full control over tags without having to assign individually "can add tags", "can edit tags", "can delete tags", "can rename tags".
That said, it still looks like the interface for assigning roles will be option 1, matrices everywhere. If there's a way we can help someone know where they are in the matrix at any given time, perhaps through some form of floating header for each role, I think that would be helpful to avoid mis-assigning roles.
As for assigning roles to non-members, it seems like a thing that should only be changeable by those with the power to change roles (admins and mods, maybe, get that by default), and that anything that involves either the members or non-members group checkboxes has a second page / pop-up saying "O Hai, this affects everyone. You sure about that?" to avoid a mis-assignment by accident.
no subject
Can Edit Style:
[] Archivist
[] Tag-Wrangler
[] Administrator
and so forth, with the roles listed under the individual permissions and able to be selected.
no subject
no subject
^ provided by
no subject
(I think I like the filters-style UI better, but, hrm.)
no subject
no subject
no subject
Roles does make a lot of sense and I am super-glad to the users who suggested them and thrashed them out in comments on the previous post!
If we do it this way we also have (in future) the option of complicating things further/making stuff Yet More Granular, but if you're happy with this set-up and the majority of users are happy with this potential set-up and nothing super ground-breaking comes into comments here, I'm going to try to get this properly specced up (including actual lists of all the priv bundles x_x) and up on GHI byyyyyy early October, say. (And then maybe see if I can't get someone to implement it during the contributor weekend in early November. :-p)
no subject
no subject
no subject
no subject
Which is obviously not to say you're wrong! Just that I'm still not quite grokking (which might well be me failing to recognise other's viewpoints because autism etc etc :-p) and it sounds like a fair bit of complexity for a thing I'm Not Grokking? I am perfectly happy to put it in the spec nonetheless if told to!
no subject
no subject
no subject
(This is also probably a good time for me to explicitly mention that while I have Strong Opinions, I only get to make design decisions about spamwhacky stuff, and that's only unless D says different...)
no subject
no subject
no subject
This Is Merely A Sketch, Do Not Paint This Bikeshed, to Engineering
is the best formulation of 'this was a discussion, not a decision' I've seen!
no subject
no subject
no subject
No real idea for a solution, just a feeling that drop-downs or a downwardly expanding 'More roles' feature might help.
XWA
no subject
Issue with dropdowns: Each human wants to be able to have multiple roles, if necessary.
Issue with Roles being listed vertically rather than horizontally: different behaviour to Edit Community Members page, plus current behaviour on ECM page is to have up to 100 users per tickbox-matrix page, and do pagination on the number of users not the number of roles. (This is also how the Manage Circle page works, approximately, albeit with slightly different layout.)
UI people, can you think of a sensible option for "x roles per page"?
(I suppose the other option is instead to duplicate the Manage Roles page again, only this time *actually* treat them like filters -- Roles in the Filters box, then "list of people with Community Control ticked who do not have this Role" versus "list of etc who do", but I think that would have the risk of being confusing and I... would prefer the matrix of tickboxes for my community management purposes, so. Announcing my biases to the world while thinking aloud at you, etc!)
no subject
I think we can avoid too-wide columns just by restricting the possible length of role names.
no subject