Previous Entry Share Next Entry
Should Members of a Space have Edit rights by default?
jducoeur wrote in querki_project
Okay -- here's one that doesn't have a clear technically-correct answer, so I'm seeking opinions from the crowd.

I created the Shopping List Space, as previously described, and invited Kate to it. Whereupon she IM'ed me to point out that she couldn't figure out how to *do* anything in it, and the UI didn't look like what I was describing. I scratched my head for a bit, she sent me a screenshot -- and I realized that I hadn't given her Edit permission in the Space, so it was rendering everything as read-only.

Which leads to the question: what *should* the default be? Very precisely: in a Space that has had no customization of its access control, should the Members have broad ability to Edit the Things in it?

(Note that "edit permission" isn't entirely a blanket statement. For example, only the Owner has the ability to manage security right now, and that's going to be a whole separate permission when I do widen it. Assume that I'm talking about editing routine application data here, *not* meta-level management stuff.)

My Security Architect and User Experience hats are yelling at each other about this, at top volume. From a security standpoint, it is clear that the default should be restrictive: I should have to say explicitly who has edit permission. But from a usability standpoint, especially for a tool that is intended for the layman, that sounds daft -- if I've said that this person is a Member of the Space, they should be able to play in it. Ordinary users, frankly, need security that is dumbed down, but defaults in ways that they consider sensible and intuitive.

I honestly don't know which is correct, and I'm way too close to the problem. So I'm looking for opinions here, and especially for any other viewpoints that I'm not considering...

  • 1
Can you have multiple levels of edit access?

User / member can add / delete objects of their own creation or a sub group (family) they are a part of, but not off a master list.
Admin / owner to edit master list / permissions.

Have the default be member level of edit.

There's pretty rich granularity for edit access. In order, the edit access for a given Thing is controlled by the following fallbacks:

-- The explicit Edit permission for this Thing
-- The Edit permission for its Model (class, more or less)
-- The Edit permission for the Space it is in
-- The default Edit permission

Create permission is separate from Edit.

Your suggestion is reasonable, but not wholly obvious. Any specific rationale behind it?

I was thinking of the ios grocery shopping app that my wife and I use. Specifically the functions we like about it.
The statement about shopping space and list on the phone led me in that general direction. Granted you may want a shopping space that has more options than just grocery store generalities.

So, as an end user I want to be able to input / add items to a list. Maybe make a master list of items I frequently get. Maybe make sub-lists for specific locations. I need to be able to edit items on the list (quantity, brand, etc). I would want to be able to check off when I got an item so my goldfish memory does not have me getting it twice. I want anyone I am sharing lists with to know what I am getting, have gotten, and be able to edit the list as well. example - one person went to the store, person not at store remembers item x, adds to list, person at store sees new item on list.

So for shopping space end users need edit of lists, items, quantity of items for the space to be useful. Sharing would be useful if this was to be social as previously indicated.

Okay, makes sense. Thanks!

Can it be an option made at the time of invitation? Google Docs and other collaborative document tools have the notion of inviting someone as a reader/reviewer/non-editor versus a collaborator/editor/term of choice here. And it is one you must make at the time of invitation, defaulting to non-editing, but easily switched to editing at the time of invite. Always with the ability of the owner to raise or lower permissions later.

Hmm. That's not a bad idea. Doesn't work with the current workflow, but it shouldn't be rocket science. And the general notion of forcing the owner to make an important decision like this (and making it quick and easy to do so) does seem reasonable. Probably implies that I need to distinguish standard roles of "Member" vs. "Editor", but I'd been thinking about that anyway.

I'll chew on that -- thanks!

"Very precisely: in a Space that has had no customization of its access control, should the Members have broad ability to Edit the Things in it?"

No, but...

a) It should be very easy for the Owner to change that default.
b) One would expect many Models (such as for example, a generalized Shared Shopping List) to have their defaults set differently. So any Spaces that descended from such Models would (if unchanged) inherit the more-permissive default.

(a) is already more or less true. (I wouldn't call it "very easy" yet, but I already know how it is intended to get there.)

(b) is an interesting observation, and I'll need to chew on it. Apps are still hypothetical, and I hadn't gotten around to thinking about permission inheritance. I suspect we'll want to talk this through in some detail, to figure out what is both intuitive and safe. (There are some immediately-obvious abuse approaches that we'll need to make sure we protect against.)

