Wedge

Public area => The Pub => Features => Topic started by: Arantor on May 14th, 2013, 08:27 PM

Title: Permissions UI, latest experiment
Post by: Arantor 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.
Title: Re: Permissions UI, latest experiment
Post by: Asgard 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.
Title: Re: Permissions UI, latest experiment
Post by: spoogs on May 14th, 2013, 09:10 PM
I like it too. It's simple and looks straight forward enough to me.
Allow yes or no
Deny yes or no
Title: Re: Permissions UI, latest experiment
Post by: icari 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.
Title: Re: Permissions UI, latest experiment
Post by: Arantor 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.
Title: Re: Permissions UI, latest experiment
Post by: 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
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 14th, 2013, 10:29 PM
Yup, that was already planned ;)
Title: Re: Permissions UI, latest experiment
Post by: agent47 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.
Title: Re: Permissions UI, latest experiment
Post by: Arantor 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)
Title: Re: Permissions UI, latest experiment
Post by: agent47 on May 14th, 2013, 10:36 PM
Oh right, I just realized there were three functions: Allow, Disallow and Deny.
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 14th, 2013, 10:37 PM
Yup, in SMF there are. There aren't here. ;)
Title: Re: Permissions UI, latest experiment
Post by: 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).

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...
Title: Re: Permissions UI, latest experiment
Post by: Arantor 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.
Title: Re: Permissions UI, latest experiment
Post by: xrunner 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:
Title: Re: Permissions UI, latest experiment
Post by: spoogs 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
Title: Re: Permissions UI, latest experiment
Post by: xrunner on May 15th, 2013, 02:19 AM
Quote from spoogs 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
I'm not sure what exactly to say next ... :huh:

Thanks for your reply, and I read it several times before I was sure I understood it. I do understand what you are saying, but you also said "Based on smf2 ..."

