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!
