Permissions UI, latest experiment

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Permissions UI, latest experiment
« on May 14th, 2013, 08:27 PM »
So those of you following the permissions discussion will know that I've been experimenting with various things, but my last idea didn't work out. So I'm trying something else.

Ignore the fact the wording at the top is wrong. Ignore also that a lot of things should be checked but currently aren't.

The idea is that if a user is allowed to do something, the allow box will be ticked, if it is denied the deny box will be ticked and if they don't have the permission (but aren't denied), neither is ticked.

This works well in other contexts so I don't see why it wouldn't work here for us.

Would appreciate thoughts on it before I spend much more time hacking the template about.

 permissions_2_checks.png - 85.97 kB, 936x914, viewed 214 times.

When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Asgard

  • So Many Searches, Why Have So Many Searches, One Search Is Enough
  • Posts: 56
Re: Permissions UI, latest experiment
« Reply #1, on May 14th, 2013, 08:36 PM »
I'm a big fan of simple, straight forward, easy to use and self-explanatory UI's.

This fits that bill pretty darn well imo. Sure, there's a lot of boxes, but that's because it's controlling a lot of things, much rather have those all in one easy to find and use space than spread out all over the place.

spoogs

  • Posts: 417
Stick a fork in it SMF

icari

  • Posts: 88
Re: Permissions UI, latest experiment
« Reply #3, on May 14th, 2013, 09:57 PM »
Quote from Arantor on May 14th, 2013, 08:27 PM
if they don't have the permission (but aren't denied), neither is ticked.
i think this part may be confusing for some admin, and as a result they would deny everything as the box is there. remember that most admin are not too smart and unless it is clearly stated in many places that if the allow and deny boxes are not checked they dont have any permission they would assume something has to be checked.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Permissions UI, latest experiment
« Reply #4, on May 14th, 2013, 10:11 PM »
I'm not sure it will because remember that a bunch of the checkboxes will be unticked for most permissions for most users out of the box.

spoogs

  • Posts: 417
Re: Permissions UI, latest experiment
« Reply #5, on May 14th, 2013, 10:16 PM »
I only think there "should" to be a facility by which both cannot be ticked at the same time and should minimize potential confusion IMO

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

agent47

  • Now I see the changes you're talking about.
  • Posts: 115
Re: Permissions UI, latest experiment
« Reply #7, on May 14th, 2013, 10:30 PM »
Makes a whole lot more sense when you actually read the words 'Allow' and 'Deny' IMO.
Quote from spoogs on May 14th, 2013, 10:16 PM
I only think there "should" to be a facility by which both cannot be ticked at the same time and should minimize potential confusion IMO
Even though these are tick buttons they act like radio buttons if I'm correct.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Permissions UI, latest experiment
« Reply #8, on May 14th, 2013, 10:31 PM »
No, that's the point. What's in SMF is radio buttons. This is firmly NOT radio buttons (because you need to be able to represent both unticked = disallow which can't be done with radio buttons)

agent47

  • Now I see the changes you're talking about.
  • Posts: 115

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Aaron

  • Posts: 356
Re: Permissions UI, latest experiment
« Reply #11, on May 15th, 2013, 12:31 AM »
Well, I really like the clean looks of it. Personally, I rather liked SMF 1.0's three-way permission system (that is, deny, allow, disallow) in that it was quite intuitive to a programmer. That is, for each permission there was a value on screen. If course, taking 'disallow' out of the picture made the interface more intuitive to every user by just using a checkbox instead (since its value is now just binary).

The only drawback I see here is this: intuitively, looking at the interface, I'd expect to be able to tick both the allow and deny boxes. While that scenario may be prevented via JavaScript or so, to me, it is important that I can understand an interface at first glance. Changing expected widget behaviour does not help in that respect.

I personally tend to think the binary way (that is, one checkbox per permission) is the best approach for all users, making the three-way radio button an advanced option. I realise this is probably a rather conservative view, however...
"The entire British Empire was built on cups of tea … and if you think I'm going to war without one, mate, you're mistaken."

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Permissions UI, latest experiment
« Reply #12, on May 15th, 2013, 12:43 AM »
Quote
I personally tend to think the binary way (that is, one checkbox per permission) is the best approach for all users, making the three-way radio button an advanced option. I realise this is probably a rather conservative view, however...
That is in essence what SMF tried to do in 2.0 - by making deny permissions an optional extra, and by essentially making everything a binary choice by default. I'd argue that's even more confusing that having the three way switch just available by default.
Quote
That is, for each permission there was a value on screen. If course, taking 'disallow' out of the picture made the interface more intuitive to every user by just using a checkbox instead (since its value is now just binary).
Except it was never really binary in the first place, nor was it 'disallow' being taken out of the picture. Previously the choice was allow/disallow (binary) or allow/disallow/deny (tertiary), Essentially what I'm suggesting is *still* a tertiary system, but one that, with some UI hinting, should suggest the actual behaviour involved. Tick allow to allow it, tick deny to deny it from everywhere (aka never) and neither to do nothing with it.

Question: if you can tick both allow and deny, which would logically take precedence? What would you expect it to do if you selected both?

What I will note is that I looked around a bunch of systems and this seems the least unintuitive to me - as in there's no 'best' approach but only a series of 'less worse than...' approaches and this seems to me to be the least worst. The only variation I can think of is to present each permission as a dropdown (been there, done that, you'd be surprised how quickly that gets old)...

Mind you, there is one validity to dropdowns, and that's what I did in SimpleDesk, which was to align own/any in a dropdown, so a permission choice was No, Yes - Own, Yes - Any. Mind you in SD's case I didn't have any UI for denied.
Quote
Changing expected widget behaviour does not help in that respect.
To a point that depends on your expectation. See attached. It's the exact same mechanism, albeit tweaked slightly for other things and without the prior set of having to press Edit to actually configure it. (There is a sort of hierarchy involved. I expect to bring some of that in too.)

Mind you, just consider that it could have been so much worse than this. ;)



Just to clarify: if there are enough objections, I won't push forward with this. I'm aware that this is an important thing to get right and that what I have is still essentially experimental. It may be that it actually needs to be tried in a real environment to get a feel for how well it would really work.

 windows_permissions.png - 33.46 kB, 407x558, viewed 183 times.


xrunner

  • Posts: 192
Re: Permissions UI, latest experiment
« Reply #13, on May 15th, 2013, 01:01 AM »
Quote from Aaron on May 15th, 2013, 12:31 AM
Well, I really like the clean looks of it. Personally, I rather liked SMF 1.0's three-way permission system (that is, deny, allow, disallow) in that it was quite intuitive to a programmer. That is, for each permission there was a value on screen. If course, taking 'disallow' out of the picture made the interface more intuitive to every user by just using a checkbox instead (since its value is now just binary).
I don't even remember deny, allow, disallow in 1.0, so can I ask what the purpose was for three permissions? What's the difference between deny and disallow? :hmm:

spoogs

  • Posts: 417
Re: Permissions UI, latest experiment
« Reply #14, on May 15th, 2013, 02:02 AM »
Based on smf2 (i sure its the same in smf1 but i never usd it)

Allow grants the permission based on a membergroup
Disallow does not grant the permission
* If however  a user is in a group that allows the permission and also in a group that disallows the permission, the permission will be granted via the group that allows it.

If a permission is denied to a group the user is in the permission will be explicitly not granted even if the user is in another group that allows the permission