As Sharon pointed out, my “Fish tales” experiment the other day was a mixed bag. On the one hand, the sandbox nature of it fostered a sense of openness by letting anybody modify anybody else’s movie. On the other hand, it really was a sandbox, in the sense that any sand castle you make might be gone the next time you visit the sandbox.
Which means people aren’t going to put a lot of work into making something great. In the immortal words of Rutger Hauer, “All those moments will be lost in time, like tears in rain.”
So what to do? I don’t want to allow people to type in names for their creations, because that will open the whole thing up to trolls — I worry that I’ll come back in two months to find that somebody has used my little fish tales space as a place to invent new varieties of curse words.
My thought is to let everyone create in their own private sandbox until the moment they want to save their work. Then I prompt them to type a password (unseen by anybody but them). Once your work is uploaded, anybody can see it, but if you want to modify something that’s up on the site, you need to know its password.
This has the advantage that people who want to work together on something can still do it — one person uploads it, and then shares the password with their collaborator(s).
There is still the problem that the site might get cluttered with hundreds of uninteresting fish tales, which will make it impossible for visitors to find the really good ones.
One solution might be to rank each fish tale by how often people play it (weighted by how much of it they play), roughly following the YouTube philosophy. If tale 47 gets a lot more play than tale 93, then maybe it’s more worth your while to check out tale 47.
I’m open to suggestions on all this. I’d love to figure out a good general model for effectively nurturing a creative community.
It is starting to sound like a lot of work! I suspect that the problems I noticed the other day were due to confusion about the UI, not malicious behavior. It may not have been so clear how to avoid choosing the same number that someone else chose, or that if you happen to click on a number and then start making modifications that you’d be overwriting the existing animation. I think perhaps a simple “Save” button (no auto-save) followed by a warning/confirmation if it would overwrite an existing animation might be enough for now. If someone doesn’t want to overwrite an existing animation you could offer an option to save under an unused number.
If you want to get fancier, I think it would make sense to have a new animation be in a private sandbox until the creator chooses to save or share it. Some people will just want to play around but not necessarily create something they deem worthy of sharing or even saving. Your password scheme sounds like a fine approach if it isn’t too difficult. As for ranking, you could let people vote for the ones they like (keep a little vote counter next to each animation displayed on the site). I’m not sure there would be a lot of motivation to spam the voting at this point.
FWIW, creating a model for nurturing a creative community seems to be a harder problem than it appears at first glance. It sounds like it should be straightforward, but things keep coming up. We ran into this with our first attempt to build a community site for App Inventor. We’re now in the middle of the second attempt, and there still is no site yet. It makes you appreciate what a good job the Scratch people have done.
Thanks Sharon! None of this is a lot of work for me. More like a lot of fun. 🙂
I agree the UI needs to make it more clear when you are modifying a shared space. For example, my friend Charles pointed out to me yesterday that it would be good to know when the tale you are editing is also being simultaneously observed or edited by others (the way Google Docs works).
One thing I don’t want to lose is that Google Docs-like ability for two people to work on the same tale synchronously, seeing each others’ changes as they happen. The version I have up there indeed supports this ability, and it would be a shame to lose it. My proposed password scheme would let me preserve that (which doesn’t mean it’s the right way to go).
Yes, letting people vote for what they like seems like a good thing to try. I already have the data of who is looking at what, without asking people to do anything, so it might be interesting to have both features and compare the two.
The wonderful Scratch community was built not just from great software design and innovation, but also a lot of community outreach, year after year, and constant innovation/iteration by their group at MIT. Mitch and his team meet regularly specifically around the topic of how to build and nurture that on-line community — it’s a central focus of everything they do. I’ve always been impressed by how much serious effort they put into that.
I can see App Inventor following an analogous path, and I very much hope it does!! I wouldn’t expect that anything I do here would have that kind of reach. I’m just a guy putting my little experiments on-line. 🙂
It all starts with “just a guy…” (or girl? gal? woman? what’s the analogous word?). App Inventor started as just a guy’s sabbatical project. 🙂
Being able to edit the animations simultaneously a la Google Docs and have it still be clear to people what is going on is an ambitious goal for your “little experiment.” I have no doubt that you can pull it off though!
So, on a mundane note, while I was editing my animation I noticed that the screen would quickly flash periodically, like it was bring refreshed. Are those your save points? Would I not see my collaborator’s changes until the next refresh?
We probably just need some kind of revision control. If all past editings are stored in a revision history, people may feel more relieved in seeing their updates overwritten by others as they are not really gone. And if some “voting” scheme is provided to let users collectively decide content in a more open and civilized fashion, the experience will get even better.
This is exactly what Wikipedia did. There is no guarantee that my updates will show up in the latest version as anyone can undo that, but I know everything I did will be part of the revision history. And if the content is good, more likely than not it will end up in the final version.
The interesting point is that Wikipedia is about facts, so there is some sort of universal truth behind each data entry that can benefit from a collective voting scheme. This cannot be said of art, which has no universal truth. A potential solution is to allow multiple *branches* (in revision control jargon) to exist simultaneously.