I looked at the permissions (I've looked at them and set them for years but looked again) and I do not see "allow" "disallow" and "deny" in the permissions or any implication that they act like you are describing. All I see is a check box that is either checked or not checked for the permissions. Is there some underlying scheme I've never understood all these years that I need to be aware of, or are we just talking on two completely different levels (me being on the lowest level I'd guess :)).

Thanks.
Title: Re: Permissions UI, latest experiment
Post by: spoogs on May 15th, 2013, 02:22 AM
In smf2 you have to enable deny permissions to see it.
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 15th, 2013, 02:24 AM
For example you might set up a troublemakers group and use that to revoke all kinds of permissions regardless of other groups they are in (except admins), so you could use it to remove their ability to send PMs or even to remove their ability to post in specific boards by way of this permission.

I find it very interesting that people are considering this 'deny' power as a new thing because that's exactly why I wanted to change it. It's so inobvious how you find it or use it as it stands.
Title: Re: Permissions UI, latest experiment
Post by: xrunner on May 15th, 2013, 02:25 AM
Quote from spoogs on May 15th, 2013, 02:22 AM
In smf2 you have to enable deny permissions to see it.
Ah. I see it in the settings menu. I guess I never touched it because of this message -

Use with care, a denied permission will stay denied no matter what other membergroups the member is in.

Every time I see a software message that begins with "Use with care ..." it scares the shit out of me. :)

Thanks for the information though.
Title: Re: Permissions UI, latest experiment
Post by: Dragooon on May 16th, 2013, 09:53 AM
Instead of "Deny", perhaps "Revoke" will be more clear? Otherwise it's looking pretty good!
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 16th, 2013, 03:35 PM
Given the feedback I've had here, that I've had on sm.org and the feedback I've had privately, I don't really see any point continuing with this, it's just proving to confuse people more than the messed up system we already had.

Though I have one change I won't be reverting, and that's to remove the option for deny permissions - as in they will always be enabled in future, so then it's just trying to salvage the wreckage of what we have.
Title: Re: Permissions UI, latest experiment
Post by: spoogs on May 16th, 2013, 04:03 PM
I honestly do not see how it is confusing. I do get that no matter what someone will find a way to be confused, but I think explaining how it works is rather simple as well. All I see happening is something along the lines of:
Issue
I use to use SMF (or some other system) the permissions for Wedge is different to me, how does it work?

Resolve
To allow a group to have a certain permission check the box to allow the permission. Leaving the box unchecked will not grant the members of a group this permission. Do however note that if a user has multiple groups where at least one group allows the permission and at least one group disallows the permission, the permission will be granted via any group that allows it[1].

If you want to explicitly ensure that a group will not have a certain permission check the box to deny the permission. Denying the permission will ensure that users in this group will not have this permission even if it has been allowed by another group the user has[2].

Heck I think those explanations can even be plugged in next to Allow and Deny with the help icon. I'm also certain by assumption things like this will be documented anyway. I highly doubt there will be a solution that fits the bill as not being confusing to someone. I even strongly believe using the illustrated iteration will prove less confusing than reading it. I'm curious to see where the ideas go from here though.
 1. I dont think this is anymore confusing than even SMF already has to explain
 2. This is way less confusing than the explanation required in SMF, where one must first go and enable deny permission
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 16th, 2013, 04:06 PM
The difficulty I'm having explaining this to SMF veterans is staggering ;)
Title: Re: Permissions UI, latest experiment
Post by: spoogs on May 16th, 2013, 04:14 PM
Frankly I think that's just trumped up to I don't like change, albeit for the better. So whats the solution there, keep what SMF has?

Keeping the current illustration in mind the only thing I see simpler is as u stated the drop down a'la SD Allow/Disallow/Deny. I mean those are the 3 options just a matter of how its presented right.
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 16th, 2013, 04:18 PM
Oh, keeping what SMF has is not really an option in my mind. Just means I need to go back to the drawing board again.

The problem with SD type dropdowns is that there is not really any scope for deny permissions in there - in SD's case that was intentional (the code supported it but the UI never did because I never saw any *need* for it there and my take on it appeared to have been validated)

However I see deny permissions in the main forum as a necessity on some level, e.g. for a troublemakers group, and then it becomes a game of presentation.
Title: Re: Permissions UI, latest experiment
Post by: spoogs on May 16th, 2013, 04:42 PM
As far as SD I just meant the style. Looking at SMF's A/X/D, i was of the assumption that could be presented 'somewhat easily' as a dropdown.

Still a little sleepy so we might be saying the same thing here and I'm just not noticing.
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 16th, 2013, 04:52 PM
Well, the A/X/D part could be, but one of the big things I did - and damn it was subtle - was flattening the way own/any permissions worked.

In SMF and Wedge, you can quite happily grant/revoke own/any permissions separately, though the cases should be fairly rare that you'd ever need to. In SD, though, the permission choice doesn't exist like that.

A normal permission in SD is 'allow/disallow', an own/any permission in SD is 'allow own/allow any/disallow either' without any option for denying, on the basis that if you have 'any', you implicitly have 'own' as well.

Now, history has shown that my call on that made sense for SD: because own/any in SD terms made sense, the permission model made it feasible and approachable to build inclusive setups without getting into a need for deny permissions. If everything is off by default for everyone you have to give them things.

SMF's more general permissions are a lot more inclusive by default, so there is a sort of need to make things more exclusive through deny permissions, plus of course cases like the aforementioned troublemaker group.

That said... I'd actually probably be more inclined to extend the warning system and do it *that* way rather than juggling permissions. After all... why do people normally create deny groups in the first place? What purpose do deny groups actually solve?

Well, they're for excluding people from doing things they would normally otherwise be able to do. So the question then becomes: why are they not allowed to do what they're otherwise able to do?

The logical answer to me about that is warnings/punishments/<insert terminology of choice>. So if you tie it into the warning system instead of the general permissions system, you don't actually *need* deny permissions, right?
Title: Re: Permissions UI, latest experiment
Post by: Kindred on May 16th, 2013, 05:11 PM
I like this concept...

Actually, I find the deny group useful - and not just for trouble makers....

because of the "all members" group and the inclusive way that smf does permissions, I have some groups (especially post-count groups)set to DENY access to functionality.
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 16th, 2013, 05:18 PM
Wouldn't you instead grant that access by giving it just through the higher groups?

Or even just set a minimum and/or maximum post count for a given permission?
Title: Re: Permissions UI, latest experiment
Post by: spoogs on May 16th, 2013, 05:24 PM
@Arantor

I get ya. In reference to your last point:

I do my level best to have the fewest amount of groups possible and very few member that end up in multiple groups (but it does happen). Most groups are requestable and each of these groups has their own board. What I did for my sanity was to create a permission profile for each group that has a board such that for Group1 there is a board permission called Group1. Each group decides which other groups they allow to access their board and what those users can do in that board. In some situations I have used deny permissions to ensure that a group cannot do something undesired on another group's board. Not necessarily a punishment.
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 16th, 2013, 05:28 PM
Hmm, yes, I can see what you mean.

So, deny permissions are needed, then.

/megoes back to thinking.
Title: Re: Permissions UI, latest experiment
Post by: spoogs on May 16th, 2013, 05:43 PM
Indeed
Title: Re: Permissions UI, latest experiment
Post by: live627 on May 17th, 2013, 12:13 AM
Quote from Arantor on May 16th, 2013, 03:35 PM
Given the feedback I've had here, that I've had on sm.org and the feedback I've had privately, I don't really see any point continuing with this, it's just proving to confuse people more than the messed up system we already had.
What, really? I see only one reason as to why they're confused[1] They are too used to the three radio buttons. It certainly makes sense from a developer's standpoint, but the average joe sixpack will see the "X" as superfluous.

How did Windows do it ever since the good old days of NT? Exactly as you propose to change it to, with the two checkboxes!

Follow your instincts. Do what's right. People will adapt and change their mindset.


...maybe some visual cue is called for here. Background colors, green fur allow (make it bluish green for the color blind[2]) and red for deny.
 1. I mean, come on guys, really?
 2. ever wonder why green  traffic light have a  blue hint?      So the color blind see blue, and not gray
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 17th, 2013, 12:38 AM
Yes, really. Most of the people I've spoken to are confused about the very existence of deny permissions because it's off by default. Thus permissions are a simple yes/no checkbox, not even the three radio buttons.

Thing is, even back to SMF 1.1.x, deny permissions are off by default so there is a whole heritage of 'it's just yes/no tickboxes' to deal with.

The reality, though, is that I haven't seen a single forum system doing it the way I proposed, they all do either yes/no or A/X/D triad (except XenForo in one specific circumstance but that's a battle for another day)[1]
Quote
It certainly makes sense from a developer's standpoint, but the average joe sixpack will see the "X" as superfluous.
Well, it all came about because of the very fact that Disallow and Deny seem awfully close together. Hell, even just renaming it to Yes/No/Never would be an improvement.

