Friday, July 29, 2011

Wednesday, July 27, 2011

Chewing on the #MozNewsLab Project Ideas

Reading the (50, when I last checked) 256-character descriptions of the projects the #MozNewsLab participants are working on was...
  intimidating
    inspirational
          thought-provoking
       reassuring
                daunting
      invigorating
               fun

One of the best things about reading them was how many connections and correlations there were between the ideas. So naturally, being the pattern-finding human that I am, as I read them I started describing them, tagging the, putting them into types.

This isn't a perfect system. Many of them overlap. And that's the best part.

The three strongest themes I saw were: content curation, social reading and beyond the article:
  • Content curation - These ideas wrestle with questions of how we take a mess of information (whether it comes from news outlets, citizens, social media, any source, really) and turn it into a digestible flow. Examples: Manual Pinto, Charlie Pinder, Regnard Raquedan
  • Social reading - These ideas try to make the reading of news more conversational. Or, to put it another way, more like how we actually talk/share/think about information with each other. Examples: Andy Jennings, Lucas Cioffi, Katie Zhu
  • Beyond the article - The article as we know it is an artifact of the 20th century. These ideas try to take a "story" and turn it into the living, breathing, organic thing that it truly is. Examples: Engin Erdogan, Corbin Smith, Sedef Gavaz (also...me!)
There were about 25 themes I saw, including: adding context, annotation, data, visualization, mapping networks, reporting tools and semantic news. I put all the theme tags on a Google spreadsheet so you can view them (and change them, update them, do as you will).

This isn't a perfect way to organize these ideas...it's just a start. Next, I want to create a mindmap to visualize how all the different ideas and themes overlap and intersect. That's probably too ambitious for the time I have at the moment but...maybe one of the other #MozNewsLab participants will do it! (Ah, the perks of working with such a motivated group.)

#MozNewsLab is news/video/web/data/social/story

Yeah, world clouds are over-rated. But I still like them. Here's one created from the text of the 256-character project descriptions submitted by Knight-Mozilla Learning Lab participants. (Word cloud made using Many Eyes.)

Update: Here's a black-on-white version, and a grey background version, at @phillipadsmith's request. ;)


Monday, July 25, 2011

256 characters is actually a lot...

...for describing an idea. Here's my Knight-Mozilla Learning Lab project in 256 characters.

Project: “GitHub for storytelling.”
Goals: Foster open-source principles in journalism. Extend life-cycles of stories beyond their publish dates.
Key features: An open reporter’s notebook, version control, collaborative authorship tools and story-forking.

Now all I need is a pretty picture and I'll be good to go.

Breaking down barriers and opening up reporters' notes

One of the many insightful things John Resig said during his lecture on the attitude and philosophy that has made jQuery successful was: You must remove the barriers between your users and your product. Make it as easy as possible for them to get in and stay in, starting with your very first contact.

Part of this has to do with making the technology work as smoothly as possible, but perhaps an even bigger part has to do with the way that technology is presented and the community engagement elements surrounding it.

In week 1, I realized that the biggest challenges surrounding my idea -- which is a tool for opening up reporters’ notebooks and encouraging others to re-mix, re-mash, and extend the stories that come out of them -- will be around behavioral processes, not technology.

So this week, I’m going to apply John Resig’s advice to last week’s and do some thinking about what some of the behavior barriers might be to using a GitHub for storytelling.

In reality, even though reporters’ notes are designed to be open and transparent (how else are we supposed to be able to trust a journalist as a primary source of information?) there are dozens of reasons reporters might object to sharing them. Some have to do with egos. Some have to do with laziness. But two “categories” are legit:

1. In some cases, sharing notes and interview recordings might compromise a story.

This could be because it would violate the trust or safety of a source. Or make it harder to continue reporting on the story because other sources clamp up.

Then there’s the pesky issue of competition. Publications don’t want to get scooped.

2. Reporters’ notes are often cryptic and hard for anyone other than the author to read.

Have you seen a reporters’ notes? They look like some sort of Proto-Indo European line form language, not English. By necessity, they need to write things quickly, and don’t always have time to type up notes or transcribe interviews.

Issues related to (1) aren’t something that could -- or should -- be addressed for my idea. Issues related to (2) can and should be.

So how do we make that happen?
  • Make new tools fit into the way journalists are already doing their work -- figure out what tools and processes they are already using to do reporting and integrate those as seamlessly as possible
  • If a tool can make it easier for journalists to take and share notes, then it would be a real home run.
Figuring exactly HOW to do that is the hard part. Ideas?

What is the equivalent of documentation for journalism?

