Via Dav/AkuAku, this from the Bunchball website:
“You have an idea for a multi-user networked application. Maybe it’s a game, maybe it’s a new way to share music or photos, maybe it’s something nobody’s ever thought of. A beautiful little jewel of an application, you know that you can make something fantastic. But then you realize that in order to build your application, you need to figure out user signup, and group creation, and invitations, and permissions, and chat, and presence, and how to save changes in the application, and how to figure out who to send those changes to, and the list goes on. And oh yeah, don’t forget that you need to setup a server, write server-side code, deal with a database somewhere, worry about uptime and bandwidth and online file storage, and that list goes on as well. All of a sudden you realize that your beautiful little jewel is just the tip of a very large iceberg. You’re going to spend 90% of your time implementing what’s below the water, out of the user’s sight, and 10% of your time building a great application.
Bunchball gives you the iceberg. You just provide the tip. So now you can spend your time doing what you wanted to do in the first place, which is to create a great application.”
Along with Ning.com, Dav has termed these services (or ‘playgrounds’ as Ning would have it) as ‘Blank White Servers’, which are potentially game-changing things, beyond the bubble of hype around Web X.X.
The point the Bunchball site makes – that providing the common building blocks and infrastructure allows developers to concentrate on delivering extra value to the end-user -makes me wonder whether this will be the case.
Will developers, freed from the burden of recreating back-end systems, invest their energy into creating a great user-experience?
Possibly.
Certainly, Web X.X’s real successes so far have been built on great UI design (Flickr, Gmail) and paying attention to the details in the user-experience – hopefully this will serve as inspiration to those who follow.
In my experience at least, it takes a great deal of effort and will on the behalf of the developers to go the extra (several) miles to create a great user-experience on top of getting something to “just work” – especially if there is a pre-established framework or library of things that they are using to create a service or application.
Also, there is the problem of trying to reconcile the design choices you think necessary for the specific service, aplication, user or activity at hand with the design choices predetermined in the platform by those that came up with it.
This building block approach of Bunchball, et al, of course begs the same question of what design choices are encoded in the building blocks themselves?
The following ramble I will have to revisit once I’ve explored and understood Ning and Bunchball more fully from actually playing with them both, but…
Architecture is destiny*: someone elses playground, architecture, landscape, physics will inevitably shape the end design noticeably. What are the combinations it forces? What are the affordances that are built in, and what patterns are most favourable as a result?
As they are aimed at providing infra and building blocks for social applications, would perhaps some of the forced combinations, or affordances of the infrastructure be default-biased towards safety and privacy?
Productivity or (/and?) play?
As playful platforms made by smart people I’m sure that the possibility spaces they afford will sustain 99% of the self-centred or small-group-centred software that people will want to construct right now – which is just fantastic.
But…
Just what politics are encoded at the molecular level of these playgrounds?
As soon as I get my accounts I’m going to start playing and see.
—-
See also: The Otwell on Ning
—-
* Who said this originally? I can’t seem to find the source.
Petafloptimism 
google seems to think it’s Jay Chiat:
cache
or in this book by Arthur Danto:
brillo
?
I don’t know if he was the first, but Lawrence Lessig has expressed these ideas before. The following are notes that Dan Gilmor posted on a seminar Lessig gave in 2002 (which are unforunately no longer online but fortunately I’d scribbled it down 🙂
This implies that there is always a great deal of intention in the way things get built…a grand master plan of sorts…and while that may be true for physical building projects (where there are major liability and public safety issues concerned), projects built with code (a more malleable and forgiving medium than steel and concrete) seem to be a little different and are often put into the world without as much forethought, to quickly test ideas and assumptions that can be folded back in…
Ideally this process would yield a more responsive product, though I don’t actually know if that is always the case. I guess a lot depends on how and who one listens to.
This though implies that there is a great deal of intention in all of this…and sometimes a ramp to a building isn’t built not because of any expressed desire to keep out those with wheelchairs but simply because of time and budget constraints,
Hey Matt –
Great questions & commentary. I don’t think Bunchball is really a Blank White Server. Probably more beige, with gridlines on it – which I think is to your point – we made design decisions that determine the kinds of things that can be built on our platform. Some of those decisions are good, others undoubtedly suck. Hopefully we can fix all the bad ones with input from developers and users.
Re: your point about UX – one of the reasons for choosing Flash for bunchball was because for Flash Developers, UX is part of what they do – it’s part of their DNA. It’s the rest of the hackery that they could use help with. I’ll use myself as an example – BA and MS in compsci and yet have no desire (or skills) to write server side code.
Our API is very simple. Our initial focus is pretty narrow, primarily games and other entertainment applications. And we’re working on improving what we can offer every day. We’ll see where it goes…