Yup, Windows did it the way proposed, and it was in fact a guy who does a decent amount of Windows sys-admin that suggested it to me (you know who you are), and it makes sense.

I tell you what though, my instincts on this are simply that *I* wasn't that convinced by it, which is why I posted it here under the label of 'experimental' because I'm not entirely convinced it's the way forward. It's *a* way forward, and the split is roughly 60/40 against judging by all the comments. It's probably better than what we have to an objective observer.

But I keep coming back to the objection Aaron raised - which comes down to the concept of form-follows-function. And he's right, even with UI hinting, even if I disable one checkbox when the other is ticked, it doesn't change the fact that it isn't what checkboxes are really for. It's not form following function.
Quote
make it bluish green for the color blind
Until you meet my mother who is blue-green colour blind ;)
 1. Specifically, they set up a default permission profile for boards that isn't tied to any one board, then each board is allow/disallow/deny/inherit from the default profile. But it's still radio buttons.
Title: Re: Permissions UI, latest experiment
Post by: Farjo on May 20th, 2013, 02:35 AM
"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?"
I would expect it to deny, as deny overrides all allows.

It's like a night club within which are many parties, all with their own invite list. If your name's on a list then you can get into the club. If your name is not on a list it means nothing - your name could be on a different list or it may be on none. However if you've been banned from the club then you won't get entry no matter how many lists your name's on.

So I agree with you getting rid of Disallow. Disallow is 1. not distinct enough to Deny to be clear and 2. misleading, because it doesn't disallow, it just doesn't allow. It's neutral, it does nothing.

"Well, it all came about because of the very fact that Disallow and Deny seem awfully close together. Hell, even just renaming it to Yes/No/Never would be an improvement."
Essentially what you have with your screen is Yes/Never/Neither - the latter being when both are unticked, and it's a truer representation of what's actually going on.

All your screen really needs is a good explanation at the top. And people who've never before seen Deny will assume it's new Wedge functionality :)
Title: Re: Permissions UI, latest experiment
Post by: Arantor on May 31st, 2013, 05:45 PM
Tell you one thing about the way IPB does its permissions - by separating permissions and groups the way it does, it reminds me of SimpleDesk and it sort of validates the concept of having roles vs groups.
Title: Re: Permissions UI, latest experiment
Post by: godboko71 on June 1st, 2013, 07:10 AM
Quote from Arantor on May 31st, 2013, 05:45 PM
Tell you one thing about the way IPB does its permissions - by separating permissions and groups the way it does, it reminds me of SimpleDesk and it sort of validates the concept of having roles vs groups.
Several CMS's do it that way as well.
Title: Re: Permissions UI, latest experiment
Post by: Arantor on June 1st, 2013, 12:12 PM
I think it's essentially encouraging me to go to town and not be too concerned about keeping compatibility in the converter.
Title: Re: Permissions UI, latest experiment
Post by: godboko71 on June 1st, 2013, 11:49 PM
As long as the data is their does it really matter if we have to reset perms. Seems if one is moving to a new platform people should be expected to have to reset settings.