[Ed. note, 7/25/2011: I thought this was going to be my official blog assignment for week 2 of #MozNewsLab, but then I wrote a new one and changed my mind. My official post is here. Sorry for the confusion!]

The value in smashing together two fields -- like ballet and football or journalism and software -- goes beyond the products created through unexpected fusion. The most lasting result is the change in perspective that occurs through removing industry-related blinders.

So during John Resig’s lecture, I concentrated on figuring out how each nugget he shared (and there were a lot) translates into journalism. If jQuery wasn’t a JavaScript library, but a magazine or a newspaper, what would John Resig have said?

My favorite four ideas:

  1. jQuery uses community input to make decisions about future strategy and direction.
  2. They make deliberate efforts to keep users after they’ve shipped products (a major time for people to forget about jQuery and move on).
  3. They treat their users as a resource. The best users become contributors.
  4. jQuery is successful is because it has the best documentation.
What would bizarro-newspaper-editor-John-Resig have said?

  1. We base our editorial decisions on reader input: What stories do they want? What do they want the newspaper to look like?
  2. We work to keep readers after they’ve read a story. (This is especially important with readers who get to stories through Facebook or Twitter. We focus on keep them here, and bringing them back, after they’ve gobbled up social media-fed links.)
  3. We give our most engaged readers -- the ones making the best comments and giving us the best tips -- opportunities to be contributors.
  4. Well, this one has a story...
I asked, “What is the equivalent of documentation for journalism?” on Twitter and got great feedback:

From @SaleemKhan,
“I can't think of a direct journalism analogue to code documentation, but the closest might be story notes.”
“Process journalism partly addresses it but isn't always ideal. News has legal/privacy issues coding does not.”
From @epilepticrabbit,
“Journalists keep records of sources and what they say, right? so documentation = these records. Maybe?”
From @k88hudson,
“Most efforts very low tech though. We're trying to experiment with a wiki for contributors this year”
“Internal documentation is necessary for student papers, because there is so little continuity (people graduating, etc)”
Two ideas emerged:

  1. Documentation on the organization level -- how a publication works.
  2. Documentation on the story level -- how it goes from idea to story. The reporting/newsgathering notes are the meat.
How does this fit in to my project? I want to create a tool that lets people, a) expose their reporting process, and b) extend the life-cycle of stories beyond their publishing date through re-mixing and re-mashing.

This isn’t possible without “story documentation.”

In fact, the problem I am trying to solve could be boiled down to:

Create a tool that makes it easy for reporters to clearly and simply share their “story documentation” (i.e. story notes and process).

Once we have that, the re-mixing and re-mashing can follow.

As I make my idea more concrete by moving into the prototyping phase, this will be my guide

Monday, July 18, 2011

The evolution of my Knight-Mozilla learning lab idea

Ideas have strange and interesting lives.

My idea has ultimately been boiled down to a single goal/statement -- Make information-based storytelling (aka journalism, the kind that happens in newsrooms) more collaborative.

To reach that goal, we have to encourage openness and transparency in the journalism process. So how can I do that without practicing openness and transparency in my idea development process? Um, I can't.

So, here's a rough outline of my idea process thus far, which I hope to update throughout the learning lab.

1. MoJo Challenge Submission - The Infinite Story

2. I work with data storytelling every day, and that produces tons of ideas. Ideas like...
  • A GitHub for data projects -- what if you could take datasets that people have already worked on, cleaned, queried, manipulated, etc., and build off of that work? Data work is a huge task. It could be made more collaborative.
  • Tools for data storytelling -- things that take the awesome data viz resources out there (Many Eyes, Tableau, visual.ly, etc.) and add content and storytelling elements. What if you could annotate data visualizations? Tie in social media feeds? Write a story around a data viz?
3. I've read a lot about collaboration. I'm obsessed with it. Enthralled. Projects like FLOSS Manuals get me really excited. How can we bring things like book sprints and collaborative authorship tools to traditional newsrooms?

4. One lesson I learned -- over and over and over -- as a journalism student is that only 10% of the reporting you do on any given story makes it to the "final" version. How can we tap the other 90%? How can we extend and nurture the lives of stories?

And all that led me to GitHub for storytelling. I don't know what it is. I don't know what it will look like. But I know I want to try it.

Prototyping the PROCESS: What would a GitHub for storytelling look like?

Aza Raskin’s lecture helped me realize that I need to prototype a behavioral process, not a technology. I’ll get there, promise. But first, some context around my project idea:

What excites me most about the Knight-Mozilla learning lab? The opportunity to foster the open source software community’s collaborative ethic in the journalism world.

This led me to a formative question: What would a GitHub for news -- a web-based tool for truly social information-based storytelling -- look like?


Next step? Doodling and brainstorming. Here’s how journalists traditionally create news stories:


That diagram is kind of a lie. Really, it looks more like this:
But what if it could look more like this:
It's journalism -- with forking! This diagram is messy. Downright ugly. But the point is: Stories aren’t discrete entities with a beginning, middle and end of life. That structure is an artifact of the 20th century news industry. (The marvelous Clay Shirky has some recent thoughts on this. Read them. Now.) Just like the post-artifact book Craig Mod proposes, I’d like to see a post-artifact news story. 

Print narrowed our definition of news: The web can open it back up.

What web tools could support this updated  workflow? For starters, a digital open reporter’s notebook for organizing information (notes, interviews, multimedia). Add to that: 
  • community
  • forking
  • version control
  • privacy control
  • tracking of forked stories
and...

HOLD UP!

