see a puffin eat a fish

As I am working on my thesis and considering other location-based social media offerings, i’ve been thinking about where CrowdScapes stands with respect to what else is out there. Take these three: Yellow Arrow, Semapedia and Socialight. What I keep on coming back to is the static quality of the content and the critical mass of the user base. The three applications mentioned here are on a degree continuum.

Yellow Arrow works best as an organized, directed event. For example, everyone goes out and sticks yellow arrows in places they have rented apartments and others in the group go on a walk where they hear stories about these places. There isn’t much impact overall once the event is completed and all the created content is static. Someone has to go and move these arrows around to update content.

Semapedia also has a static tag that physically has to be put somewhere (not to mention custom 2D barcode reader software you have to install) but its back end is dynamic and fueled by the collaborative activity on Wikipedia. You can leave a tag somewhere regarding a current event and the next person who scans that tag may get different content from what you saw. The back end is constantly evolving as a collaborative community works on an collective encyclopedia.

Technically, Socialight is the most advanced and accessible. It supports the Web, WAP, SMS, MMS and J2ME. Through its virtual sticky system, all of its content is server side making it easy to update and keep current. What it needs is more users. A critical mass of users encourages other users to create content.

So where does CrowdScapes fit in? It is technically accessible to all (WAP) with a Python version on the way and a J2Me version if there is interest. Right now, it is not a social app. That was not the primary motivation. It’s about bringing interesting, constantly evolving content to people out in the world. The innovation with CrowdScapes is that although it might not be as tightly socially targeted, there is content everywhere. That’s what I have always found frustrating about these kinds of applications, the lack of content and the commitment they require to get a meaningful experience with ubiquitous media. With CrowdScapes i’m pushing something I like to call software by side-effect. My app works because it takes the content from a successful community, Flickr, and using TagMaps/user’s personal popular tags, feeds it to my mobile app. It has content because the users creating its content are not being asked to understand a new paradigm for media sharing. They’re just asked to take photos and document them.

Today i’m realeasing the first WAP version of CrowdScapes, my thesis here at ITP. Originally I was going to write it in Python and make use of cell tower discovery, but I ran into some issues which I have yet to resolve. Not to mention the fact that a lot less people will be able to use the application if it only runs on Python. The mobile web version, which can be reached at http://m.crowdscapes.com, has all the functionality of the python version except for location discovery. You have to tell it where you are, otherwise it’ll assume you are in New York. It supports Flickr authentication using a remote key generation. To get a private key and authenticate your Flickr account against CrowdScapes, go to http://crowdscapes.com/auth. More information on what the application is actually doing can be read about here.

You can also view a web simulation of the application by going here.

For the home stretch of my thesis (it’s all implantation at this point) i’ve decided to return to Python. It’s just much simpler and more importantly, unlike j2me, it gives me access to cell tower information. Now that I am using cell tower instead of GPS for CrowdScapes Python becomes the obvious choice. I’ve got a pretty decent app running at this point. My development has been much more rapid now that I am not jumping back and forth between coding the client and server side. Instead I have the server generating dummy content and i’m only concentrating on the client. The cool thing is I have the server generating python like so:

[(u"city", u"San Francisco"), (u"state", u"California"), (u"country", u"USA"), (u"zipcode", u"94107"), (u"lat", u"37.7667"), (u"lon", "-122.3958"), (u"ok mister"), ]

And then running an eval directly in python on the string. Very cool.

This slide is from a presentation by Danah Boyd on the general breakdown of tags (on Flickr?). Although the beauty of tags is that they are ‘dumb’ in that they do not fall into any predefined categorization system nor do they have an individual weight or value, according to Boyd they tend to fall into these categories. Tags democratize because they are an individual voice yet they have value in aggregation and it might be interesting to break down the tags i’m working with along these lines. This would have to be done manually so it’s only practical for a few experiments but might give some insight.
Link: Paper on Flickr Taxonomy

I’m very excited, this just might be exactly what my thesis needs. I’m going to a two day seminar on Nokia’s open source project, Mupe. Mupe is a cell phone publishing platform that removes a lot of the annoying overhead required to develop J2Me. The handset market fragmentation, unsupported JSRs, certificates, etc. All the stuff that keeps me busy and not doing the fun stuff. From a quick glance, Mupe allows you to write the logic and social behavior of your application on the server side. The client, deployed only once, just downloads the new version of the logic and your users have the latest version of your app. The key will be to see if I can get most of my application’s functionality replicated within Mupe. Image transfer, XML and GPS access. Even if it isn’t natively supported the whole thing is open source so I should be able to figure it out. Very cool.