The goal of the first release was to demonstrate different ways of thinking about how foster communities and conversations around news articles on the web, and not to build a real news website or software to power a real news website.

Version 1.0 of News Mixer is a standalone application built on Python and Django. It is meant as a technology demo. For those who liked the ideas and wanted the software, News Mixer is a great commenting system, but it lacks depth. There was very little time put into anything but the commenting. The content management component is minimal. There is no support for posting media. There was a lot of thought but little dev time put into comment moderation, either for site owners or visitors. It’s what happens when you only have 11 weeks to go from “you can do whatever you want” to working software + report + polished presentation.

Despite the minimalism of News Mixer 1.0, it was a hit. People were impressed and inspired by it. So for a tech demo it was a success. Now to make it usable …

Usefulness

Yes, there will be a Wordpress plugin.

The next release of News Mixer will be a more useful application built to actually be used by folks. The plan is to build an API on top of News Mixer and build a plug-in to make the features available for Wordpress. In addition to an API, we’re going to give News Mixer the ability to handle commenting for multiple sites.

Why not just put all the commenting features into a Wordpress plug in?

So the wheel re-invention is kept to a minimum. So we can plug the features into other applications without writing everything from scratch. So folks can manage the comments for many sites in one place. And so maybe it will grow up to be its own web service someday.

There is a big list of things that our team came up with that could make News Mixer better: more commenting systems, rating systems, moderation. But right now we need to make it accessible for people to use.

This new work for News Mixer is being done by the Gazette and me (Ryan Mark). I’ll be writing more about the progress on my blog: http://ryan-mark.com and on twitter: http://twitter.com/ryanmark. Send me your thoughts.

We’ve been writing this blog since the project started.  For the first few weeks we wrote about the theory of the project, since that was what we were struggling with - the major decisions of which task to tackle, which features to include, and which to cut.  

Those were the heady days of philosophical discussions about Journalism and Conversations and Democracy and there was much to blog.  

Then came the era of the research, wherein the consumer insights team wrote about their findings, and the industry researchers dug through the host of products already in existence, and the team gleaned many new answers that provided course corrections for the project.  Since then we’ve blogged about some of our industry research discoveries.

The act of blogging served as a catharsis.  It was the cleansing act of articulating the problems we were combating.  It helped us organize, provided objectivity and some of the input we’ve received from comments has been invaluable.

Happy programmers write happy code.  by Stuart Tiffen

Happy programmers write happy code. by Stuart Tiffen

But after much hand-wringing and painful decisions suddenly, overnight we were in full-on development mode.  Since now our day-to-day grind consists of tackling innumerable design and development obstacles, with some research and now final report and presentation preparation thrown in, such pursuits do not always make for interesting blog posts.

And so, I ask you, our loyal reader(s), what is it that you would like to know about the riddle, wrapped in a mystery, inside an enigma that we call the Crunchberry project?

xkcd Webcomic

xkcd Webcomic

One of the challenges in managing the Crunchberry project is understanding what the development team spends everyday working on. It’s a fundamental problem anywhere developers and non-developers work together: programming is looked at as a black box, something people avoid if possible. As a small group students we each fill a variety of roles and this makes it even more important to communicate how development time is spent.

On Friday after our end-of-the week meeting, I took a half hour to explain the basic concepts behind how Web servers and databases work and what frameworks like Django are and what they do. I tried to keep the explanation as simple as possible, explaining key concepts like what a server is, what web and database servers are and how they fit together, what the difference is between a programming language and a software framework.

I won’t take time here to explain these thing when others have done a better job.

My brief tutorial was helpful to the team. People asked questions and generally understood some of the basics of what the development team does.

Django and its Model, View, Template methodology is relatively simple to explain on a high level. For those who are not familiar - this methodology breaks out logically separate parts of a web application. Models represent data in the database, Views handle the request from a visitor, and Templates format and display the data. I showed off my development environment and some code, trying to dispel some of the magic by walking everyone through a trail of code a visitor would experience when using the Web site.