My brainstorming came to a halt, right here. (See the skid marks?) And it’s Aza Raskin’s fault: The barrier to change in a system often isn’t technology -- it’s culture and behavior.

I stopped sketching features of a software tool and started thinking about behavior and culture. Are newsrooms ready (although perhaps readiness is a luxury) for collaborative storytelling?

My first reaction was newsrooms won’t be open to a GitHub for storytelling. A lingering sense of proprietary culture and competition pervades much of the industry. As Shirky notes, this has to change.

In the new news ecosystem, it's collaborate or die.

The good news: journalism is inherently collaborative. The bad news: newrooms are 30% smaller today than in 2000. As the pool of “in-house” collaborators diminishes, newsrooms have two options:
  1. Look outside for collaborators (journalists are doing this by integrating social media, made smoother by tools like Storify)
  2. Get better at collaborating with the resources they have left
Collaboration can be improved.

To get there, I need to prototype the process not the product. How?
  1. Look at successful journalism collaborations (great collaborations exist within the investigative news community, like ProPublica and other members of the Investigative News Network). What are they doing right? What could they do better?
  2. Look at open reporter’s notebook projects. Or build one.
  3. Start testing the workflow -- What would forking a news story look and feel like? Is it intuitive?
Then, and only then, can I start sketching software. (Hopefully, this will keep me from turning into a Swiss Army knife.) I have tons of work to do...better get started!

Sunday, July 10, 2011

Sinister 7: The Good Kind of Evil

I'm blogging from the road here (literally: just south of Great Falls, Montana on I-15). Full update soon. But first...we won! Girls Heart Rockets was the fastest all-female team at the Sinister 7 trail relay, finishing the 148 km course in 15 hours and 53 minutes!

[Update, 7/11/11, 1:30 pm: Tien-Tien and I made it back to Boulder on Monday morning -- no deer-splattering! I'll add some annotations to these pics, and more soon...the resolution seems to be weird because I uplodaded them from my phone, so I might post better versions, too.]


At the pre-race meeting, a stuffed bear looms ominously over the team in rad matching track suits. (Want!)
Obligatory "before" picture, taken under the Sinister 7 start/finish

My favorite piece of race shwag: Sporknife! Knorkoon!

There was a cougar there, too...

Crowsnest Mtn. in the early morning light before the race start. The jaggedy thing to the right is the Seven Sisters, which I ran over on Leg 5.

Wednesday, July 06, 2011

Sinister 7 Imminent


Sinister 7 is bearing down on me. Or rather, the snippets of information about the race that have floated through the interwebs are bearing down on me. On the eve of my departure for Canada's Crowsnest Pass (which I keep mentally pronouncing, "Crown-set Pass"), here are some of my favorite quotes from the official race materials and the discussion on the facebook page:

From the racer info packet:

There are definitely bears and cougars in the area. If there is reported activity around the course prior to, or during the race, we may modify the course. We cannot predict random animal activity so please stay alert. Take note of the information pamphlets, which will be included in your race package, on what to do if you approach a bear or cougar on the trail. We may dress up in bear suits to “motivate” runners; please do not pepper spray bears if they are wearing Sinister 7 t-shirts and running shoes.

We strongly recommend that you be prepared to drink from streams or rivulets if you need water when higher up in the mountains. The water in the area is generally very clean, and besides, illnesses like Beaver Fever take about two weeks to manifest symptoms so you should be fine for the duration of the race!
[Note: As someone who has experienced Beaver Fever, I can confirm.]

From the race director's update e-mail:
Snow Report

Two weeks of consistently warm weather has brought down a lot of snow and most of the course is now clear. This means a few different things. First, the streams and creeks are running high so some of you will be getting wet feet, especially on the longer stages. Don't worry though - it only helps your toenails fall off that much faster.

A lot of the trails are now quite muddy but we hope a week of sun will help that. Not that we care about the runners; we're just worried about trail damage!

There will still be snow on leg 5, guaranteed. So that does make the race directors feel a bit better - you are not getting off scot free.

From the facebook page:

[Leg 5] is worse than you can imagine. I did it completely in the dark (actually had daylight for the first bit but no light on the climb). Took me forever. But I am slow. It was horrible. So wet. It was like hiking up a waterfall at time...s. It was so wet. There maybe creek crossings but I never noticed any as the whole friggin trail was wet. A couple guys passed me running without poles (It think last year a couple fast teams got lost so ended up behind me) those guys were flying, have no idea how they could do it. The decent is brutal in the dark. When I did it is was misty, no moon, I had glasses on, I could barely see the frigin ground. Took longer to go down then to go up. It was hell. Poles saved me from certain fractures and sprains and incredibly helpful on the steep climbs and even more necessary on the decent. PLEASE NOTE THIS there is an aid station somewhere on this trail, one aid station, last year they had sweet nothing except for water, not a gel, not a granola bar, not a peanut.






See you on the other side!

A proper mixed drink

The Violet Hour, Chicago


Atop Bard Peak

This picture is from one of two 13ers I hiked on Sunday. Whose vertebra is that?


The bean