So, I've been noodling around with this, and nothing I'm happy enough with to provide screenshots of yet, but let me explain where I'm going and see what you think.
There are a great many issues with the permissions UI and structure.
First up, regular group permissions. I'm still working with what I proposed in http://wedge.org/pub/feats/7662/permissions-ui/ - namely a single big table with all the groups along the top, the permissions down the side, and all the permissions shown there.
There are several bits I'm not entirely sure about, like exactly how you set the permissions. I don't really want to present a minefield of buttons to the user, nor do I want to present a minefield of <state> <button to change> Maybe I'll have it click to change the permissions for a given group <-> permission, but that could get clunky if there's a lot of changes you want to make. Maybe it should be a dropdown for each one to select the state.
This makes me wonder other things. I'm not averse to exposing 'deny' permissions generally. However, what I am concerned about is the mentality. A/D/X is confusing. Elsewhere (board access) we use Yes/No/Never to represent that states, and we need to get a bit more consistent - I'd be happy dragging Yes/No/Never over to permissions too.
Another system I'm liking has two checkboxes, rather than radio buttons - one for allow, one for deny.[1] I'm not sure what I'm going to do yet, would appreciate thoughts.
Note that I'm looking to remove the 'default profile' being shown underneath the general permissions, but the whole nature of that I'll get to in a minute. I would also be tempted to remove some of the other stuff in the admin pages, like 'setting permissions for one group like another' - basically if you go to the permissions page, you get the list of groups, then some stuff below those groups for things you can apply to the groups; setting 1+ groups like a template, setting a single permission on each of the ticked groups. Seems to me that a single big ol' list would negate the need for that. Permission copying would be reasonably simple too.
There was a concern previously about fitting it all in - while this is not a huge deal for the most part (inherited groups wouldn't be shown either, to save space), I'm also looking at using http://fixedheadertable.com/ - you'd keep the group names and the permissions in view at all times and scroll across to fit.
I don't think there was any real objection, but I think now I'm looking at it again, I'm having second thoughts on the idea - but I also know I don't have anything better to solve the problems I want to solve. I don't want to get into huge scale re-engineering if the idea doesn't feel sound, and right now this doesn't.
Board permissions. Ah, yes, I couldn't forget this, could I? I've been looking at what SMF 1 did versus SMF 2, unique board permissions vs profiles and I think I might have a better solution but this is sort of off the cuff. If I said it came to me while I was sat on the toilet[2] you'll hopefully understand.
So, let's recap, first of all.
SMF 1, for those who never used it, had the notion of global versus local board permissions. You'd set the permissions for each group generally, and if you had a board whose permissions were different, you could indicate as such and get unique permissions for that board.
Conceptually that's fine, until you have two or more boards that need the same-as-each-other but unique-compared-to-everything-else permissions. Incidentally, sm.org has this very setup, there are boards that have different permissions to any other (namely showcase, but some of the internal boards have that going on too)
Meanwhile, SMF 2 has the idea of profiles. You have some template profiles (but one you can actually change despite the system telling you that you can't, which I'm still not sure isn't a bug in disguise), and you create new profiles to apply them to the relevant boards. Great for managing boards with a few tiers of boards where you only have a few sets of 'permissions'.
Then we have SimpleDesk. This did something a little bit different: permissions were expressly not tied to groups. You create roles, which are essentially groups of permissions, then you say 'these groups, have these permissions, in these boards'. For example you'd create a staff role, which had a bunch of permissions, and all the time they were in those boards, they had those permissions. It was a bit ropey in places because I abused the concept in two interesting ways.[3]
Two options present themselves, ultimately.
Firstly, I can take the SD route. The UI can be nicer this time because I don't need to pull stunts around 'non board permissions', I can safely have the UI abstract that stuff away. But I'm not sure how well the 'groups != roles' concept will get across and I'd hate to lumber us with 'how do I set this permission up' crap.
Secondly, and perhaps more confusingly in a way. I can sort of regress back to SMF 1 permissions. I'd envisage it being split between permissions and the board configuration area, or at least... mirrored that way.
See, what I'd envisage doing is giving a list of the board type permissions, and the groups again - like above. Only this time, with an extra dimension to it. For each permission, you'd select the list of groups who have it/don't have it, but there's an extra option: apply to all boards. If you say 'apply to all boards', all the boards the users can see would be able to have/not have that permission. For example, posting replies would typically be yes to any group who can see the board in question. So you'd just have that as 'all boards', and just set it to the groups who reply.
If you decided you didn't want it as all boards, I'm thinking that the list of boards could fold out underneath to indicate that permission for that board/group combination. I think it could be thoroughly ugly, but I think it would be more intuitive than the current permissions setup.
Then you could go into a given board and see how it is in that given board, and configure it that way too. It would be back to local vs global permissions but easier to configure for simple changes. Of course if you have a lot of boards, changing things is going to suck very, very quickly, which is where profiles win.
More importantly, newbie factor. Setting up roles is not the most obvious thing, especially if you want people to be able to dive in and just set up a forum quickly, though I guess if sane roles were defined out of the box, that might not be a bad thing and it would probably clue most of them in on how to do it. But seeing the confluence of boards/groups/permissions should be marginally easier to follow - and still more compact than the current reporting methodology (which could also go bye-bye in the process)
Note that all the things I have in mind down the road about other content types can slot into what we have here with little change on a purely technical level, so this is almost entirely a UI problem. UI says it must be so, everything else will be kicked into line.
I don't know. I honestly don't know what's best out of all this. I just know that I don't like how SMF does it and by extension how we do it. I've been wary for some time of making big changes because I've been frightened of creating a worse mess than we already have. But I'm also not sure it can be *that* much worse. So, over to you. I'd love some thoughts on this, even if it's only to tell me whether you like or dislike it. Remember: you're the people who are ultimately going to be *using* it.
Of course, I'm open to other ideas. If there's any other system you've seen that you like the look of, tell me and I'll see what I can do to find out about it, including figuring out what's good about it. I'm not averse to drawing on any system out there - if the system works, I want to see it :)
There are a great many issues with the permissions UI and structure.
First up, regular group permissions. I'm still working with what I proposed in http://wedge.org/pub/feats/7662/permissions-ui/ - namely a single big table with all the groups along the top, the permissions down the side, and all the permissions shown there.
There are several bits I'm not entirely sure about, like exactly how you set the permissions. I don't really want to present a minefield of buttons to the user, nor do I want to present a minefield of <state> <button to change> Maybe I'll have it click to change the permissions for a given group <-> permission, but that could get clunky if there's a lot of changes you want to make. Maybe it should be a dropdown for each one to select the state.
This makes me wonder other things. I'm not averse to exposing 'deny' permissions generally. However, what I am concerned about is the mentality. A/D/X is confusing. Elsewhere (board access) we use Yes/No/Never to represent that states, and we need to get a bit more consistent - I'd be happy dragging Yes/No/Never over to permissions too.
Another system I'm liking has two checkboxes, rather than radio buttons - one for allow, one for deny.[1] I'm not sure what I'm going to do yet, would appreciate thoughts.
Note that I'm looking to remove the 'default profile' being shown underneath the general permissions, but the whole nature of that I'll get to in a minute. I would also be tempted to remove some of the other stuff in the admin pages, like 'setting permissions for one group like another' - basically if you go to the permissions page, you get the list of groups, then some stuff below those groups for things you can apply to the groups; setting 1+ groups like a template, setting a single permission on each of the ticked groups. Seems to me that a single big ol' list would negate the need for that. Permission copying would be reasonably simple too.
There was a concern previously about fitting it all in - while this is not a huge deal for the most part (inherited groups wouldn't be shown either, to save space), I'm also looking at using http://fixedheadertable.com/ - you'd keep the group names and the permissions in view at all times and scroll across to fit.
I don't think there was any real objection, but I think now I'm looking at it again, I'm having second thoughts on the idea - but I also know I don't have anything better to solve the problems I want to solve. I don't want to get into huge scale re-engineering if the idea doesn't feel sound, and right now this doesn't.
Board permissions. Ah, yes, I couldn't forget this, could I? I've been looking at what SMF 1 did versus SMF 2, unique board permissions vs profiles and I think I might have a better solution but this is sort of off the cuff. If I said it came to me while I was sat on the toilet[2] you'll hopefully understand.
So, let's recap, first of all.
SMF 1, for those who never used it, had the notion of global versus local board permissions. You'd set the permissions for each group generally, and if you had a board whose permissions were different, you could indicate as such and get unique permissions for that board.
Conceptually that's fine, until you have two or more boards that need the same-as-each-other but unique-compared-to-everything-else permissions. Incidentally, sm.org has this very setup, there are boards that have different permissions to any other (namely showcase, but some of the internal boards have that going on too)
Meanwhile, SMF 2 has the idea of profiles. You have some template profiles (but one you can actually change despite the system telling you that you can't, which I'm still not sure isn't a bug in disguise), and you create new profiles to apply them to the relevant boards. Great for managing boards with a few tiers of boards where you only have a few sets of 'permissions'.
Then we have SimpleDesk. This did something a little bit different: permissions were expressly not tied to groups. You create roles, which are essentially groups of permissions, then you say 'these groups, have these permissions, in these boards'. For example you'd create a staff role, which had a bunch of permissions, and all the time they were in those boards, they had those permissions. It was a bit ropey in places because I abused the concept in two interesting ways.[3]
Two options present themselves, ultimately.
Firstly, I can take the SD route. The UI can be nicer this time because I don't need to pull stunts around 'non board permissions', I can safely have the UI abstract that stuff away. But I'm not sure how well the 'groups != roles' concept will get across and I'd hate to lumber us with 'how do I set this permission up' crap.
Secondly, and perhaps more confusingly in a way. I can sort of regress back to SMF 1 permissions. I'd envisage it being split between permissions and the board configuration area, or at least... mirrored that way.
See, what I'd envisage doing is giving a list of the board type permissions, and the groups again - like above. Only this time, with an extra dimension to it. For each permission, you'd select the list of groups who have it/don't have it, but there's an extra option: apply to all boards. If you say 'apply to all boards', all the boards the users can see would be able to have/not have that permission. For example, posting replies would typically be yes to any group who can see the board in question. So you'd just have that as 'all boards', and just set it to the groups who reply.
If you decided you didn't want it as all boards, I'm thinking that the list of boards could fold out underneath to indicate that permission for that board/group combination. I think it could be thoroughly ugly, but I think it would be more intuitive than the current permissions setup.
Then you could go into a given board and see how it is in that given board, and configure it that way too. It would be back to local vs global permissions but easier to configure for simple changes. Of course if you have a lot of boards, changing things is going to suck very, very quickly, which is where profiles win.
More importantly, newbie factor. Setting up roles is not the most obvious thing, especially if you want people to be able to dive in and just set up a forum quickly, though I guess if sane roles were defined out of the box, that might not be a bad thing and it would probably clue most of them in on how to do it. But seeing the confluence of boards/groups/permissions should be marginally easier to follow - and still more compact than the current reporting methodology (which could also go bye-bye in the process)
* Arantor does not normally want much in the way of external validation, but this is a *big* thing to get right and I want to involve everyone as much as possible because it's also one of the most fraught areas of setting up a system.
Note that all the things I have in mind down the road about other content types can slot into what we have here with little change on a purely technical level, so this is almost entirely a UI problem. UI says it must be so, everything else will be kicked into line.
I don't know. I honestly don't know what's best out of all this. I just know that I don't like how SMF does it and by extension how we do it. I've been wary for some time of making big changes because I've been frightened of creating a worse mess than we already have. But I'm also not sure it can be *that* much worse. So, over to you. I'd love some thoughts on this, even if it's only to tell me whether you like or dislike it. Remember: you're the people who are ultimately going to be *using* it.
Of course, I'm open to other ideas. If there's any other system you've seen that you like the look of, tell me and I'll see what I can do to find out about it, including figuring out what's good about it. I'm not averse to drawing on any system out there - if the system works, I want to see it :)
| 1. | If allow is ticked, it's A, if deny is ticked, it's D, if neither are ticked it's X, letters for our current parlance. Oh, and you can't have both ticked at once. It actually works rather well on Windows for file permissions. |
| 2. | And how much thinking really gets done there, eh? |
| 3. | Firstly, I created non-board permissions using the same concept, except for 'board 0' being the board in question. Secondly, there are implicit permissions embedded into the roles, for accessing the helpdesk, being staff and being a helpdesk admin, they were ingrained into the role 'templates' that you had to build from. Kludgy but it worked, in fact in hindsight I think it worked better than I guessed. |
