Crunchberry Project

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.

In fall of 2008, Team Crunchberry- six journalism students at Northwestern University’s Medill School of Journalism - partnered with Gazette Communications in Cedar Rapids, Iowa to explore the broad idea of building better conversations around news. After four weeks of researching and defining our project, six weeks of designing & developing software, and two weeks polishing & presenting our work, we went live with our final product, News Mixer.

And now for the moment you’ve all been waiting for - how we did it. Now available for download is our final report (80 pages - 2.7MB pdf file), which documents all 12 weeks of our research, design and development processes. We also provide our findings and recommendations for the journalism industry, as well as further development of News Mixer.

You might also be interested in this roundup of reactions to the News Mixer site, written by our professor, Rich Gordon.

This has been a very educational experience for us, and we hope this final report will help educate journalists, media organizations and journalism schools (in addition to bettering conversations around the news!). We would like to extend one last thank you to our partners at the Gazette, our industry experts, our research panel, and of course - you - our readers who helped us develop News Mixer. Thanks!

For your edutainment needs, we present a short how-to video outlining the various commenting structures and navigation schemes of http://newsmixer.us

 
How to use News Mixer from Stuart Tiffen on Vimeo.

I judge books by their covers. Similarly, I judge websites by their homepages. If you don’t impress me, I will likely leave your site within minutes. 

Research has shown I’m not alone in this. While we all judge homepages by our own set of standards, the fact remains, we judge. This is not good news for someone (me) trying to design a homepage. In fact, it’s downright terrifying. 

The obvious first option was to copy the standard norms for online news sites. Think: USAToday.com, NYTimes.com and CNN.com. There is nothing wrong with these models, to be sure, but as we are building a somewhat experimental site, we wanted to be, well, experimental. And the truth of the matter is we will likely not have enough content each day to fill an entire news site, nor the development time to build it. 

What we want from this site is a place to best showcase what we have created: the comment structures we have built and the Facebook Connect integration we have developed. One of our professors, Jeremy Gilbert, put it best. This site should be like the best art galleries – display the work without getting in the way.

We decided to pursue a news feed model. What we think is the quickest and easiest way to get readers into the stories and experimenting with our designs. Think: New York Times River (with a little more design), meets Digg (without ratings).

New York Times River on a mobile platform. dsearls/flickr

 You see, we are designing a site for the Facebook generation. These people use Digg, Reddit and Twitter. They use sites like this. They get it. They don’t necessarily need the pretty, the big photos, the fancy layout (especially for our testing purposes) they need the stories. 

So while this site might not agree with the tastes of everyone, hopefully it will help us reach our target audience, 20 to 35 year olds living in Cedar Rapids, so they will be able to test out what we have built for them.

After all, if you build it, they will come, right?

We didn’t want to reinvent the wheel. Luckily, we didn’t have to. 

There are many sites out there that let users create profiles—but how many social networks and profiles can one person maintain? We decided not to do what someone else is already doing well, and instead utilize the social networking power that is Facebook, or rather, the ability to relate news to your social network using Facebook Connect.

From the Facebook developers blog: “Facebook Connect is the next iteration of Facebook Platform that allows users to “connect” their Facebook identity, friends and privacy to any site. This will now enable third party websites to implement and offer even more features of Facebook Platform off of Facebook – similar to features available to third party applications today on Facebook.”

This week I am busy designing a system for how comments a user makes on our site will appear on their Facebook profile. Again, not reinventing the wheel here. The Facebook developers wiki makes it pretty clear what the accepted norms are. 

The system I am designing for The Gazette Online this week is very similar to the entertainment celebrity news and gossip site, The Insider. The Insider was one of the first sites to integrate with the Facebook Connect system. Users can choose to add comments they make on The Insider to their Facebook profile wall feed in either a one line, short or full format. 

The good news is that if Facebook approves our implementation of Facebook Connect, the Gazette would likely be one of the first news sites to use the system. But that is a big IF. Facebook has said Connect will roll out November 30, but it’s anyone’s guess if they will hit that deadline, who they will approve and how it will be decided. All we can do is wait, design, develop and hope that the brains behind Facebook Connect like what they see.

We Americans like to judge things. We vote for a new leader every fourth year. Pick favorite teams in baseball. And befriend only those deemed popular in middle school. So it was bound to happen. After years of judging each other, we took the game online, and ratings were born. 

There’s binary – the Ebert model – a quick thumbs up/thumbs down. Ratings done by assigning points or stars. Or there’s the more complex. Like the Topix model where users can judge comments as “brilliant,” “nuts,” “clueless,” “racy,” and a whole host of other descriptions. 

Topix

In our weekly design team planning meeting we decided we couldn’t build commenting structures without addressing ratings. But the tricky part is building a system that will not just be a copy of existing models, but rather, be uniquely targeted at each commenting structure we have built. This means we must have a separate model for the question and answer structure, short format and this week’s letters to the editor format. 

