Previous Entry Share Next Entry
Invitations
querki
jducoeur wrote in querki_project
Okay, time to start coding invitations. Before I do so, here's what I am thinking -- please call out any concerns ASAP. It is *very* different from what I originally planned, but I rewrote the design based on previous discussions here, and I think it should suit us well.

Requirements and Concerns

The most important thing about the Invitation model is the classic two-edged sword of invites to a startup. On the one hand, we need to encourage viral growth; on the other hand, we need to be able to *manage* that growth.

We're going to succeed as a company only if the model is carefully designed to go exponential. One of Paul Graham's most important observations, IMO, is that this is basically the *definition* of a startup -- you must hit an exponential growth curve, preferably in the ballpark of 10% per *week*, which is a bit staggering when you think about it. Moreover, I actually want even faster than that for the first few months of beta -- I'm not really going to be happy unless I can pull off closer to 25% per week during the initial "inflationary" period.

But managing that growth is also crucial. If things went truly viral in the YouTube sense, growing 1000% a day, our servers would simply melt into a puddle, and that's not good for our image. I really don't want to mimic the early days of Twitter, which spent its first year as basically synonymous with "currently down; try again later". We need levers that we can open up gradually, allowing growth to occur as quickly as we can handle it but not quicker.

Most startups handle this with a classic viral-invitation model. Each user gets a small pool of invites, that they can send to their friends; as the system resources grow, they get more invites.

That was my original plan, but it doesn't actually fit Querki all that well, because the important granularity isn't really the number of Users, it's the number of *Spaces*. By the way the system works, we can actually handle a *lot* of Users per Space pretty gracefully -- that's the advantage of the in-memory database model, which is staggeringly fast compared to most dynamic architectures. (And there is a ton of room for further optimization down the road.) But we're heavily memory-bound, and can only support so many Spaces active at a time. So that's the important lever to control.

Moreover, I very much want to encourage collaboration. There's not much there yet, but collaboration will be one of the primary feature areas over the next six months. I want people to be able to invite the right collaborators to share their Spaces and work with them, without too many artificial constraints. If somebody has a project that requires dozens of people to work together, that's a good thing, and I don't want them to be frustrated by artificial constraints that force them to dribble out the invitations over weeks or months.

So instead, here's the plan.

Invitation Architecture

