Zampus

November 8th, 2008

The reason it’s been so quiet around here lately is because I’ve been doing something I swore I’d never do: working at a non-freelance full time salaried job.

I started working at Zampus (a local web development start-up) in August. At the beginning I worked four days a week (I had a few freelance projects I wanted to finish up) but I quickly moved to doing full time work. The hours are flexible, which is nice. I started out coming in at 11 and leaving around 7 but I soon got tired of not having much free time in the evenings, so I slowly worked my way earlier towards my current 9ish start time. I’m not much of a morning person, so it took some time to adjust my internal clock, but now waking up early is much easier.

The transition from having so much freedom in the ways that I work into a more structured environment was less challenging than I expected. Part of this I can attribute to the casual and flexible nature of Zampus. Being a small start-up lacking all of the overhead of a traditional corporate bureaucracy, we can focus more on what we need to do and let individuals complete tasks on their own terms. Training my attention span to last 7-8 hours and adapting my work habits accordingly were the most difficult parts. Doing freelance projects, I usually didn’t work for more than an hour or two at a time, and I’ve adapted this style to Zampus work by switching tasks about that often to keep myself from getting stuck in ruts. Trying to find a middle ground between all of the developers’ different coding styles and skills has been tough as well, but now I’m starting to feel like we’re finally becoming a well-rounded and cohesive team.

When I started this job, we were spread across a few projects, but since then we’ve focused all of our efforts on our namesake, Zampus.com. It’s an “insider’s guide” to college life. Part review site, part forum, part video sharing site, and much more. The site is built around “entries,” which can be anything from local restaurants to TV shows to fraternities to whatever else college students have on their minds. Instead of encouraging users to create certain types of content, we provide a basic structure and let the content evolve naturally. Users can attach photos, videos, maps, and more to entries, and categorize them with tags. Entries may have one or more “definitions” (this term might not stick) that can be provided by any user. This usually amounts to reviews or personal opinions of whatever the entry happens to be about. Right now we’re Cornell-only, but we’ll soon begin work making the site expandable to other colleges and universities, without losing the community feel for each school.

The site currently runs off a Fedora server and is coded in PHP. Our data lives in a MySQL database (except for images and videos). The frontend makes heavy use of AJAX to provide a dynamic and free-flowing user experience. Unfortunately, this means javascript is required to do anything except basic actions—which goes against my progressive-enhancement instincts—but I’ve been justifying this by keeping our target market in mind (who almost always browse the web from a javascript-enabled browser) and making sure that accessibility sacrifices are only taken where real usability gains can be had.

Since starting, I’ve moved up to a CTO/CIO position, which puts me in charge of two full-time developers and several part-timers. Being in a managerial position is a big change for me, and I’ve learned a lot about how to mediate different development styles and skill sets. I still spend most of my day coding, but I also have to keep track of what everyone else is working on and the state of individual features/bugs/modules/etc. It’s crazy to think of how quickly I went from working for myself to having other people work for me.

Anyways, we’ve just finished up our alpha version, and are starting user testing. We’re using this cool program called Morae that captures on-screen actions and uses a webcam to record facial expressions of the tester. The first round of testing is 20 people and isn’t quite feature-complete. We’re going to use the results of the test to improve usability and decide how to implement the missing features, and then do two more test/development cycles first with 100 then 1000 users. Hopefully by the end of all this we’ll have a polished and intuitive application.

If you go to Cornell and want to help us with testing or anything else, the first step is to take our user survey.