Josh and I have made some progress on a rating system for the question and answer commenting structure we designed a few weeks ago. 

We didn’t like the idea of rating questions, at least in the traditional sense. As we are told often throughout life, there are no bad questions and we don’t want to discourage question asking by judging people for their inquiries. We are, however, designing a rating system for questions where the most popular questions would be highlighted. After a question is asked users with the same question can click a box that says, “I have this question too!” This will give priority to the questions readers most want answered, and possibly motivate the reporter to further investigate the story until the answer is found. 

For ratings on answers, we are combining the Topix model with traditional binary commenting. Users click either a thumbs up or thumbs down icon to vote an answer as good or bad. When users click the thumbs up icon, they are given a drop down menu of choices for how to positively rate the comment including “interesting,” “agree,” “helpful,” “insightful,” “informative,” etc. Conversely, when users click the thumbs down icon they are given a drop down menu of choices for how they can negatively rate the comment, including “disagree,” “offensive,” “off-topic,” “incorrect,” “rude,” etc. 

This system is not entirely brand new, it’s not off the wall, but it just might work. It maintains the speed and ease of use of binary ratings, while providing a little more insight into the content of the comments so the user can decide which comments are worth their time. 

While designs for that rating system move forward, Stuart and I are still busy at work designing a rating system for the letters to the editor model. We are struggling with a way to make ratings innovative and uniquely tied to this commenting structure, without adding too many bells and whistles.

What do you think? How would you want to rate letters to the editor? We’re all ears – ready to judge your suggestions and determine the winner.

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?

This morning I interviewed Kerry Lauerman, of Salon’s Letters and Open Salon, as part of our industry research.

Salon’s Letter to the Editor comment structure stands out in a crowd. Their system, adopted in October 2005, is an innovative approach to a trusted and familiar model. Letters to the Editor are as integral to the history of newspapers as obituaries and wedding announcements.

Salon

Their model is simple: user’s must go through a quick registration and then can write a headline and post their letter. Editors highlight the best letters. Readers can choose to read only those marked by editors, or can see through every letter submitted. 

The letters to the editor structure is one that Stuart and I have considered in our design process, one that we may decide to pursue in the coming weeks. One concern I had before speaking to Mr. Lauerman was that the barrier to entry would be too high. The phrase “letters to the editor” implies a more intelligent, thoughtful reply, as opposed to “comment” which can suggest a snap judgment. It sounds like a great idea – promoting intelligence over outbursts, but to meet the goal of increased community engagement every effort should be made to encourage comments, not discourage them, right?

An example letter

In the world of page views, tallies of registered users and counting clicks, it seems like the focus online is on getting a volume of comments, rather than striving for intelligent discourse. We worry about having too high a barrier of entry to commenting, but maybe that is not a productive concern. 

Lauerman said he doesn’t care if people are turned off from commenting by their letters system.  

“We never worry. If anything we worry it isn’t high enough of a barrier,” Lauerman said. “Our system is targeted at someone who wants to write something thoughtful, because that’s what we’re looking for.”

Lauerman wondered if anyone truly benefits from commenting systems where users can spout off without restraint.

“You are not building anything useful if people are just using it as a place to pop off anonymously,” he said. 

Former Salon editor, Scott Rosenberg, in a letter dated Jan. 30, 2006, said they believe that signed letters reflect a more considered thinking. 

“We know that some of you might be thinking, ‘Gee, when future potential employers are Googling my name, do I really want them to see this rant?’” he wrote. “Maybe that’s simply good motivation to write something that you’ll be proud of. If you think you won’t want to stand by your letter years from now, you might reconsider whether you want to post it at all.”

I like that Salon has the attitude that they want to receive quality letters, or none at all. Just because we want to get more people interacting online does not mean we have to set the bar so low that anyone can jump in. News organizations can still maintain their sense of intelligence and worth. Perhaps if more news organizations took this message to heart we would have more intelligent discourse and less cover stories featuring Britney Spears and Angelina Jolie.

It’s decided. As Stuart noted one of the super features we are beginning to develop is comment structures. 

This week Stuart and I are designing a question and answer structure for comments. We decided to tackle this structure first because it has come up so often in our class discussions that we had to take a longer look. Whatever we come up with by Friday will then be passed off to Brian and Ryan, our programmers, who will build the system next week.

mikemindel/Flickr

We will likely be designing three additional structures throughout the next few weeks. We have a lot of great, innovative ideas for different comment structures – and that is the problem. An argument could be made for any of these ideas, so what we really need is feedback.

Here are the comment structures up for consideration:

Letters to the Editor (much like the Salon.com model)

Users would write a headline and more formal letter-style comment. Could include an option for editors to highlight the best letters to feature prominently on the website or in the print product. 