The key distinction is going to be between "Full Users" and "Pending Users". (For now, there is no payment model, so there is no free-vs-paid distinction. That'll come sometime next year.) There will probably be a few differences in terms of what they can do, but one is all-important: only Full Users can *create* and *own* Spaces.

(Initially, there will be a limit to how *many* Spaces each User can own, and I will frown on anybody gaming the system, but I mostly hope that folks just won't abuse it too much by, eg, creating a Space solely for someone else's use.)

As a Full User, I can issue Invitations to join in my Space, by email. (Eventually, these will go mainly through social networks, but one thing at a time.) I am limited in the number of such invitations I can issue, but the limit won't be tiny -- I certainly want people to be able to invite a hundred people or so into a project, and we'll likely set the limit at several hundred before Beta. (It'll probably be on the orders of dozens at first, but I'll try to increase that as much as is feasible.)

The invitees will be prompted to create a user account, verify their email address, and all that usual stuff -- in most important ways, they will be Users. The key limitation is that they will be Pending Users, and will not be able to create their own Spaces at first, just use the ones that they are invited into. (We'll likely also add an optional "Join this Space" feature, allowing people to request membership in a Space if the Owner allows it.)

As Admin, I will be able to review the Pending Users. I'll be able to upgrade specific individuals directly, if I have specific reason to want them in (the folks involved in the discussions here, for example), but mostly we'll do it in batches, in order of signup time. When you get upgraded to Full User, you'll get a notification to that effect, and will be able to create your own Spaces after that.

Note that the system is mostly going to "play fair" -- while I reserve the right to bump certain Pending Users to the front of the line for Full User status, otherwise I plan on inviting people exactly the same way you do. For Alpha, I will create an Alpha Space, whose main purpose will be to invite folks in and provide a bit of introduction to the system.


Opinions? This seems like it should fit my goal, which is to constrain the growth of Spaces to a manageable level, while allowing the Spaces that *do* exist to quickly become fully-active communities. That seems like the right way for this project to proceed...

  • 1
The plan seems reasonable, but I think you might want to change the terminology, in the case of "pending user." If I got mail telling me I was a pending user, I'd think your system was full, and you'd let me be a user when your capacity increased. That may be true, from the standpoint of being able to create spaces, but that's a subtle distinction which isn't obvious from the term. I wouldn't expect to be able to do anything while a "pending user," and that might discourage participation.

I was going to suggest "space user" as an alternative, but that has a whole different set of negative connotation, so no.

How about "provisional user" instead of "pending user?" The implication is still that they might later be a full user, but in the meantime, they have some abilities.

Hmm -- good point. I'll ponder that, but I'm not wedded to the terminology...

I kinda feel that "Pending User" should be "User" and "Full User" should be "Creator" or "Wizard" or "Architect" or something else to denote "User that creates spaces", even if the word "User" ends up getting phased out entirely upon launch.

(Deleted comment)
I kinda feel that "Pending User" should be "User"

+1. Not sure what the Full Users should be called, but complicating the nomenclature for 90%+ of the people visiting the site at first doesn't seem like the best call.

See the reply I just posted -- I disagree, for very specific reasons. Remember that the whole "pending user" thing is short term...

I see where you're coming from, but I actually don't care for the specific suggestions. Remember that the whole "pending user" thing is a short-term necessary evil, and in the medium term there will be *only* "full users". And while the geeks are likely to like terms like "creator" or "architect", I'd bet dollars to donuts that typical Facebook users (who are, remember, supposed to be enormously in the majority in the long run) will find it intimidating.

In other words, the term I *care* about is "User" or something like it. Yes, it's bland, but that's kind of intentional -- the point is that *ordinary* people should be able to do these things, routinely, without feeling the responsibility of being an "Architect". And yes, I am fairly sure that most people *will* look at that as a title that implies you're supposed to know something special that they don't.

(Insert rant about the priesthood of programmers here -- I could go on, but 'nuff said.)

I have no attachment at all to "Pending User", and am open to suggestions to change that. (oakleaf_mirror's "Provisional User" is more syllables than I like, but not a bad suggestion.) But I'm firmly against anything that implies that creating a Space is in *any* way a big deal: the entire point of Querki is that it should *not* be. It should be as routine and as ordinary as creating a text document -- that's the whole point of the project...

I knew you'd disagree with me and I knew your reasons why. Consider this rewording of my suggestion then: You have Users and you have User+s. As your beta expands, all privileges that User+s started with are grandfathered into all Users, and all that's left that's different for User+s is the designation. Maybe just call them "early adopters" or "alpha testers". "Or Guinea Pigs". Or "Minions".

Possible. I confess, I'm largely pondering whether this is a tempest in a teapot -- I'm not sure how much these terms are actually going to be visible in the UI anyway, so it may be a non-issue.

That said, I find myself actually leaning towards "Invitee" for the first-phase folks, and getting away from the "kinds of User" thing on the visible level. It's a more positive term, not implying anything missing, and it is an honest reflection of their status, as someone who has been invited to use one or more Spaces...

I have no attachment at all to "Pending User", and am open to suggestions to change that.
Brainstorm:
* Visiting User
* Guest User
* New User
* Recent Inductee Into The Awesome
* Space User
* Spacer
* Consumer
* Limited User
* SubUser
* Beta User

I don't like most of these, but a few are OK. New User is both accurate and makes it obvious that in time you become a normal User.

What do you think of "Invitee"? That was last night's thought, coming from an entirely different direction. Don't say anything negative about being a less-than-Full-User; instead, focus on the fact that you've been invited to join into somebody's Space. Feels more positive all around.

(Although, as I just remarked upthread, this may be largely a non-issue: I'm not sure that these terms are going to be especially visible anyway...)

Invitee also sounds fine.

(Although, as I just remarked upthread, this may be largely a non-issue: I'm not sure that these terms are going to be especially visible anyway...)

I was wondering about that.

(If they're not obvious labels, public-facing-wise you could simply call them both "User" - one with certain privs, one without.)

That's possible, yes -- I'll think about how I phrase that.

It actually touches on another detail I'm pondering, which is how aggressive the site should be about signing people up. I'm not sure whether it is cool or not to automatically make anybody who joins a Querki Space a user -- I worry that folks might get annoyed by the presumption. So I'm pondering whether it's worth including a checkbox in the sign-up page, to opt out of that. It may be appropriate to do, just in principle...

When I give usability talks, I always throw up the definition of user first:

us•er (ˈyu zər)

  1. a person who makes use of a thing; someone who uses or employs something (OK)
  2. a person who uses something or someone selfishly or unethically (not what you had in mind)
  3. a person who takes drugs (clearly not!)

This is why Apple has Human Interaction Guidelines. Maybe you just have Querkists. Maybe you have Space Rangers and Space Cadets.

My other concern is that you want exponential growth. However, there's an Admin in the loop needed to promote someone to full privs. That's a bottleneck that will break very quickly under exponential growth.


Fair point about "user", and one I've had in the back of my mind. I'm not actually as attached to the word as my previous comments makes it sound; my concern is mainly that we *not* drift towards any terms that imply any sort of deep knowledge. Demystification is a priority here.

However, there's an Admin in the loop needed to promote someone to full privs. That's a bottleneck that will break very quickly under exponential growth.

Actually, no -- the "promote this specific person" is the exception case, for when there is someone I particularly want to get up and running quickly. The *normal* mode of operation will be, eg, "promote the next 700 people" -- purely numeric and capacity-based. That should scale adequately.

(The ability to grow the *servers* exponentially is another matter entirely. But that's the main motivation to use one of the cloud-hosting services for the first few years, if possible...)

  • 1
?

Log in

No account? Create an account