Chris Messina wrote a fantastic article describing the inevitable future that’s ahead of us for location based services. I posted some thoughts on the topic in his comments, and I decided, while link-loving his blog, I’d reproduce my comments here:
In keeping with Lisa’s theme, I want to talk a bit about the topic of attention management.
A week ago, I declared information bankruptcy.
Information bankruptcy is a more generalized form of email bankruptcy and RSS bankruptcy. I have too much content to keep up with. I have 96 people I follow on twitter (low by most affluent standards). I have 73 friends on facebook (again, low). I follow the life streams of a dozen people. I’m on livejournal, flickr, yelp, upcoming, eventful, tumblr, delicious, wordie, pownce, linked in, myspace, last.fm…the list goes on. By declaring information bankruptcy, I stayed away from all of these things for a week with the intention of rethinking how I consume data when I return.
This is a quick announcement for the first release of a strongly typed Fire Eagle .NET library. You never have to deal with XML or any OAuth, and it handles hashed, secure requests like it should. This project was submitted under VS.NET 2005 and uses the .NET 2.0 framework. There is still a lot that I would like to see this library handle, but it’s reached the point where it would be beneficial to give it to the community for testing and feedback. Read the rest of this entry »
Last week, Yahoo launched Fire Eagle at ETech. Fire Eagle is a platform for sharing location information about yourself. The most powerful piece of this service is its privacy consciousness. Users who publish their location via this service have very robust controls regarding how third party applications access to their data. While not much value on its own, Yahoo is hoping that community developers (like Technarium!) will step in to provide novel uses of the service via their API. Read the rest of this entry »
Liberatr is Technarium’s rehearsal. It’s a first read-through of the script to see what works and what doesn’t. Our work flow is experimental and part of what makes the company unique. As such, the process was almost more interesting than the tech (almost, but not quite!). The release candidate contains 1573 lines of original code, and took 6 months to complete.
What worked
The UI. Creation of the UI was a collaborative effort between myself, Lisa, and a white board for three hours. The final interface did not change from what we drafted in those three hours. Very rarely does that happen in development, and we created a flexible interface that accentuates our feature set.
XML files for storing metadata. Taking advantage of .NET’s built-in serialization techniques, we were able to quickly make human readable files for each downloaded set that contains all the metadata we pull from Flickr (or any other source in the future). This was another early design decision that turned out well.
Design Philosophy. Technarium is built on the principle of “apps you love to use.” We create small, innovative apps that fill an essential need in the community they target, and we wrap these features in elegant interfaces. The conception phase of this project worked perfectly.
What didn’t
Inefficient testing pipeline. Testing many features was a slow process, and because of the nature of flickr accounts, testing upload functionality was difficult at times. We also had no written test plan, and several times encountered regression bugs. We didn’t have a very efficient flow or schedule for builds, and getting them to the testers took time.
Object hierarchy isn’t as clean as it should be. Image management is deceptively complex. We originally built our object hierarchy similar to Flickr, but we discovered later that this model didn’t easily support certain operations. We wasted a lot of time recoupling objects. This could have been avoided if we spent more time in the beginning exploring the actions we’d need to perform, both in this iteration and in the future.
Confused purpose. Our feature set got a little muddled toward the end, because this Liberatr is part synchronization tool, part backup tool. We’re also waiting to see how the community receives the app before we decide which way to continue developing: sync or backup.
API. Liberatr relies on the Flickr API and the Flickr.NET wrapper. The wrapper behaves badly in some cases, like when Flickr’s API returns null sets. For future work, it will be worthwhile for us to lend some development muscle to the API projects. It benefits us, and it’s a way of saying thank you to the projects that assist our work and the work of others.
Final Thoughts
As a rehearsal, Liberatr is a success before we even release. We confirmed that our design philosophy is solid. From here, we will release to the public for feedback before deciding the next step. In the meantime, we will move forward with other applications using the same design principles while keeping in mind the mistakes we made.
Working on this project was a great experience. Thanks to everyone who helped make it happen!
