Lessons learned

David Herzog, 2010-2011 Fellow

We launched OpenMissouri.org as part of my RJI fellowship on March 17, during Sunshine Week. We had 135 data sets and nearly 20 state government agencies listed on the site at kickoff.

Since then, we’ve hit nearly 200 data sets and are continuing to add features (data file sharing and Sunshine letter generator) and otherwise tweak the site.

I’ve learned some great lessons this fellowship year by tapping into the wisdom of my fellow RJI fellows and Columbia developer Jamie Stephens, and from reading “Getting Real,” a book from 37signals, a web software company.

Here are some of those lessons, in no particular order:

• Launch lean. Launching a website is a Herculean (and sometimes Sisyphean) task, especially if your timeline is a few months. When you’re planning, spend some time thinking about what you really need to have for a functional, attractive site. Not necessarily what would be shiny or cool. During planning, we asked ourselves what we wanted Open Missouri, at its core, to do. We decided that we wanted to let people look up information about databases held offline by state agencies and allow them to tell us about data sets they uncovered. We had those features at launch. We’re working on adding other core features, such as the ability for Open Missouri community members to generate Sunshine request letters and share data sets they’ve obtained from agencies.

• Lower the barriers to entry.
  
  

  We’re all competing for users’ time and attention on the web. When we planned Open Missouri, we wanted to minimize the time and effort that users would need to spend. One way we lowered the bar is by asking first-time users to provide the bare minimum information. When users join the Open Missouri community, we ask them to fill out five fields: First and last names, email address and password, entered twice. 

If users want to get the full benefit of the Sunshine letter generator, they can go into their profile settings and provide more information that the site uses to build their return address.

We also had thought about having the site’s community managers approve new users, to cut down on spam-bots registering. But we ditched that because our new-member confirmation process ensures real people are registering. The upside is that new community members can suggest data sets and make Sunshine requests right away.

The biggest goal we had for the site was making it easy for users to look for information about data on Open Missouri. Google’s minimal but functional approach has set the gold standard for ease of use, a comment that came up during a Missouri School of Journalism student-run focus group.

On Open Missouri, we tried to simplify by providing a few roads to the data. Users can search, browse (click on “Data Sets” in the navigation menu) , filter by category or view by agency.

So far, users have said they find Open Missouri easy to navigate, which is music to our ears.

• Don’t be afraid to tear up the plan. This can be scary, at least it was to me when our web developer got a few weeks into his work and recommended starting from scratch. We had initially planned to modify the Sunlight Foundation’s National Data Catalog, an open-source project. When we got into the software, we discovered that the catalog had more features than we needed. So we decided to build our own software using the open-source Rails framework. It was a wise decision because it allowed us to build for our own more narrowly focused needs. 

• Real-world testing. Formal web usability testing can be a great tool for putting a website through its paces and uncovering bugs that you need to fix. But, if you are launching a relatively simple website in a few months, nothing beats real-world testing by a trusted cadre of users, who should range from total newbies to power users. We enlisted users from librarian, journalist and Government 2.0 circles and had them bang on Open Missouri. They found a few bugs and came up with great suggestions to improve the site.

• Work from your vision. Have a clear picture of what you want to accomplish with your web project and work toward it. I found that lots of people are willing to offer advice about whatever it is you’re doing. Quickly sort out what is useful and what is not.

• Find smarter people and listen to them. A huge benefit of my RJI fellowship was being surrounded by my fellow fellows, all bright innovators who’ve had different experiences in and out of journalism. Also, my fellowship allowed me to connect with journalists and information professionals here in Missouri. They are on the front lines of the ongoing struggle to keep government open and offered lots of valuable input. Many of the people I sought and listened to were outside journalism, including people working in the Government 2.0 and tech spheres.

• Over communicate. When you’re working with a web developer, you can never have too much clarity. Especially when you’re batting around a lot of great ideas that you might not execute. We used 37signals’ Basecamp web-based project management software to keep track of files, messages and the always morphing to-do list.

• Last, have fun.
  
  

  Not saying that web development doesn’t have its light moments, but things can get pretty intense and frustrating. At one point, when we were batting logo ideas back and forth to what seemed to be no avail, I decided to whip up my own, using the Black Power fist. It was a great way to break the tension.