Programming has a high learning curve compared to many things, but as tools get better and people spend more time using computer systems, that barrier to entry gets smaller. The walls that have been built around technology people need to be torn down. Developers should be able to explain themselves with little or no jargon to non-developers and non-developers should show an interest in understanding.

Ask questions. Challenge the developers to explain things plainly. This helps developers to better understand the problem, and non-developers better understand the tools and constraints the developer works with.

photo by ashe-villain/flickr

Lately we’ve had all sorts of posts about various bits of industry research that we’ve been doing on sites like MonroeTalks, Salon.com’s letters to the editor model, Plurk and personas, but we haven’t taken the time to actually give an update about where we are in the process of this project.  

Well, here it is folks:  We are in the midst of our fifth development iteration.  We have so far successfully designed, developed and are testing the first of our comment structures - Q&A.  Ryan and Brian, our overworked dev team, made an solid product in minimum time.  

We have also designed our second comment structure - Short Format - and that is being developed during the current iteration and we’ll be testing next week.  

The design team, which consists of Kayla and I, augmented by Josh and Angela is working hard on the Letters to the Editor comment structure, as well as ratings structures to be reverse engineered into Q&A and Short Format, all of which are to be developed next week.  

Through each of the last three iterations we’ve been plumbing the depths of Facebook integration, asking how much is too much, how little is not enough and how should it all look?

Crunchberry Teams very first Iteration Meeting!

Crunchberry Team's very first Iteration Meeting!

We’ve wrapped up our first week of design, research and coding. In keeping with our agile project plans, the development team (Brian and I) will work one week behind the design team (Kayla and Stuart). The design team spent the last week putting together features and mock-ups which the dev team will be building in software this coming week.

Since the design team hasn’t had time to put anything together for last week, the dev team built a simple CMS and put together a proof of concept for Facebook Connect. Using Django and pluggables we were able to whip up a basic dynamic news site, plain-jane comments and account registration in a day. It ain’t much to look at yet, but it will give us a starting point to build from as we get direction from the design team.

Facebook Connect was a bit of a challenge to get working, but it will do everything we would like: sharing stories to people’s pages and giving us a way to connect people to their friends and others through news and discussion. As Brian has blogged - it gives us an interesting way to keep the conversation civil: don’t make a scene, others are watching.

There is a bit of a fly in the ointment: When is Facebook Connect going to launch? And where are all the partners? They’ve gone live with a few partners, but the service was supposed to officially launch mid-October after being pushed back earlier this year. And when they do - will they decide that some feature is not a good idea? Not being able to pull a person’s Facebook friends or push a story to their feed makes our application much less interesting.

We’re going to try find out what the plan is from the horse’s mouth, but it gives us pause - do we keep trucking with Facebook Connect and be one of the cool kids on the block when it launches? Or do we hedge our bets and go some other direction and loose some of the potential Facebook brings?

photo by Tambako the Jaguar

photo by Tambako the Jaguar

After a subsequent round of surveys, Team Crunchberry gathered new data on Internet usage rates from our user panel.  From the survey we’ve gleaned that participation intimidation, one of the barriers we’d earlier identified, is not a significant factor for the Cedar Rapids area.  We also eliminated the barrier “Comments lack are not valuable” choosing instead to investigate “Comments are not believable,” as it is a subset of the former, and since it is the more measurable problem to solve.

On Tuesday we finally hammered out a narrowed-down list of super-features and began actual development.  Many hours were spent agonizing over eliminating some features and barriers from our wish list that we wouldn’t have the time to implement, but what we’ve ended up with is a (still over-broad) list of super-features and subordinate features that mitigate many of the barriers to strengthening communities of our target demographic in Cedar Rapids.

The subordinate features on the image above only represent a tiny portion of the overall list of features we’ve written, and that list continues to evolve as the iterative development process gets underway.

Due to time constraints we will not be able to accomplish everything on our narrowed super-feature list.  We are not ruling any of this list out entirely, but to get the ball rolling we are beginning to develop two super-features:  Comment Structure and Facebook integration.