-
Notifications
You must be signed in to change notification settings - Fork 11
Use case crowdsourcing
This is essentially a meta-Use-Case -- the conceptual basis for Use Case Wine List, Use Case Restaurant List, Use Case Poker and many others.
The high concept is that many Apps are best thought of as collaboratively managed databases -- crowdsourced, in the current jargon. In these cases, the lines between App and Space are a bit fuzzier than normal: instead of the structure all being in the App and the data all being in individual Spaces, we really want most of the data to be in a communal, shared Space, with individual Spaces used as a customized window into that.
Since I expect this concept to be common and powerful, we should think carefully about how to make it as easy as possible.
This is, plain and simply, likely to be Querki's killer app. If we can make it easy to build crowdsourced databases, folks are likely to flock to them. It's likely to be a fair amount of work to get right, but is likely going to be well worth that.
Structurally, I believe these things will typically have three levels. First, there is the root App, which as usual is all about the structure. Then there is the communal Space, where most of the records live. Finally, each user gets their own Space as usual, but frequently with very little customization or data.
The trick here is to think carefully about curating policy. We can't allow the shared database to simply sit, uncurated, or it will become a spam magnet. So the app owner will be required to curate the data.
That said, we can offer several curating techniques. These will include "active curating" (each new record must be reviewed before it is approved) and "passive curating" (records can be displayed immediately, but will be presented to the curators, who can then remove them).
We should encourage the App owner to build a community of curators, and have new records doled out to curators in some more or less reasonable way. (Ideally, based on how responsive each curator is, and how much they say they want to take on.) Curation requests likely should be considered a queue, where a curator simply gets told that there are new requests, and they can pull records off of that queue when they choose to do so. Ideally, we might do some automatic double-review, so that rogue curators can easily be caught.
All of this curation is probably only for fully public Apps. If an App is limited-view, with the membership controlled by the owner, we can probably allow uncurated addition, on the theory that the members are more trusted.
Technically, the big change here is the relationship of Space and App. Each user who instantiates the App should get a choice of what to do with new records that they add -- whether they default to being public (but can be marked private when you enter them), or private (and can be pushed into the public Space at any time).
Each user's Space is essentially a customization point. They can add private records; they can also create private modifications to records however they choose. Indeed, Crowdsourced Apps should usually have a standard field or two for private notes, along with public discussions, reviews and other such shared information.
Users should be allowed to create sub-curated communities -- basically, limited views of the public community. This is potentially a hair challenging, since it requires inventing a mechanism for a Space to say, "I don't want any of the non-Model Things from my App by default", but that shouldn't be rocket science -- it's probably just a meta-Property on the Space, a bit of special code, and another Property that says, "I'm including this one". Indeed, private Spaces will likely often want this, so I can create a filtered view of Things I like. (Ideally, it should be Very Very Easy to create such a View -- define some standard Property for the filter I want, and a QL stage for filterOn().)
Crowdsourced Apps are probably the ones most likely to benefit from advertising -- which is good, because many of their users aren't going to need to be paid members of Querki. In the short run, simply letting Google Ads do its thing is likely to produce a modest but nice income flow. In the longer term, it'll call for some real advertising and marketing know-how, probably to work with an advertising specialist company to build advertising systems customized to each App. Since the Apps are likely to be pretty domain-specific, they should be unusually effective from an advertising POV.
As usual, of course, paid members shouldn't be subjected to ads unless they specifically opt into them. That shouldn't be a huge problem -- indeed, if we can get enough compelling crowdsourced apps, that will encourage folks to buy paid memberships.
-
Feature -- Crowdsourcing: The big feature group for this use case. Will get broken down more later.
-
Feature -- Views: The ability to easily define a private or curated View over a common Space.
-
Feature -- Curation: The collection of stories to submit records to a group of curators for approval.