claireblang/flickr

Polling

This comment structure is designed for people who don’t have a lot of time. One to three questions at the end of the story, users submit their votes and see results. 

the brownhorse/flickr

Ratings

Quick votes by users. Giving stars, thumbs up/down, or points to comments. The top rated could be displayed prominently. Users could also choose to display only those comments with a rating of 3 stars or higher.

Moderated by user (much like the Slashdot model) 

Users post comments. Other users (or users with special moderating privileges) give points to those comments they deem interesting, intelligent, etc. Users can choose to only display comments with X number of points, or “interesting” ratings. 

Short format (much like Twitter)

Users are only allowed 200 characters to make their comment.

Opinion disappears

In an effort to foster intelligent discussion, not based on opinion rants, this structure makes comments containing unsubstantiated opinion disappear in a shorter amount of time than other comments, such as anything supported by a citation or reference and questions. 

Waffle Whiffer/Flickr

Mad Libs

Users leave comments in this format: “I feel _________ about _________________.” Could feature a drop down menu of choices. 

Annotation/citation/reference/footnote

Allows users to make a comment or site an additional source at a specific point in the article. 

One-click comments

Users click buttons at the end of the story with general statements about how they feel about an article. Examples: “This story frustrates me,” “This article offends me,” “This is awesome,” and “This is well-researched.”

Format 

Allows users to choose the format in which they leave comments. Could include replying via video and/or audio. 

Live chat

Registered users can see other users who are logged into the site and begin a live conversation with them about a particular story. This comment would be visible to the public and displayed on the side of the article. Other users could jump into the conversation at any point. 

We want your comments on every blog post, but we especially NEED your comments on this post. What’s interesting to you? What are your top three? Why? Are there any models/ideas out there that we missed?

In part 1, I wrote a bit about the origins of agile, without going into how it translates into a day to day practice.  So, what do you do once you buy into the principles of agile software development?  Get ready for some rules.

(Disclaimer: If you’re at an organization that’s ready to take the plunge into agile, please please please don’t use this blog as a guide.  I will present an incomplete list of things we’re doing, which is an small subset of things we ought to be doing, presented by a guy with a teensy tiny knowledge of the full canon of agile practices.  If you want to do this right, read Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin, and The Pragmatic Programmer, by Andy Hunt, and Dave Thomas.  Or even better, go to Ann Arbor and learn it from the badasses at The Menlo Institute.)

Finished the Foundation by chaim zvi

(Also, read Getting Real by the folks at 37signals.  Please, just trust me on this one.  It’s important.  Much more important than reading this silly blog post, that’s for sure.)

At the beginning of this project, I presented to the team a set of rules by which we all need to abide.  The following is a subset of those rules regarding our weekly schedule.

1. We will scrum every morning.
2. We will work iteratively, regrouping and correcting our course once a week.
3. At the end of each iteration, we will have built and deployed a working piece of software.
4. At the end of each iteration, we will demo our work to the entire team, including stakeholders at the client.
5. Following an iteration, we will gather feedback from end users, stakeholders, etc., and we will adapt.

Scrum?

A scrum is a five-minute long, stand-up (no sitting!) meeting with everyone on the team in attendance.  (Not just the worker bees.  The boss.  The client.  Everyone.)  We go in a circle and briefly recount what we accomplished in the previous day, and what we will to do today.  Keeping everyone in the loop might be the most important thing we can do to make this work.

Iterations?

We work in iteration: tight, discrete chunks that usually a week or two, tops.  This way, there is always a working product, just in varying stages of completion, that can be loved, hated, and rated by the folks who matter most: the users.  (Software joke: Name the other industry that calls its customers “users.”)

This is also about keeping everyone in the loop, but we work this way for many other reasons.  It makes it much easier to change direction.  It prevents the development team from bullshitting everybody else.  (Sure.  It’s practically done!  All we’ve got to do is write the code!)  And it lets the stakeholders (client, instructor, your boss) see what they’re getting for their investment of time and/or money.

Our schedule

We meet Tuesday thru Friday.  So we’re doing 4 day iterations (pretty short, but we’re making due with what we’ve got) resulting in a weekly schedule for everyone on the team that looks like this:

• Scrum, 5 minutes, 9:30 a.m. Tuesday thru Friday
• Iteration Kickoff, 30 minutes, 9:35 a.m. Tuesday, following Scrum
• Iteration Review, 1 hour, 11:00 a.m., Friday

All other meetings will be held in accordance with the rules defined in Getting Real: Meetings Are Toxic (<– click this!):

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:

1. Set a 30 minute timer. When it rings, meeting’s over. Period.
2. Invite as few people as possible.
3. Never have a meeting without a clear agenda.

So, that’s it for today!  Stay tuned for more on our agile process.  Next week: how we break down big scary problems into little tiny problems that aren’t scary at all.