People approach technology with different expectations. Some users will expect "Anybody can edit" to be the default: the Wiki-centered crowd are going to expect this on some level. Some will expect "I assign permissions" to be the default.

If technically feasible, make the "default" a tunable option on the Owner's account preferences: "New Spaces may be edited by any invitee" or "New Spaces require specific permission to edit."

Of course, what default to use for that? Not sure. I lean toward "Requires Specific Permission", and explain loudly and repeatedly that you can change that--and you have to live with the consequences. It's much easier to let the genie out of the bottle, after all.

Hmm. Okay, I can see the value in that approach. I hadn't thought about this as a *user* preference, but you may well be right that we should be prepared for variable expectations.

Interesting viewpoint, which I hadn't considered. Thanks!

What other "Per Account" defaults do you want inherited by Spaces?

Don't know -- this is a whole approach that I hadn't been thinking about. It makes sense that we might want "My Spaces" preferences, but this is the first time it's come up. I suspect we'll mostly figure them out as we go along...

So I'm looking for opinions here, and especially for any other viewpoints that I'm not considering...

There's the Wiki viewpoint, which would say "edit permissions by default" - even FosWiki has that as the standard, though you can lock things down as tightly as you'd like.

But after reading the comments, I half-prefer the notion of including it as part of the invite. (Half because I feel like it might get annoying to have to specify repeatedly with every invite, rather than being able to set it once and forget it. So I'd say in an ideal world, I'd have a Space setting which could be "Give new users edit rights", "Don't give new users edit rights", and "Prompt on invitation", with the last being the default for new Spaces.)

Makes sense. There is a midpoint that we might strike, which is that the Space defines the default for the prompt -- so the choice is always in my face, but after setting it once I don't have to *do* anything about it...

Ask it to set an individual default for Spaces you create when you create your account? (Or is that too complicated on the programming end? It *sounds* like it should be complicated...) If one of the account creation questions is something like "Do you prefer your default to include editing?" though possibly phrased a bit better, everybody could decide for themselves.

Or alternatively have a separate kind of class you can add someone as-- add them as a Member or add them as a Reader, which seems much more intuitive from a layman standpoint than mucking with permissions even though it technically *is* mucking with permissions, and force the question for each person you add.

If that's not an option, then I'd say default to editing-enabled, because paranoid people who grasp security measures are going to actually go looking for them and probably have enough computer-savvy to use them, while people who don't grasp security measures aren't going to want to fuss with them and are just going to want it simple because "who cares about hacking into my X?" (Which question I've been asked for all manner of X, some of which made me widen my eyes and go "No, you *really* need to secure that...")

All plausible -- the first option is similar to Talvin's suggestion, the second to Laurion's. (And it is plausible that I might do some combination of the above.) Thanks...

In the world of email lists, some lists are set up "reply to all" as default, and some "reply to sender" as default. Each group thinks the other is nuts...

I'm wondering if there should be two subtypes of space, one with edit privileges engaged by default, the other locked down (as current), so that someone creating a space would choose one of these as their first decision.

Or am I trying to place this at the wrong level of the hierarchy?

Looking at some of the other comments (and your replies) it looks to me like one option is "all members are editors by default (but can change status to "just a reader") " and the other option is ""all members are reader by default (but can have "editor" status granted by the space creator)"

I think that having two subtypes of Space baked in is probably too fiddly to be worthwhile, especially since the issues are actually fairly subtle. There's no obvious benefit to this approach over just having a Big UI Button that sets things up as desired, and it's likely to have a lot of side-effects.

That said, it's plausible that we'll eventually find ourselves with some concept of "templates" for Spaces (as opposed to Apps, which are already in the design), and those might have prebaked defaults for access control. I don't have nearly enough sense of what such templates might do otherwise, though, so that's just something to ponder...

Well, in that case, I vote for the secure version being the model (as it is now) and it's up to the user to realize that if she's making a type of space that calls for inclusion she needs to set permissions appropriately.

I still think it should be a choice that gets made at time of creation (this would be the Big UI button?) AND which can be overridden at time of invitation, or at a later time. I want to have my cake, eat my cake, and have the box that the cake mix came in still be full...

Heh -- fair enough. I'm not changing anything right this minute, but this discussion has given me good food for thought for where things should gradually evolve. Thanks...

  • 1

Log in

No account? Create an account