Now things start to get interesting.

For graduate students majoring in new media, Medill's one-year academic program ends with one of our "innovation project" classes. These are team-based classes in which the students are challenged to create a new digital or cross-media product. Sometimes these classes seek to apply proven technologies or business models to a problem faced by a real media company; in other cases, we explore emerging technologies to develop new insights for journalists, media companies and journalism education.

Our latest new media innovation project -- which includes the first Knight programmer-journalist scholarship winners, Brian Boyer and Ryan Mark -- is now off and running. There are six students (in addition to Ryan and Brian: Angela Nitzke, Joshua Pollock, Stuart Tiffen and Kayla Webley.)

I've challenged the team to look at improving "conversations around news" -- to use digital community-building tools to enhance people's connections to their local communities and to news and information about those communities. If the class is successful, the students will develop new ideas for building these community connections -- and a new Web site or service that brings those ideas to life.

Here are the high-level goals for the class:

• To understand the ways that journalism has historically helped enable civic engagement and provided a forum for conversations around news.
• To understand the nature of people's interactions online and to apply that understanding to local communities and the role of media in a democracy. 
• To develop recommendations on how to approach news, online conversations and civic engagement. 
• To develop software prototypes for enhancing online conversations and engagement. 

Our laboratory will be Cedar Rapids, Iowa, home of Gazette Communications (which, among other businesses, owns the city's daily newspaper and ABC affiliate). The Gazette is sponsoring the class in hopes that our students provide some ideas for doing a better job of connecting with people in and around Cedar Rapids, which suffered devastating damage in June as a result of a record flood.

The students convened for the first time on Tuesday, Sept. 23. Here's what they've done so far:

• Decided on goals for the class (for instance, "create something people will talk about," "think big," "create something people will actually use" and "have a good time");
• Done some teamwork and collaboration exercises designed to improve their capacity to work as a team;
• Traveled to Cedar Rapids for two days to learn something about the community, the newspaper, Gazette Communications and the aftermath of the flood;
• Read a variety of relevant materials, including the "Online Community Cookbook" (which I wrote for the Newspaper Associaton of America), Jonathan Alterman's "Out of Print: the death and life of the American newspaper" (from the March 31, 2008, New Yorker), excerpts from David Paul Nord's "Communities of Journalism," the Newspaper Next 2.0 report, "Making the Leap Beyond Newspaper Comapanies" and selections from the recent "Audience Segments in a Changing News Environment" (report issued by The Pew Research Center for the People & the Press).

Gary Kebbel of the Knight Foundation has said that he wants readers of the Idealab blog to be able to follow Knight News Challenge projects as if they were looking over Thomas Edison's shoulder as he was inventing the lightbulb. I like that analogy, and the class -- similarly -- will operate a site that will give outsiders a view of what they're doing. (Input and ideas are, of course, also invited.)

You'll find the class's site at Crunchberry Project. Why the name? When we visited Cedar Rapids last week, one of the city's most notable attributes was this: It smells like breakfast cereal. That's because Quaker Oats has a large manufacturing plant right on the edge of downtown. We don't know for sure what products Quaker makes in Cedar Rapids, but the students thought they smelled Crunch Berries, one of Quaker's cereals.

You're all invited to join the students on their journey.

If you know of a Community Technology Center, Public Access TV station, University Media Program, or other non-commercial, community media outlet who may be interested in participating, please invite them to apply at http://deproduction.org/ombeta. They can read more about the program there, or on the Drupal Group, http://groups.drupal.org/open-media-project.

As requested, we've discussed the project with the early applicants and, in an effort to be entirely open and transparent, are providing some early feedback on our appraisal of each organization's fit for this Beta program. Below are the 11 groups who have submitted an early application, together with our evaluation of the strengths and weaknesses of each as a potential participant in this Beta program, as well as our request for any additional steps we'd like each to take. We hope this feedback will allow some groups to move forward in their process with more clarity, and will also provide guidance for those on-the-fence as to what steps they could take that would make their application stronger.

We've separated the applicants to-date into 4 groups: "Already-Started", "On-The-Fence", "Needy-But-Appealing", and "Best-Served-to-Wait".

Already Started: The first group includes two groups who are already clearly headed down the same road, with not only a commitment to, but clear action towards, each of the 3 "requirements" of the OM Beta program: All-Digital workflow, increased community involvement and control, and Drupal development capacity.

Amherst: http://actvamherst.com
* * PROs: Hiring web community media coordinator, high bandwidth capacity, investing $23,000 in upgrading tightrope system
* * CONs: Very basic, non-drupal website, externally hosted, Don't seem to be proactively collaborating with other PEG2.0 stations in development efforts
* * Request: Support integration with Tightrope. Hire & train webmaster immediately, Provide support for Worcester, BNN, and other MASS groups interested in collaborating on a Drupal network

Humboldt: http://accesshumboldt.net
* * PROs: Upgrading to new Princeton Digital server, High Bandwidth Capacity, hiring part-time websmaster, able to allocate additional funds
* * CONs: No internal webserver, need to develop internal server combined with external media storage for VOD
* * Request: Need to allocate funds to set up their digital workflow immediately. Provide support for nearby CA Access groups interested in collaborating on a Drupal network

On-The-Fence: The second group includes 5 stations who have a clear commitment to some or all of the 3 "requirements", but are not actually moving forward on at least one of them. Our hope is to work with groups who are already headed in a similar direction, as opposed to waiting for (or depending upon) this program to bring them there. Our support will not be sufficient to carry a station through this digital, user-automated transformation. Some of these groups (especially Portland and Vermont) are far ahead of Amherst and Humboldt in some areas, but behind in others.

CCTV Vermont: http://cctv.org
* * PROs: Has overlapping grant and goals, Local webserver, drupal website, strong team of contract Drupal Developers,
* * CONs: OM System is designed for widespread Public use, user-generated content, only useful if CCTV is headed in that direction. User Ingest? User QC?
* * Request: CCTV is the strongest applicant in the group, but only fit if they are interested in the community playing a larger role in the station, which may not fit as a G station. Need another brief conversation.

Portland: http://pcmtv.org
* * PROs: Has overlapping grant & goals, has funds to devote to development, training internal drupal staff member, actively communicating and interested in collaboration
* * CONs: Currently on Dreamhost, no local webserver, Fiber on its way, but not yet setup, playback system is unfamiliar to us & timeline for replacement is delayed
* * Request: Establish high-speed internet connection, internal webserver, initiate new digital playback system as planned. These steps have at-times taken stations years to implement, but if they are done soon, Portland is among the strongest applicants here.

Austin: http://www.channelaustin.org
* * PROs: Plans to upgrade to new digital playback server, Large Cap Equipment funds available, commitment to being an interconnected community media center, convenient location (since we're going to SXSWi)
* * CONs: External website, Cable Modem connection, Synergy playback
* * Request: move to digital playback server, upgrade web connection, identify/hire drupal expertise

Urbana: http://www.city.urbana.il.us/urbana/finance/is/uptv/Main.asp or http://urbanapublictelevision.blogspot.com
* * PROs: Connected to fiber, building a network of community organizations on their fibre network, internal webserver,
* * CONs: No internal web staff or Drupal development capacity, no physical facility, no Drupal website (using blogspot)
* * Request: Develop internal webmaster/Drupal development resources

Worcester: http://www.wccatv.com
* * PROs: Located near to Miro, Uploading content to Archive.org, willing to devote up to 30% of Capital Budget and 25% of Operational Budget
* * CONs: DSL Modem, No internal web, IT or Network support
* * Request: would need to devote up to 30% of Capital Budget and 25% of Operational Budget and develop internal drupal capacity

Needy-But-Appealing: This third group includes two stations who are similar to the above, but have made less progress towards, and have fewer resources available to contribute to the process. Both are in Colorado, which is appealing to DOM, and would be great examples of how well the model works in the most meager of environments, but its possible that these stations would be best served by using the tools once the Beta-period is complete and we aren't relying as heavily on them to help us develop the modules.

Durango: http://www.dcat.tv
* * PROs: Digital Princeton Playback Server,
* * CONs: No internal webserver, no web staff or drupal management/development capacity, no local broadcast server in facility
* * Request: Would need funds for local support and development of website and OM System.

Boulder: No website currently (no station currently)
* * PROs: close to denver, Knight Community, good example, possible support from Knight
* * CONs: No webserver, no budget, no archive, no channels until city council re-activates them (hopefully in Dec)
* * Request: Submit proposal to Knight Community Grants Program to hire webmaster

Better Served to Wait: the final group is comprised of organizations who are not likely in a position to contribute to the development of these tools, as we're hoping for from each of the first 6 OM Beta participants. Our opinion is that they would be better-served to wait until we have completed this initial Beta period, allowing the other participants and DOM to further develop the tool-set such that it is better-suited to implement in environments with very limited resources.

Genesse:
* * PROs: One staff member with good technical skills, developing a media center
* * CONs: No Digital workflow, low bandwidth, no website, no webserver, Not ready to contribute to development of these tools at this time.
* * Request: Get prepared to adopt these tools in fall 2009 when they're more established.

Dekalb: http://www.iogcyvc.com
* * PROs:Good support from Comcast
* * CONs: no website, no local webserver, not located in the Access Center, incomplete proposal
* * Request: Get prepared to adopt these tools in fall 2009 when they're more established.

I have a long list of things to polish, add, tweak, revise, and rethink, but it was time to open the site up to users and let them help me figure it out.

Last time I wrote about the options I was considering for Web development, I was leaning toward Django and away from Drupal.

Here's why I gave up on Drupal for this project and moved on to Django:

Drupal is a fantastic content management system out of the box, with little -- if any -- programming knowledge required to get started, but I found it to be extremely difficult to mold into the application I was building.

Did I need the structure Drupal came with for users, posts, archives, feeds, and comments? Probably. But there was a whole bunch of other baggage, like all the WYSIWYG block and module organization that I wasn't as comfortable with. My first instinct was to start from scratch and build my own theme, but I quickly realized I needed to build my own content types. And views. And the file system was confusing to me, coming from WordPress. Plus, although the Drupal community is full of awesome people building awesome modules, I still couldn't figure out how to do a few simple things, like create a content type with a maximum length (say, 140 characters).

On the other hand, as soon as I started digging a little further into Django, I found an active community of developers working on projects similar to mine.

Why? Is it just because Django is still new and shiny? Maybe. But the fact that developers interested in services like Twitter and Friendfeed were building their own tools in Django with similar functionality made all the difference as I looked for open source projects and pluggable apps to incorporate into ReportingOn.

Here are a few of the Django applications that have been involved in my development process in one way or another:

• Finisht: Nick Sergeant's "done" list for "developers who do things." (On Google Code)
• Pinax: James Tauber is the lead developer on this project, which, frankly, is pretty all-encompassing. If you're seriously considering building any sort of social network or content management system in Django anytime soon, I highly recommend you take a close look at all the work that's already been done on Pinax before you start reinventing any wheels. Check out Cloud27 for a demo of what this system is capable of with all its bits active. (On Google Code)
• Django-Tagging
• Django-Profile

Plus, the Django community and my own network of online friends and acquaintances has an enormous amount of overlap, so I've been inundated at times with offers of help, hints, tips, and flat-out answers to my questions about Django.

The Drupal commmunity? I certainly know a few people there, but without an exception that I can think of (correct me, please), they're developers first, and journalists second. Which is fine, except that I'm really trying to maintain ReportingOn as something built by journalists, for journalists.

Why? Well, while a primary goal of mine is to make ReportingOn a repeatable process -- in this case, a relatively self-contained Django application that anyone can run on their own server -- I'm really trying to make this something repeatable by journalists with little programming experience. And that describes me, too. I have a few years of experience working with WordPress and other platforms, but most of the "programming" I've done has been strictly copy & paste, trial & error.

In fact, I expected the "programming" part of building ReportingOn to be far more difficult. In July, when I told Adrian Holovaty I was seriously thinking about using Django for my project, he said: "I didn't know you were a programmer." My response: "Well, I'm not. I didn't think you had to be." And Adrian suggested a book about learning Python called "How to think like a computer scientist" that I haven't read yet, because I've had an easy time of picking up bits of Python by reverse-engineering other applications and walking myself through every tutorial and screencast that I've found.

It wasn't that hard to wrap my head around Django's file structure, or the model-template-view pattern. Frankly, it was harder to get certain accessories to Python running in a development environment on my laptop, but once I moved the app to a production server at Webfaction I had much, much better luck.

None of this is to say I'd recommend against using Drupal for any number of projects. 12seconds is one of the most impressive things I've seen built in Drupal, lately, and it certainly doesn't feel like Drupal when you're using it.

But for me, as a proof of concept that a journalist with just a little programming knowledge can build something interesting on a low budget (all I've paid for so far has been Web hosting), assembling ReportingOn in Django was the way to go.

Thank you to our African participants - Samwel Kongere, Kennedy Owino, Fred Kayiwa, Peter Ongele, Kofi Thompson, James Njunge, William Wambura, Wendi Losha Bernadette, Joseph Runnel Lule, Betty Kyewa, Josephat Ndibalema and many more! - for giving our Minciu Sodas laboratory such great vitality around the world.

We're impressed at your enthusiasm to overcome challenges - traveling miles to the Internet cafe by foot, bus or taxi - paying $1 an hour or $100 a month - waiting your turn, suffering power outages, slow bandwidth, worrying about coming home safe at night.

One year ago I asked for our help to work on a flash drive editor, a device for our African participants at home to read and write emails stored on their USB flash drives, so they could upload and download them later at an Internet cafe. We now call this the Includer. This endeavor is fantastic and strategic in that it helps us appreciate the importance of many related endeavors and make progress on them all. Similarly, Marcin Jakubowski's open source tractor is a "keystone species" for a whole "ecosystem" of endeavors in appropriate technology.

What have we achieved in this year? Our greatest success is that Ricardo is with us. I learned of Ricardo through his Sneakernet page at the OLPC wiki. Ricardo is a software engineer in the UK. He works with Samwel Kongere, Dan Otedo, David Mutua to set up Internet access centers. He sent refurbished laptops to many of our lab's participants. He solves and documents technical challenges such as how to get online with a phone. He is organizing trading clubs and helping Kenneth Chelimo and others get established on PayPal and eBay. He has written dozens of pages at our wiki and made very concrete the technical options (Bluetooth, PDA, laptop motherboard and so on) for us to pursue for our Includer.

I won a 2008 Knight News Challenge Award to blog about the Includer at the PBS website. Thanks to an idea from Barry Dobyns, I wrote a proposal that online services fund us to develop offline versions. I am very glad for Ed Prentice's help from Silicon Valley, and also I had lunch with Christian Crumlish of Yahoo! and Charles Warren at Google. The world is definitely moving towards simpler laptops and e-book readers. Yet I haven't been able to make the needed contacts to take the Includer closer to reality.

The challenges for our Includer are:

• The market for the Includer is a moving target. Many people might benefit from the Includer, but typically, within a year or two or three, they will have moved on to have their own laptop and Internet access. Franz Nahrada and I observed in Hungary a similar challenge with telecottages, which are very meaningful when nobody has Internet, but within two or three years they generate a demand for Internet at home, which can make the telecottages not so relevant.
• We don't have a leader in Africa to champion the Includer. We know from our African participants that it's a worthwhile idea. But they are finding ways to get computers and get online (often thanks to Ricardo!) So we have to consider who in Africa cares about the Includer and why.
• I haven't been able to make corporate contacts with budgets who might pay us to develop interfaces or to organize large global teams. I spent five weeks in Silicon Valley but didn't get very far. However, we are getting more participants there. We need a corporate strategy - if there was a company with five Minciu Sodas participants, then we would surely get paid work. If we keep writing our dreams and identifying who we'd like to work for, then we can work across our network to make the links (through LinkedIn, FaceBook, events) and organize independent thinkers in corporations.
• We don't have a hardware team or even a software team. We'd like to have students, retirees or other enthusiasts who we could send hardware parts to for trying out small projects. There's a lot of software that we could develop and try out. We also need a project leader. Ricardo doesn't want to make that commitment.

I thanked Ricardo and asked him what he's found most fun and meaningful. He's very excited about his work with Pamela McLean and John Dada. Pamela is traveling in Nigeria and she is forming digital camera clubs there. Ricardo is preparing a photo editing course for them. Ricardo is a photography enthusiast. Pamela has linked a class in a Nigerian school with Steve Thompson's class at his school in the UK. Everyday they are exchanging a photo and a caption, showing to each other their everyday lives. This is very exciting and shows how David Mutua and others at Teachers Talking are reaching out to include other Africans into our online world.

Ricardo and I agreed on four priorities, in the order below, for our work on the Includer and marginal Internet access:

1. What would you like to share online? We want to encourage our African online experts to reach out and include more people. William Wambura in Tanzania teaches the children. Fred Kayiwa in Uganda leads a soccer team and has relatives in the village. Wendi Losha Bernadette links us with women in Cameroon. Samwel Kongere is training women at an ICT center in Kenya. Involving them would make our network much more valuable. How would they like to participate online? What groups would they like to engage? What kind of software or hardware innovations would be helpful?
2. What is the business value of such people with marginal Internet access? Who might value our work as individuals or large teams? What can we do useful online and offline? What markets might we foster?
3. What are new technical solutions that we might develop and promote? Ricardo thinks of many, including broadcasting data by FM radio from community radio stations (I note also One World), or having a large display that works with a mobile phone by Bluetooth (see Jeff Hawkins's Foleo and also netbooks, there are more than twenty of them).
4. What technical skills (hardware, software) might we encourage in Africa and around the world? for building Includers or even open source tractors? and how might we help and organize open source hardware makers?

I encourage us to write about all of the above, but especially reaching out and including those further out. Our next step is to survey our African participants about how they access the Internet. I am still looking for a smart way to set that up online. I have set up a Ning social networking site which I invite us to join. I will try to set up the survey there (I found this software). Then we will know the kinds of people we are reaching out to, the kinds of uses for the Includer, and the different kinds of Includers we might work to develop.

Thank you all for inspiring us and including us!

The first time I started paying attention to this trend was about a year ago when Nate Ritter of San Diego created a Twitter channel to provide up to date information on a series of wild fires that ravaged Southern California.

More recently, and in response to hurrican Gustav, Internet activist and a social media strategist for NPR, Andy Carvin, put together an independent Hurricane Information Center on the fly. The site was a grassroots effort that soon gathered momentum among other tech savvy volunteers as Gustav's more menacing cousin Ike came on the scene.

What makes Carvin's effort particularly interesting, other than the fact that it was built on a social networking platform (Ning) and has more Web 2.0 bells and whistles than you will likely find on any mainstream media site, is it's spontaneous and completely voluntary nature. It wasn't created by and for NPR, or any other major news network, and yet has some of the best information and features for people impacted by or following major hurricanes in the United States. it integrates up to the moment national weather service information with local reports of people on the ground, shows maps of hurricane locations, and helps people find immediate assistance through zipcode based tracking tools. After Ike touched down, it streamed useful ads from Craigslist with offers of assistance and housing for hurricane victims. And the site is ready to go for use in up and coming storms.

The Hurricane Information Center is not pretty from a user design standpoint, but the array of information and services provided is extremely impressive. And without any apparent resources besides some technical expertise and a commitment to get people practical information ASAP, it is exactly what you would expect for last minute, community-driven project.

So is the Hurricane Information Center a bell weather for a new kind of citizen journalism, and are we likely to see more of this happening as average do gooders leverage free and open information sharing and reporting tools to help people locally, nationally and internationally in times of crisis?

Finally, what other examples of "Citizen Journateerism" are people aware of and is there a different or better name for this stuff?

You can check out the results here.

There are a couple of things that got me excited. First, I just find it visually engaging. Next, it involves an unusual collaboration between comic book artists, a blogger, and online developers to produce something distinct. On a personal level, it warmed my heart that a "newspaper" was trying something this daring.

Some folks may shrug, or dismiss it because it involves comics. But while I've never been much of a comic book reader myself, I've seen some amazing uses of the form to produce some really interesting journalism in recent years.

One of the most dramatic versions of this is a full-length, comic book documentary called "Palestine" by Joe Sacco. I saw Sacco speak a couple of years ago at the Nieman Narrative Conference in Boston. Essentially, he spent months in Israel and the West Bank trying to see first hand what was happening there. He then told his tale in comic form. It's powerful stuff.

More recently, there have been a couple of notable uses of comics to tell non-fiction stories. One was by The Globe and Mail in Toronto. They produced a full-page comic to explain the current fiscal crisis. I first saw this via Juan Giner's blog:

Another comic that got a lot of attention recently was one produced by Google to explain the technology behind its Chrome browser. The comic was produced by Scott McCloud:

These projects are good reminders that innovation doesn't just have to be about embracing the new digital tools (though they played a big role in this case). It can also involve working with new people or groups that you don't usually collaborate with. And it can include finding new ways to tell stories that embrace older forms, such as comics.

I've been keeping an eye on The Takeaway for the same reason: I'm really interested in whether they'll be successful in fostering a community of listeners who contribute meaningfully to the show. I'm still not crazy about their format, but their website is constantly in motion and they do seem to draw substantive and interesting insights from listeners.

So I was tickled to see The Brian Lehrer Show, an NYC talk radio staple, launch a wiki for their traditional election year 30 issues in 30 days series. I think the structure they've settled on will take a lot of care and feeding if it is going to stay manageable, readable and useful. I'm genuinely interested in seeing whether an audience that is so used to sparring in comments can collaborate to develop intelligent questions and perspectives for the shows.

Deproduction has assembled a stellar Drupal Development team since being awarded the Knight NewsChallenge award, and they are making significant progress towards the first benchmark of our process: developing a robust set of custom Drupal Modules, ready to deploy in our beta-test group of 6 Public Access TV and Community Technology Centers across the US.

Participants include Free Speech TV, OurMedia, KGNU, LinkTV, the Media and Democracy Coalition, and dozens of Public Access TV stations and CTCs from across the nation. Its not too late to get involved, participate in a panel, or register to attend. For more information, please visit accesswithoutborders.org

Tony Shawcross

After three months of working with conceptual mockups and user interface flows, we're finally able to click through a set of Web pages connected to a database that generates simple magazine-style PDF files. In the coming weeks and months we'll be sharing more of that with you, starting with videos and, as soon as possible, prototypes and betas that you can play around with to provide feedback. None of these will be the final application -- which launches in March -- but they will allow us to work with the larger community of people who have an interest in Printcasting to help us make the final product that much better.

In the meantime, I'd like to share a little about the team we've assembled that's making this happen, and how we're getting from point A to Z. I'm excited to put the spotlight on them because I know that they're all extremely excited about Printcasting and want it to be a big success. We want everyone to feel a sense of ownership of Printcasting because it's an open source project. That begins with the people I mention below, but you can also get involved (more on that later).

Transition Plans

The hardest and most important thing I've done this year is build a new team while transitioning from my other duties. For those of you who are just now entering your ideas for next year's Knight News Challenge, take note. The planning process for your transition should begin in your head as soon as you fill out your entry form. We started our planning in February of last year when we learned that The Bakersfield Californian was a News Challenge finalist.

While Printcasting was proposed by three of us -- myself, Justinian Hatfield and Mary Lou Fulton -- it quickly became clear that we couldn't all drop what we were doing to make it happen. And we felt that it was paramount to have at least one full-time staff person responsible from start to finish. I began the emotionally difficult job of planning my eventual exit from the exciting social media work I helped start at the Californian back in 2004.

Fortunately, Justinian was ready and willing to step into my shoes, and he remains a trusted Printcasting advisor, stakeholder and friend. And Mary Lou has been incredibly helpful in an oversight role for the company. She will be even more involved in the second phase, when we launch and market Printcasting in Bakersfield.

Finding the Lead Developer

Printcasting sounds like a simple idea, and to the user it will definitely feel that way, but underneath it's a complicated piece of software with a lot of moving parts. While it uses an open-source foundation (Drupal), the most essential components -- the ones that create a magazine using variable content -- are custom code.

We knew that we'd be best off with a full-time staff developer. We found the right mix of skills and passion in Ron Robinson, who had done some contracting work for the Californian starting in January. At his previous job he built a system that lets people create print layouts for books that feature their own photos. He was truly the right person for the job at the right time, so as soon as we got word about our grant we extended him an offer.

Crafting the User Experience

All the rest of our budget (the majority of it) is for contractors. Our most urgent need at first was for conceptual mockups to help us think through the user experience. I began putting out the word for user interface designers as early as March. While we talked to a lot of qualified individuals and firms, I ultimately decided that I needed someone who I knew would understand the vision of Printcasting.

Tom Dellecave, an old colleague from AOL who now operates his own company Second Wind Media, did a great job creating an initial UI. You can see his work in the concept presentation in this video on Printcasting.com.

At this time we also began to think more about the visual look, feel and layout of the PDF magazines and newsletters Printcasting would generate. This is an area where The Bakersfield Californian has a lot of talent, and I was fortunate to get some initial help from staff designer Glenn Hammett.

Writing the Code

During this time, Ron was poring over a 55-page Product Requirements Document I'd written and attempting to fit that into a technical architectural plan. Around the middle of the summer he'd settled on using the Drupal framework, based on its modular architecture and large and growing community. We began putting out feelers for PHP developers with experience in Drupal who could work with Ron as a virtual development team. After once again talking to lots of different companies and individuals, including five which provided proposals based on our specs, we chose Photon Infotech out of Chennai, India.

Before now, the furthest I'd ever personally outsourced anything to was Canada. Working with a company on the opposite side of the globe was and still is new for everyone on our team. After one month we're very happy with the knowledge, commitment and responsiveness we're seeing from Photon, and I'm surprised to find that the Indian developers at Photon are more communicative and customer-focused than some U.S.-based developers we talked to. And while this isn't the only reason we chose them, it's also really great to know that we're getting two full-time developers working on Printcasting for the same cost as one half of a developer in the U.S. or Canada.

I should also mention that having our own full-time staff developer who manages the contract developers gives us the flexibility and confidence to outsource in this way. I feel strongly that it's important to keep the vision of a product very close. Once you have the right core team it makes sense to fill in the holes with contractors whose physical locations are less important.

Designing the User Experience

Once we chose Drupal, we knew we needed someone who could translate Tom's conceptual thinking into designs that would work on any Drupal site. And aside from that, we needed a designer who could create everything from the graphics, templates and themes that Drupal needs to the content and ad templates that Printcasting will generate.

When I stumbled across Don Hajicek, formerly of Boulder Drupal shop pingVision, I knew I'd found someone special. You will get to see Don's work soon, but let me just say that sometimes I think he understands the value proposition of Printcasting better than I do. Perhaps this is to be expected of someone who started out as a print advertising designer in Chicago, competed with his local newspaper using what we now call a "hyperlocal" Web site, and started his own Web design firm.

Don will subcontract as needed to Greg Hines, a developer who understands the ins and outs of Drupal themes and architecture. Both Don and Greg are very involved in the Drupal community, which excites us because they'll be able to help us spread the word about Printcasting to thousands of Drupal sites when it's provided as an open source module.

What's Next?

Thanks to all of the people above, we're now finally hitting a running stride with Printcasting. Among our next milestones are to release a rapid prototype for feedback, launch an alpha before Thanksgiving, and release a series of increasingly open betas between then and February. That will give us plenty of time to polish the edges and -- who knows -- maybe even squeeze in a few extra features before we launch in Bakersfield on March 2.

Join the Team!
I've talked a lot about our team, but it's a lot larger than the people listed here. Do you want to help shape the direction of Printcasting? Join our team of advisors on the Printcasting.com social network. We'll be using the site as a launching pad for testing and feedback. There are 102 members already, and there's always room for more. The more input we get over time, the better the final product will be when we open source it. Hope to see you there!

As one of the very early members of the Online News Association, I've attended my share of ONA conferences over the years. This year, I wasn't able to attend the annual gathering that ended in Washington, DC, over the weekend. Instead, I spent most of last weekend at TechCrunch50, a technology conference in San Francisco now in its second year put on by TechCrunch, one of those upstart startups that may put the San Jose Mercury News out of business some day.

Reviews of the ONA conference have been mostly positive, especially for the keynote delivered by my friend and fellow tech blogger Robert Scoble. (To get a glimpse of the future of media and Web TV, watch his talk here or read his Q&A with ONA here.)

But I wanted to mention one of the more intriguing startups I came across at TechCrunch50: iamnews, a small outfit run by an Israeli, Nir Ofir (above is a shot I took of him last week). The site took the top People's Choice award at the conference.

Ofir describes iamnews as "a global open newsroom powered by you." (Because it's only as open as each publisher wants to make it, perhaps a better way to describe it is a DIY, or Do It Yourself, newsroom.) The site says it's geared to "independent reporters, photographers, media moguls and anyone who wants to connect with reporters from the world and collaborate in the creation of news."

Alas, the site is still in a closed alpha and is seeking investment capital, but what Ofir showed me was impressive. It has the makings of a modest content management system, giving publishers or editors the ability to designate members with certain roles (assignment desk editors, reporters, etc.) and a workflow queue similar to the editorial review process in a newsroom, as well as Web 2.0 features such as reputation systems for citizen journalists.

The goal is not to become a stand-alone destination site but to power blogs and citizen media sites that want to bring paid or volunteer contributors into a more structured editorial publishing environment. The site, Ofir told me, is for bloggers and publishers who don't have the resources to start their own full-fledged news site.

Ofir writes on his site:

The Web is the Newsroom

I believe that the Internet of today is already a global newsroom, and we all take part in it. Video sharing, photos, blogs, and social network platforms are our tools for creating news. The most current example of this were the recent reports of the earthquake in China; reports that were communicated by means of a platform such as "Twitter". These reports preceded formal TV news reporting by the traditional mass media.

However, there is problem with this global newsroom. The content and sharing tools which are available today, (such as we could only dream of three or four years ago) are not sufficiently adequate. The main reason for this is the excess of information. There is so much incoming information that the news networks are unable to screen the material, or select the preferred topics. There is also no current solution for quickly investigating the reliability of this material, or the reputation of its sources. There is simply no way in which to gather the information from so many sources, or effect the collaboration of these sources for the purpose of creating reliable news. Even if this were possible, there would still be no way to compensate the participants for their contributions.

iamnews will try to help remedy those shortcomings in the citizen media ecosystem. (Ouriel Ohayon has an interview with Ofir -- in Hebrew -- here.)

It's comforting to know that, as 20th century media empires and business models begin to crumble, there are enterprising folks out there who still believe in the fundamental importance of news -- gathering, editing and distributing the news -- to our lives.

Much of what they recommended resonates with some of David Cohn's blogs and the importance of being iterative. See for example:

• Eliminating the Fear of Being Open
• Growing a Community and The Importance of Being Iterative
• Starting Small and the Importance of Being Iterative

Some of the top tips from our development launch meeting included:

Start with the low hanging fruit

You want to build an interest and a sense that something is happening around your project from as early on as possible. So do a few things early on which are quite contained and which build this sense of progress - the website, the blog, the targeted deployment of the prototype of the software, etc. That way, even if it takes six months before the full, stable version of your software is developed, people can still get a feel for what you're trying to do, and there is a vibrant, dynamic forum through which people can contribute their suggestions.

Scope viciously

It's tempting to try and cram all of the functionality you want your product to have into an early version. Resist That Temptation. Rather, be deliberate and focussed about what features you choose to be developed in the first phases, and how you prioritise them. If your scope is too broad, your developers will start to lose interest as the process drags out.

Avoid spec creep

Once you've settled on a feature set for a given version of your software with your development team, stick with it. Changing the goal posts during a version, or asking your developers to add "just this one more thing," will make it difficult for your developers to keep their momentum.

Choose your early deployment partners strategically

The best way to build interest around a funky new project is to demonstrate just how funky - and relevant - it is. We've known that we want to engage with a few capable, technical partners to put Freedom Fone through its paces, and to demonstrate it in action in a few different contexts, from very early on. Our launch meeting reminded us that, in addition to the technical capacity of potential partners, we also want to vet them for the type of deployment they'll be doing with it. The more interesting and engaging the content they incorporate into the system is, the more rich and exciting our case studies of their experience will be - and the easier it will be to spark other people's imaginations and interest in the project.

Actively build the community around your project

Freedom Fone will be an open source technology that will depend on a community of developers coming around the project to ensure its continued evolution and usefulness even after our Knight News Challenge funding is over. Some in the group believed we should open up our software immediately, starting with the prototype, in order to build this community from the ground up. Others in the meeting, including Brenda and myself, thought there was merit in waiting until we had at least the full, stable, version 2 of the project developed - in six months time or so. We thought we'd then be in a better position to support project deployments and share our experiences with others in the open source development community. Either way, the group was clear that at the very least, within the last 6-9 months of Knight funding, the software and its code should be fully available - and that we should actively be engaging to generate this sense of "development community" around the project, to ensure that it lasted beyond the Knight funding.

Just start

We have a prototype version of our software that can do about 80% of what we want the first full, stable version of the software to do. The more we can work with it now, before our development team has even started on version 2, the more feedback we'll have for them about what does and doesn't work. And the better we'll be able to inform the spec for version 2 and beyond. There's a temptation to wait until we have the "perfect" version up and stable - but the meeting urged us to just get started with what we have, to speed up what will probably be a steep learning curve.

We've come out of our development launch meeting with our client requirements which we'll be using to recruit our development team and iron down the technical specifications for the next round of development. Tips and suggestions for working with developers are welcome!

The tower didn't fit in the elegant, cabin sized roller bag we'd hoped it would, so we had to put it into my tatty duffle instead. It was quite amusing in the office trying to get everything to fit. Eventually, we settled on opening up the computer and taking off its feet - this meant it could lie down on its side in my bag and be slightly less conspicuous - standing up it definitely looked quite suspicious and I was sure I would be stopped.

I had strict instructions from my colleagues about the importance of clearing the equipment properly with customs in Harare - serial numbers, declaration forms, and such like. We decided it wasn't such a good idea to pack my knickers right next to the computer - since likely I was going to have to take the computer out and show it to the guys at customs. But, much to my surprise, when I arrived at the departure gate, all I had to do was fill in a form and be on my way. No one asked to verify my serial numbers, and I didn't even have to take things out at the X-Ray machine.

In Johannesburg for the connecting flight, we tried to find a different bag to carry the CPU in. We had three criteria: a) must be easier to carry than the unwieldy CPU in a duffel option, b) must by carry-on size, c) must be less likely to split across its seams than the bag it was in. We tried the backpacks at the camping store but they all had these lovely lean aerodynamic lines that made them too sleek for our clunky box. The soft duffels would have at least addressed issue c, but whilst they filled out at the bottom, their openings were far too constrained, so we moved on to another shop.

We completely charmed the woman at the luggage store and she took it upon herself to Help Us Out. We tried a big black pilot's case, a hard pink roller case, a soft paisley duffel, and a gold lame shoulder bag. But, after taking the stuffing out of bag after bag, and trying to cram the CPU into each of them, none quite did the trick. So we settled on some DIY wheels which we could strap onto the duffel. They were about six inches too short for my arm, so I spent the rest of the trip with some kind of odd praying mantis type walk to keep everything balanced. But at least it reduced the beating my legs were taking from the server banging against them every step. And best of all, I was able to glide right through Immigration in France and back out again in Harare without so much as a sideways glance.

I was carrying the full sized CPU because we want to be able to connect Freedom Fone to high capacity E1/T1 style lines using a Digium card, which needs to plug into the computer's PCI slot - the smaller Shuttle we've used as our Freedom Fone server doesn't have a PCI slot, only a full sized tower would. Of course, as someone at the meeting pointed out on the very first night, we could bypass the whole need for a Digium card (and hence the PCI slot and full sized tower) by instead getting an Analog Telephony Adapter - handy, palm-sized gadget that it is.

Wish I'd known that in the first place!

Institutional Problems

Again, that's all true. But collegiate publications don't have the budget to fund innovation like many of the professional papers do. We also don't necessarily have the expertise, the time, or the willpower to actively try to break out of the institutional molds we're stuck in. I think one of the chief problems plaguing the collegiate press is a combination of institutional forgetfulness and inertia.

Every year the people who have been at a college paper the longest graduate, often having established a set of policies and a way of doing things that people continue to use long into the future, even if they are no longer best practices. I understand this happens in a lot of other industries too, but the degree to which it takes place in college newsrooms is highly exaggerated. Students have class, part time jobs, and the newspaper. How do they have time to reexamine the practices and policies they use every day to make them better when they already work OK?

The fact of the matter is that college editors can't sit around and wait for a professional newspaper somewhere to invent an ingenious new way of delivering the news, or break ground on a brilliant new business model. Every college paper has to find the time, energy, and resources to start innovating. Maybe that involves applying for a Knight grant? I'm not sure. But college papers are actually in a better position to reach out to their communities than most larger, professional papers. I think there is a bit of a misnomer out there in the "new media" crowd (of which I am a card carrying member) that simply working on a better website, blogging, integrating video and audio, and adding more interactive content will start to solve the problems of the industry. I think that's largely false.

Community Generated Content

In my opinion everything the new media people are working on equals better journalism, and more accessible content. But it's not enough. Newspapers have to find a way to become central to the exchange of information and ideas in their communities if they want to start making more money. Newspapers need to be more local and more central, they need to offer social network and social bookmarking features, and they need to embrace a certain level of user generated content. That could mean a lot of things, though, so I want to explain how I am going to use my News Challenge project, Populous, to achieve some of those goals.

Right now at UCLA there are something like 800 different student organizations. There are far too many for the students to keep track of, and there is no real tool for these organizations to have a web presence, market themselves, or organize online. There are also no good directories for local shops and restaurants. These are all information needs on campus that need to be filled, and the Daily Bruin is working on doing that through Populous.

The Community News Network aspect of our project aims to provide every student organization on campus with the opportunity to create a website on the Daily Bruin's network. They will be able to do basic things like add members, have a blog, and contribute to a community calendar. Every time they want to do any of that they will be coming to our website.

We're going to fulfill a need on campus by providing this service, and we will also provide our readers a searchable database of the student organizations on campus and create a platform for an all-inclusive community calendar at the same time. And that's just part of the vision. We also understand that we're not the only people that can report on the news going on on campus, and we're never going to be able to cover everything. So we're going to let all of our users create their own blogs on our network so they can write about what's going on around them and in their lives.

An Alternate Business Model?

I think once we accomplish this network, essentially a robust news- and community-focused social network, we're going to be driving a lot more traffic to our website. Will it be enough to increase our online advertising revenue to compensate for our decline in print advertising? Unfortunately, no. That's where another philosophical decision we've made at the Bruin comes in: to use our website to generate support for, and interest in, our print product. They are going to have to work together and complement each other. My hope, and intent, is that once people see the Daily Bruin making more of an effort to engage the community in its news coverage they will be more interested in picking up the print version of the newspaper.

We are also going to redesign the print product to incorporate some of the community generated aspects of our website, and retool it to make sure the news and style of the print product complements, but doesn't repeat, what's online. But that's a whole new entry. My plan to increase the Daily Bruin's revenue has two prongs: one is to support our current business model with increased community interest and through our web presence, and the other is to flip some of the features we're working on into alternate business models.

Hopefully this approach will work out for us, and maybe other college publications can adopt it and start doing better financially. But it also concerns me that we're one of the only college newspapers thinking like this. We might be right, but we might not be, and the more people that are working on these issues the better.

While New York City busies itself posting PDFs of city agency documents within 10 days of their publication, the District of Columbia's Office of the Chief Technical Officer is churning out no less than 261 live data feeds and maps, and has mandated that no city agency may acquire software that cannot publish to the data warehouse.

Two hundred sixty one and growing, while the British Government's Power of Information Task Force is sponsoring a contest with a $35,000 prize to the best idea on "how to reuse, represent, mashup or combine the information the government holds." To get folks started they've put together a comprehensive list of public data sources in the UK.

The data that Washington DC makes public is the same data that city agencies use internally every day. Unfortunately, it seems to be so obvious to the current administration that this is public information that they don't have many insights about how other cities might find the political will to follow suite. One interesting observation: that DC has managed to sell the data warehouse as a way that the city can retain control over data. By providing the data as feeds that civic projects can re-purpose, the city has the power to correct data and see those corrections percolate out in a way they never could with figures published in hard copy.

Other tasty morsels from Websites Without Walls? NPR's API is up and running and mighty robust, Stephanie was the most used word in congress on Monday.

In an effort to train our ears and give our digital audio editing fingers a work out, we've been recording some audio at a few public events.

A few lessons we've learnt along the way:

1. If you're at a public event with a sound system, make friends with the sound engineer

At a discussion evening at Harare's Book Cafe on 21 August, we were able to get right up next to the sound table, allowing us a heads up when the sound levels changed - so we could adjust our own recording equipment. This also meant that our microphone was positioned right near the speakers and thus avoided much of the ambient sound that would otherwise have compromised our sound quality. The Book Cafe, as the name suggests, is a venue where participants sit at their tables and listen to a presentation over a few drinks with their friends. Whilst our recording still picked up audience sounds like laughter and applause, there's much less of the table bumping, chair scraping, glass clinking background noise that we might have had otherwise.

You can listen to Ezra Chitando, Professor of Religious Studies at the University of Zimbabwe, discuss the importance of sensitivity and empathy in leadership or read our write-up from the evening.

2. If the band next door is louder than the poet in front of you, your audio recorder will pick up the band over the poet

At a different event, we went to listen to the "Real Heroes" - a mixed performance of music, spoken word, and poetry from a variety of Zimbabwean artists. You can listen to some of our sound clips from the event.

Whilst the poets had a microphone and a sound system so did the band playing at the venue next door. Unfortunately they play right through some of the meaningful pauses in the performance poetry. When you're there in person, your mind can block out the one sound and focus on the other. But when all you know of the event is what you're hearing on the recording, it's hard to separate the music from the performers, as you can hear in this clip.

3. Saturday afternoon pub gigs are great for a fun time - but you'll get poor quality audio

Part of the fun of the Magamba! Real Heroes event that we went to is that it was on a Saturday afternoon. There weren't very many people there when it first started, but as the event progressed, the crowd grew - and so did the background noise. A pub full of slightly inebriated friends of the performers gives a great vibe. But there is constant background noise - chatter, laughter, discussion, glasses, chairs, and so forth. One of Zimbabwe's greatest poets, Julius Chingono, performed a four poem set towards the end of the afternoon. You can listen to him read The First Woman - but it's a frustrating listen given the background noise levels. You might also want to read
some of Chingono's poems.

All in all we're pleased with our experimenting so far. The next challenge will be getting a better sense of how higher quality audio converts into the 8,000 Hz sample rate files we'll be uploading to our telephony system.

We'd love to hear more about others' experience with audio files - particularly in recording at public events, on the street, or other non-studio conditions. What are some other top tips you'd like to share?