I[base ']ve planted the seed that I hope will grow into the kind of community site that defines community the old-fashioned way [~] people living in the same place [~] as well as in the modern sense of network affiliation. The project has raised a bunch of technical, operational, and aesthetic issues.
Technical: Django is working well for me, but I haven[base ']t invested deeply in it yet. Patrick Phelan, a web developer I[base ']ve corresponded with for years, reminded me the other day that my reluctance is strategic. With any framework, buy-in cuts two ways, and you should never take unnecessary dependencies. Patrick noted that I am using WSGI, a Python-based Web Server Gateway Interface, to connect Django by way of FastCGI to my commodity hosting service. And he pointed out that a rich WSGI ecosystem is evolving that could enable me to proceed in the minimalistic style I prefer, integrating best-of-breed middleware (e.g., URL mapping, templating) as needed. If the preceding sentence makes any sense to you, but you haven[base ']t heard about Paste and Pylon (as I had not until Patrick pointed me at them), then you might want to watch the Google TechTalk that Patrick recommends.
Operational: I[base ']m doing this project on $8/month commodity hosting because I want to understand, and explain, how much can be accomplished for how little. Bottom line: amazingly much for amazingly little. For years I[base ']ve supplied my own infrastructure, so I never had the experience of using a hosting service that provides web wrappers to: create subdomains; provision databases and email accounts; deploy blogs and wikis. Sweet! At the same time, though, I[base ']m struck by how much specialized cross-domain knowledge I[base ']ve had to muster. For example, the first service I[base ']ve built on the site, a community version of LibraryLookup, relies on programmatic use of authenticated SMTP to send signup confirmation messages and status alerts. I figured out how to do that in Python, but it took some head-scratching, and my solution isn[base ']t particularly robust. For me, spending an extra buck a month for a more robust solution (ideally delivered as a language-independent web service) would be an option I[base ']d consider. For many people, though, it would be an enabler for things that otherwise wouldn[base ']t happen. There[base ']s a ton of opportunity in this space for buck-a-month services like that.
Aesthetic: For now I[base ']m going with an aggressively Web 0.1 style, a la del.icio.us and craigslist. My wife[base ']s first comment was: [base "]So, you are going to pretty it up a bit, right?[per thou] I dunno, you can argue it both ways. The current arrangement has the advantage of being The Simplest Thing That Could Possibly Work. But virtuous laziness aside, it may be that craigslist, in particular, has validated the Web 0.1 aesthetic for community information services. Or it may be that my wife[base ']s first reaction was correct, and I[base ']ll have to look for a volunteer designer. We[base ']ll see.
None of these issues are top of mind for me now, though, because they[base ']re all trumped by a conceptual issue. How do I demonstrate methods of syndication, tagging, and service composition so that people will understand them and, more importantly, apply them?
Consider the version of LibraryLookup that I[base ']ve built for this site. The protocol is, admittedly, abstract. It invites you to use your Amazon wishlist not only for its existing purposes [~] keeping track of stuff you[base ']re interested in, registering for gifts you[base ']d like to receive [~] but also as an interface to your local library.
Dan Chudnov thinks this is a questionable approach, and his point about interlibrary loan is well taken. But we don[base ']t have through-the-web interlibrary loan in my town, and if we did, I[base ']d still want to use Amazon as my primary interface to it. To me, it[base ']s obvious why and how to wire those things together. To most people, it isn[base ']t, and that[base ']s the challenge.
To meet that challenge, I[base ']m stepping back from some things things that have been articles of faith for me. For example, this service does not yet notify by way of RSS. Just email for now. Of course I can and will offer RSS, but in my community (as in most) that is not the preferred way to receive notifications.
Everything else about this service will be unfamiliar to most people:
- That an Amazon wishlist can serve multiple purposes.
- That LibraryLookup is OK with Amazon. (It is. Jeff Bezos told me so.)
- That we should expect to be able to wire the web to suit our purposes.
The lone familiar aspect of this service, I realized, is that once in a while you get an email alerting you that something you want is available. Everyone will understand that. But the rest is going to be hard, and I[base ']ve concluded that evangelizing RSS in this context would only muddy the waters even more.
In other ways, though, I[base ']m pushing hard for the unfamiliar. It would be an obvious thing to use Django[base ']s wonderful automation of database CRUD (create, read, update, delete) operations to directly manage events, businesses, outdoor activities, media, and other collections of items of local interest. People are familiar with the notion of a site that you contribute directly to, and I could do things that way, but for the most part I don[base ']t want to. I want to show that you can contribute indirectly, from almost anywhere, and that services like Flickr and del.icio.us can be the database.
I got a great idea about how to approach this from Mark Phippard, a software guy who lives in my town (though we[base ']ve not yet met in person). Mark wrote to offer technical assistance, which I[base ']m glad to receive, but I wrote back asking for help breaking through the conceptual barrier. How do I motivate the idea of indirect, loosely-coupled contribution?
Mark mentioned that one of his pet peeves is the dearth of online information about local restaurants. You can find their phone numbers on the web, but he[base ']d like to see their menus. That[base ']s a perfect opportunity to show how Flickr can be used as a database. If Mark, or I, or someone else scans or photographs a couple of restaurant menus and posts them to Flickr, tagged with [OE]restaurant[base '] and [OE]menu[base '] and [OE]elmcityinfo[base '], we[base ']ll have the seed of a directory that anyone can help populate very easily. Along the way, we might be able to show that Flickr isn[base ']t the only way to do it. A blog can also serve the purpose, or a personal site with photo albums made and uploaded by JAlbum. So long as we agree on a tag vocabulary, I can federate stuff from a variety of sources.
And now, I[base ']m off to collect some local restaurant menus. A nice little fieldwork project for my sabbatical!
