Permissions UI overhaul

[Arantor]

I didn't really know where to put this :/ Anyway, some of you know that I work on an SMF derivative, and one of the things I've been thinking about is permissions, and I want to share the discussion here because I think it's worth considering changes in future SMF versions too. Especially as some of the comments elsewhere prompted me to think there is a problem with the way permissions are arranged.

Whether you like 'simple' or 'classic' permissions, there is one thing never really made clear in SMF's permissions: it can be either two choices (has permission, doesn't have permission) or three (has permission, doesn't have permission, cannot ever have permission)

Or, as SMF calls them, Allow/Disallow/Deny (or A/X/D for short). Other software calls it Yes/No/Never.

I think, honestly, even renaming it from A/X/D would be an improvement, but simple changes aren't really my style.

So I proposed a bigger change, as attached. Instead of one checkbox (for allow/disallow, or yes/no whichever you want to call it) or radio buttons (for A/X/D or Y/N/Never), I thought about two checkboxes, like in Windows.

The idea is that if you tick Allow, they have permission, tick Deny they can't have the permission, tick neither and they don't have it but another group might grant it.

So I wondered what people thought about it here. Obviously there would be proper hinting so that if you tick a box, the corresponding other box would be disabled (tick allow for a permission, you can't then tick deny without unticking allow)

Would it be more logical? Is it worth considering for a future version of SMF perhaps? Or even something more modest (like renaming Allow/Disallow/Deny because some people don't see what the difference between Disallow and Deny is without having to explain it)?

Thoughts on a virtual postcard please.


EDIT: Yes, in case anyone's wondering, I did remove Simple vs Classic and only left Classic. And yes, I know the wording at the top is wrong, that's why it's a mock up and not actual working code.

[Liam.]

I remember that the Allow/Disallow/Deny fiasco left many people confused and still does, including me several years ago. It's logical but the documentation and implementation of that is extremely poor and I do agree that it should be renamed at the very least.

However, I don't think that having separate checkboxes for allow/deny will be needed. I only see the deny being used extremely rarely and don't think there would be a need for much effort to be put into it. Also, when would you ever have both Allow and Deny checked at the same time, as in your mockup? I'm assuming they'd be radio buttons?

[Shambles]

I think it's a splendid idea and offers food for thought.

Also, when would you ever have both Allow and Deny checked at the same time, as in your mockup? I'm assuming they'd be radio buttons?

Obviously there would be proper hinting so that if you tick a box, the corresponding other box would be disabled...

[Arantor]

And no, they wouldn't be radio buttons. I actually explained this already but let's just recap.

Allow ticked = allowed
Deny ticked = cannot have regardless of what other groups they're in
Neither ticked = doesn't have the permission but isn't prevented from another group granting it

If you can tell me how a user can untick a radio button...

[ziycon]

And no, they wouldn't be radio buttons. I actually explained this already but let's just recap.

Allow ticked = allowed
Deny ticked = cannot have regardless of what other groups they're in
Neither ticked = doesn't have the permission but isn't prevented from another group granting it

If you can tell me how a user can untick a radio button...

Should one of these options not always be selected as a default? If so then radio buttons would suffice, unless when you tick one of the three options the other two checkboxes are disabled!?

[Arantor]

Should one of these options not always be selected as a default? If so then radio buttons would suffice, unless when you tick one of the three options the other two checkboxes are disabled!?

-sigh-

How many people have no idea what SMF does? Or indeed actually read what I'm saying


OK. Admin > Members > Permissions > Settings > Enable deny permissions

Now look at the permissions page. It has 3 radio buttons.


I'm proposing replacing those three radio buttons with two checkboxes which between them represent all three states.

* Arantor realises it was a waste of time suggesting this here.

[ziycon]

Should one of these options not always be selected as a default? If so then radio buttons would suffice, unless when you tick one of the three options the other two checkboxes are disabled!?

-sigh-

How many people have no idea what SMF does? Or indeed actually read what I'm saying


OK. Admin > Members > Permissions > Settings > Enable deny permissions

Now look at the permissions page. It has 3 radio buttons.


I'm proposing replacing those three radio buttons with two checkboxes which between them represent all three states.

* Arantor realises it was a waste of time suggesting this here.

Ok, so I miss read you post slightly, relax, no need to assume your wasting your time. Some people breeze over posts due to being in work and only getting bits of the post, now back on topic.

Yes, would be my answer. Initially when I started with SMF i found the permissions system quite confusing but with time I've become accustomed to how it works. I feel the same as you've stated regarding replacing the 3 options with two checkboxes and the default value if neither are ticked along side the renaming.

[Arantor]

Ok, so I miss read you post slightly, relax, no need to assume your wasting your time.

Trust me, I am on this one. It's confused more people than those who actually 'got it'.

I feel the same as you've stated regarding replacing the 3 options with two checkboxes and the default value if neither are ticked along side the renaming.

How did you come to that conclusion from the screenshot I posted, exactly?

[Kays]

The idea is that if you tick Allow, they have permission, tick Deny they can't have the permission, tick neither and they don't have it but another group might grant it.

Nah, it's too simple and almost makes sense.

Actually I like the idea. One of the confusing issues for a new forum admin is realising that permissions are inherent. And then there's that damn warning which shows if you enable "Deny". I never could understand that since I think that Deny should be enabled by default.

This way everything is out front and as long as Deny trumps the other permissions it should be easier to understand for a new forum admin than the way it's done currently.

[ziycon]

Ok, so I miss read you post slightly, relax, no need to assume your wasting your time.

Trust me, I am on this one. It's confused more people than those who actually 'got it'.

If that's the case you kind of answered your own question. It more-so warrants a change to make it easier for new users as well as accustomed users of SMF.

[Arantor]

Which is exactly what I'm proposing but the amount of effort it's taking me to explain it to SMF veterans is prohibitive. I'd rather stick with what we have which is at least understood by some people already.

Though as I said on wedge.org, I don't really see keeping SMF permissions as an option. Just means I need to think outside the box some more.

[emanuele]

Dunno, dunno.
Yes the three radio are meh, though also the two checks don't convince me either...

Drop down with: Allow, deny, let someone else decide?

mmm...why do we need to see in a page the permissions only for one group?
A column on the left with all the groups, a "column" on the right with all the permissions subdivided like now in collapsible boxes. Drag&drop of permissions from right to left and back.
One page to grant permissions, one to deny them.

Of course that would need some trick to "hide" (and show ) the permissions for the various groups.

[Arantor]

mmm...why do we need to see in a page the permissions only for one group?

Mostly it's a practicality thing in terms of not flooding $context with a lot of stuff. (cf the comments in the reporting area about taking up a lot of memory)

I will note that I did also experiment - somewhat unsuccessfully - with presenting it as one large table, permissions down the left, groups along the top, making it scrollable like an Excel spreadsheet, but even if I had gotten the table scrolling stuff working properly (which I didn't), it was still very cluttered and oppressive.

What you're proposing could work, dunno. It's an interesting idea. Not sure how practical it would be to have allow/deny handled too... I do know that we discussed it at Wedge and came to the conclusion that dropping deny entirely isn't an option.

[Irisado]

Having just enabled the deny permissions option, I can now see what you're referring to.  Yes, it does look a bit messy, although I do see a difference between disallow, and deny in terms of their meaning, so I don't find the terms that confusing.

Ideally though, I agree, that a system of two checkboxes, as per your proposal, would be more elegant, and easier for most people to follow.

[bloc]

Rather than presenting everything at once though, one could look at it at different angles - I did some drafts of looking at permissions from a membergroup-based view/permission-based view and board view a couple of years back. Looking back at it now, that might work - with adjustments.

http://www.simplemachines.org/community/index.php?topic=411039.msg2870973#msg2870973

About 2 columns of allow/deny..IMHO it only confuses having them both present, as its not as simple as it may seem. For myself I never used the deny option, but I have missed the option to quickly see what a specific group might see.

Expanding upon those drafts I did, one could even do a breakdown of the permissions of all custom groups set for a specific member only. So it would be "by membergroups", "by permissions", "by boards" and.. "by members". I am not sure how it would perform, but one could then build a simple map of a member on how the groups give him/her permissions outside of the his/hers main membergroup.

Probably needs to be drafted to get the idea lol.

[Arantor]

Not everyone can see that, Bloc, though I remember the discussion well, because the suggestion started out with someone (SleePy?) suggesting to go down the road SimpleDesk did.

[bloc]

Ah, I forgot. I'll attach the drafts.

[Arantor]

Oh, I still have at least one picture you mocked up, been studying it along with various other screenshots of various systems and trying to figure *something* out...

[bloc]

Its not an easy task - to make something thats easy to work out, and at the same time improves upon current. Instinctively I feel that having the overview is somewhat better than in and out of smaller screens - you lose soon what was set and where. Thats why I went that route, with showing it differently, for different scenarios.

Of course one could also build in some logic, like when viewing a membergroups permissions, also put a notice of what other groups have the same permissions..or if using profiles, list in a compact form what exactly that profile have(so you don't have to go into profile screen to get it). Also, profile screen should look quite different than the permissions screen and board permission screen - if only by a visual background/icon etc. Right now only the header says something about where you are. I find that too easy sometimes, to set something in the "wrong" screen.

[Arantor]

Oh, it's not an easy task at all! I personally think of the profile area separately to the main group permissions for the simple reason that it has a different job to do.

What does occur to me, actually, is that as you've suggested, there should be the ability to flip the view between permissions -> groups that hold them, and groups -> permissions they have. There is even precedent for this in SMF itself; from each board you can see the groups which can enter it, from each group you can see the boards they can enter, and this is a good candidate for the same treatment.

I actually have a sort of idea about trying that, so that groups->permissions might look much as the current one does, but there is also a permissions->groups view. It might not be pretty but it might work out alright.