Log in

No account? Create an account
Previous Entry Share Next Entry
Should Querki Spaces default to public or private?
This is related to a topic I tossed out in the Querki Dev Journal yesterday. The more I think about it, the more important it seems to be -- it's a subtle detail, but likely to affect the contours of Querki's overall social structure.  So I'll ask the larger crowd here.

The issue is privacy settings. To summarize the above article, Querki allows users a lot of fine-grained control over security, but to make it usable we're going to need to sum that up into a few easy-to-use options: you pick one of these, and then tweak the details if you care.  I expect relatively few people to do much tweaking.

The question at hand is what the *default* option is when you're creating a Space, Public or Private. For reasons I describe in this comment, I don't think we can entirely duck this decision -- at the least, we're going to wind up subtly influencing user choice, so I'd rather do that deliberately instead of by accident.

So the main question is, when you create a Space, which of these options is the default (or at least, on top of the list):

  • Public: The Space is (mostly) publicly-readable and commentable, a la a typical LiveJournal.

  • Private: The Space is (mostly) not readable by non-Members, a la a typical private Facebook group.

(There will also be "Hidden" -- you can't even tell this Space *exists* unless you are invited in -- but I do not believe that should be the default.)

Closely related and still important: should we be explicit about this default, or should we require that the user creating the Space make a decision? (That is, should one of the radio buttons be checked initially or not?)

Opinions solicited, at least in this quick poll. I'm very much on the fence here -- it's a less easy issue than it looks at first glance.  Comments and thoughts also welcomed...

Should Querki Spaces favor Public or Private?


Should users be forced to choose explicitly, or should there be a default?

Require explicit choice
Have a default

  • 1
(Deleted comment)
Hmm -- interesting point. Yes, that's a consideration I'll have to keep in mind here...

By have a choice/a default, the user should be able to choose both their default behavior and that of an individual post.

Absolutely this.

I'm in favor of requiring an explicit choice (no preselected option) but with a checkbox that says "use this choice as the default in the future".

Hmm -- interesting idea. I hadn't thought of doing it quite that way. At first blush, I like it. I'll chew on that further: thanks!

Well, keep in mind that a Querki Space is far more than a post -- it's essentially an entire database/website. This decision defines an entire collaborative space; that's why it is pretty important.

But yes -- in the medium term, you'll be able to set this as a personal preference. I expect that to be handy for power users, but I honestly don't expect more than 10% of users to ever set it; hence, I think of the default as being more important overall.

(I've been pondering the notion of making this decision persistent, as a sort of implicit preference -- your choice this time becomes the default for next time. But I'm not actually sure that helps, and I suspect it *may* be worse all around...)

I think it depends on your dominant target market.

For the corporate world, or other situations where it's unlikely someone would want people to wander into their space, Private should be the uber-default.

For the social-media / hobby / enthusiast / casual-user world, Public should be the uber-default. You want people to be able to find cool things.

(...or maybe not. If Public is the uber-default, people will be able to explore a lot of half-baked not-yet-done spaces, which might make the interesting / quality ones harder to find.)

Either way, I think you definitely (a) want an explicit choice, and (b) want to explicitly tell the space creator that this is something they can change later.

I think there are more than just 'public' and 'private' models that you will want to have.

I'd go with a 4 setting model.

'Editable' being open to anyone to read and edit (wiki model),

'Open' being world readable and world comment-able (LJ).

'Public' being world readable but not comment-able. Basically, your average external website.


'Private' being not world readable (facebook).

I'd add side-setting for Open and Public for selecting between moderated and unmoderated comments .

Regardless, the default should be part of setting up a space and explicit.

'Editable' being open to anyone to read and edit (wiki model),

Not going to happen, sorry. Bitter experience has taught me that wide-open wikis are always a bad idea unless you have sufficiently massive scale to fight the wikispammers. (Eg, Wikipedia.) It is *possible* that I may soften my stance if there is sufficient outcry, but my current stake in the ground is that non-members *cannot* submit or comment without moderation, period.

Note the implication: in the medium term, non-member submissions will work almost exactly the same as non-member comments -- if the Space allows it at all, they will go to moderation. Moderation will be designed to be as easy as possible, but I am intentionally setting things up to encourage/require curation of your Space: the community is ultimately responsible for its content.

(Also, there will be whitelisting in the medium term. As far as I'm concerned, whitelisting is essentially a very low-privs and easy version of membership -- the moderation approval screen will have a checkbox for "Approve this person's comments/submissions in the future.")

'Open' being world readable and world comment-able (LJ).

'Public' being world readable but not comment-able. Basically, your average external website.

Possible, although I'm going to see how things play out. If there seems to be demand for this distinction, I might make "Non-members can comment" a checkbox under "Public" -- I think it may be clearer that way.

Somewhat tangential, but, I am fond of the message "You can change this decision later", especially when making sweeping decisions very early in a setup process.

Hmm -- good point. The same control will be available on the Sharing and Security page, but I hadn't thought about saying that explicitly...

  • 1