Tonight our Department debuted a Citizen Journalism website. Now that the technical structure is in place, I thought I’d comment on the design decisions that went into it.

First, back last summer, when this project was first introduced to me, we looked at a number of existing citizen journalism websites for some insight, such as Chi-Town Daily and MyMissourian. These sites are excellent examples of the genre. In the beginning, it wasn’t clear to me exactly what sort of content (e.g., what types of media) would need to be accommodated. And while to the end-user, the integration of audio, images, and video all look like they work together seamlessly, the back-end handling of these various media forms is not as easy. On many sites we looked at, the media seemed to drive the division of stories, so one would go to one section for video and another section for images. In this way, it seemed like the technology (the media) was driving the site organization rather than the content. In contrast, we wanted the story to drive the navigation, instead of it being driven by the media form.

Furthermore, although there are a number of open source platforms to choose from, when deciding on an appropriate platform, our criteria for selection became: 1) ease of use on the administrative side; 2) availability of plug-ins to handle images, audio, video; 3) and to a lesser extent availability of customizable templates. Based on these criteria, wordpress appeared to be the best option. Though it’s not traditionally a CMS, it is robust enough. We also considered drupal (but I hate the admin panel and the templates always seem to look drupal-y) and joomla (not an intuitive administrative panel).

That was the easy part. I will spare the details of the entire process, but the plug-ins that have been instrumental are:

• Vidavee:This plug-in allows for the uploading of video content, where the video is compressed and you can easily cut and paste code in the post that embeds the video for integrated playback. My only fear is that Vidavee’s terms of service will change.
  
• YAPB (Yet Another Photo Blog): This plug-in just literally saved the day because due to a server setting, the built-in resizing of images that comes with wordpress doesn’t work. I would recommend this plug-in anyway, because it nicely resizes images to a small image on the front of the site, a larger image within the full post, and an easily customizable sidebar in which to display thumbnails.
  
• Podpress: I swear this used to support audio upload, and it was a breeze. I might have imagined that. Nonetheless, after adding audio to the built-in wordpress media gallery, a user can cut and paste the url into Podpress and a snazzy audio player is embedded right into the post.

For a while I was also using the flickr rss plug-in. I really like that as well, but we didn’t want to add an additional layer of username and password for We-Town site users to have to go through to add pictures. Also, the group feature does not currently work with that plug-in. (It works if you are hard-coding the sidebar, but not when using widgets for some reason). I will also say that the YAPB plug-in is a little more flexible, and I like that we can change the width of photos as they appear. For someone already using flickr, this plug-in is excellent though. In fact, I use it on this site. For this same reason of not wanting to burden potential site users, we didn’t opt to demonstrate major overlap with YouTube either.

We are currently pulling together directions for using the site. I have started customizing the admin panel to reflect more specifically for a potential user what each section might be for. If podpress would just support uploading audio, it would make my life a lot easier as there would then be no need to point users to the media gallery.

Next, there are still a lot of process-oriented aspects to consider. I am also curious whether the “one image at a time” aspect is going to frustrate users. Certainly more sophisticated users can link to photobucket, flickr, or other photo sites, but then these images won’t show up in the sidebar. It will also be interesting to see how the categories across the top play out. They are designed to mirror the types of categories one might see in a newspaper. This is fine, but I wonder whether community users will see this as helpful. I can also start to imagine other features that would be good to add, including a way to add to a community calendar. The easier the better, I would think.

So I think we can fairly say that we’ve come to the end of Phase I - choosing the tool, customizing some key additional features, and choosing a look and feel (done by one of my Publication Graphics and Design classes). Phase II will be much more concentrated roll out of student-produced content and community events to help potential contributors get familiar with the process. We imagine student-designed workshops to do outreach to the community.