Do you have a sharp red pencil & a passion for 'news applications' ?
Phillip Smith
Howdy folks,
If you have an interest in 'news apps' -- or experience developing, or dreaming about them -- I could really use your help to refine the final copy for "The Open Web's Killer App" challenge that will launch on May 23rd.
I've taken a shot at clarifying the intent of the challenge here:
http://etherpad.mozilla.com:9000/MoJo-News-Apps-Challenge
Would you mind taking a look and letting me know:
1. Do you 'get it' at a gut level? Is the scope of the challenge both broad and specific enough for you to see a possible solution?
2. Do you have better examples of existing traditional 'news apps,' new news 'web apps,' or HTML5 capabilities put to use toward news delivery? If so, could you add them to the bullet points in the document linked above?
Last but not least, if you're working on a new news app -- one that aggressively uses the building blocks of the open web -- and would be open to letting me interview you about it on Skype (your aspirations, frustrations, etc.), I would be grateful for the opportunity to highlight your story in a blog post. If that interests you, please shoot me a quick note off-list with a few dates and times that work for you.
Many thanks in advance,
Phillip.
--
Phillip Smith
http://phillipadsmith.com
http://twitter.com/phillipadsmith
http://linkedin.com/in/phillipadsmith
Carrie Oviatt
"Have a look at HTML5 demos from AP (http://html5.labs.ap.org/) and NYTimes (http://www.nytimes.com/chrome/)"
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/community-mojo
Esteban Contreras
> links not accessible to general public?:
> "Have a look at HTML5 demos from AP (http://html5.labs.ap.org/) and
> NYTimes (http://www.nytimes.com/chrome/)"
>
Nice!
Wray Cummings
FTA: "HTML5 presents an opportunity to create entirely new ways of
interacting with journalism."
and: "HTML5 is being developed specifically to address these limitations,
and to enable true 'web applications,' applications that are both *on* the
web, and *of* the web."
Don't want to get all pedantic and stuff but "HTML5" in this context is the
visible piece of a bigger structure that includes CSS and JavaScript.
Together, these components (perhaps the "HTML5 stack"??) open a universe of
client-based possibility. Sure, as we figure out how to implement and use
<canvas>, local storage, local database, etc, our devices should appear to
get smarter. In the meantime CSS3 is here, now (for 80% of the main browsers
anyway). And CSS3 is *very* useful.
--
Wray Cummings
402.419.3889
Carrie Oviatt
Scott Klein
I'm not sure I understand the challenge. Is the end-product an individual piece of journalism like Mapping LA or Dollars for Docs, or an innovative story collection like the Times chrome app? I think they're quite different.
/s
________________________________________
From: community-mojo-bounces+scott.klein=propubl...@lists.mozilla.org [community-mojo-bounces+scott.klein=propubl...@lists.mozilla.org] On Behalf Of Phillip Smith [p...@phillipadsmith.com]
Sent: Monday, May 16, 2011 6:55 PM
To: Discuss the Knight-Mozilla News Technology Partnership
Subject: [mojo] Do you have a sharp red pencil & a passion for 'news applications' ?
Howdy folks,
If you have an interest in 'news apps' -- or experience developing, or dreaming about them -- I could really use your help to refine the final copy for "The Open Web's Killer App" challenge that will launch on May 23rd.
I've taken a shot at clarifying the intent of the challenge here:
http://etherpad.mozilla.com:9000/MoJo-News-Apps-Challenge
Would you mind taking a look and letting me know:
1. Do you 'get it' at a gut level? Is the scope of the challenge both broad and specific enough for you to see a possible solution?
2. Do you have better examples of existing traditional 'news apps,' new news 'web apps,' or HTML5 capabilities put to use toward news delivery? If so, could you add them to the bullet points in the document linked above?
Last but not least, if you're working on a new news app -- one that aggressively uses the building blocks of the open web -- and would be open to letting me interview you about it on Skype (your aspirations, frustrations, etc.), I would be grateful for the opportunity to highlight your story in a blog post. If that interests you, please shoot me a quick note off-list with a few dates and times that work for you.
Many thanks in advance,
Phillip.
--
Phillip Smith
http://phillipadsmith.com
http://twitter.com/phillipadsmith
http://linkedin.com/in/phillipadsmith
_______________________________________________
Nicholas Doiron
1) The challenge seems to be of two minds - one is making a news app which
is open, and one is creating an HTML5-centric app. There's plenty of
cross-over, sure, but what about interactive and open web platforms - such
as OpenStreetMap - that don't revolve around <video> and WebGL?
2) This paragraph is critical of maps and information mash-ups:
--->"News organizations are actively creating interactive tools, web and
mobile applications, and information visualizations that combine reporting
and data. But most of these news applications and tools -- like ProPublica's
"Dollars for Docs" or the LA Times' "Mapping LA" projects -- are confined to
a single web site or page, and a single platform or device"
Based on its placement in the problem statement, it implies that maps and
mash-ups (a) don't use HTML5, (b) do not work on mobile and tablet devices,
and (c) should be replaced by HTML5 web apps, which are webpages that can be
viewed on all devices. That interpretation doesn't make sense to me, but I
can't figure out what else it could mean.
3) The challenge asks us to make a page for all platforms
(browser/client-side). Then it compares the ideal app to Yelp, which is
more of a social network or API (server-side, and not HTML5).
4) The challenges are all very open and inspiring, and are based on real
products and progress by open web developers, but the barrier for submitting
an idea is too low. As a result, many submissions are not related to HTML5,
not possible technically, or not usable by news organizations. On a site
like Quora I could find useful answers based on people's qualifications,
interesting diagrams, or links to examples, but on the existing site each
submission looks like a run-on sentence. Please fix this so we can see more
of the well-supported ideas.
Regards,
Nick Doiron
Ian Hill
- Enable more coherent, elevated discussion
- Improve the signal-to-noise ratio in public news commentary
To be successful you're going to need to explain to people like me, and people a lot less tech-saavy then me, how your product accomplishes those goals.
Just something to keep in mind.
__________________________________
Ian Hill
Community engagement specialist
KQEDnews.org<http://www.kqednews.org/>
Phone: (415) 553-2216
Follow KQED on Facebook<http://Facebook.com/KQEDPublicMedia> and Twitter<http://twitter.com/#%21/kqed>
Share your knowledge and become a KQED News source by joining the Public Insight Network<http://www.kqed.org/news/publicinsight.jsp>
ih...@kqed.org
______________________________
*Sent from my iPhone. Please excuse any typos.
Mark Surman
bigger as Wray says.
Flipside, HTML5 is actually a useful marketing buzzword to catch
developer attention as long as you caveat / contexualize.
On 11-05-16 10:19 PM, Wray Cummings wrote:
> Hey Phillip,
>
> FTA: "HTML5 presents an opportunity to create entirely new ways of
> interacting with journalism."
>
> and: "HTML5 is being developed specifically to address these limitations,
> and to enable true 'web applications,' applications that are both *on* the
> web, and *of* the web."
>
> Don't want to get all pedantic and stuff but "HTML5" in this context is the
> visible piece of a bigger structure that includes CSS and JavaScript.
> Together, these components (perhaps the "HTML5 stack"??) open a universe of
> client-based possibility. Sure, as we figure out how to implement and use
> <canvas>, local storage, local database, etc, our devices should appear to
> get smarter. In the meantime CSS3 is here, now (for 80% of the main browsers
> anyway). And CSS3 is *very* useful.
>
>> _______________________________________________
>> community-mojo mailing list
>> communi...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/community-mojo
>>
>
>
>
--
Mark Surman
Executive Director
Mozilla Foundation
ma...@mozillafoundation.org
commonspace.wordpress.com
Scott Klein
presentation, they're pieces of journalism. The description ought to talk
about gathering and analyzing data and reporting, etc.
/s
--
Scott Klein
Editor of News Applications
ProPublica <http://www.propublica.org/>
office: 917 512-0205
twitter: @kleinmatic
>On Mon, May 16, 2011 at 7:55 PM, Phillip Smith
Jonathan Eyler-Werve
They are costs, office politics, training, legal barriers, documentation
and other boring stuff.
Perhaps that's out of scope for this effort. But I'd like to see solutions
that reflect those realities - posting code to sourceforge does not finish
the job.
Perhaps asking participants to clearly describe the journalist end user (by
name!) and their pain points would help promote this thinking?
For context I just talked with some very smart people who do not use
spreadsheets when analysing reporting data because they don't know how.
Everything on a word doc.
On May 17, 2011 9:37 AM, "Scott Klein" <Scott...@propublica.org> wrote:
I share Nick's concerns. I'd also add that news apps are not just about
presentation, they're pieces of journalism. The description ought to talk
about gathering and analyzing data and reporting, etc.
/s
--
Scott Klein
Editor of News Applications
ProPublica <http://www.propublica.org/>
office: 917 512-0205
twitter: @kleinmatic
On 5/17/11 12:29 AM, "Nicholas Doiron" <ndo...@mapmeld.com> wrote:
>I'm a programmer and ...
Jonathan Eyler-Werve
http://getindaba.com
Jonathan
Phillip Smith
Many thanks to those that responded. I greatly appreciate your feedback toward getting the language of the 'news app' challenge right. Some quick responses are below:
On 2011-05-17, at 7:57 AM, Mark Surman wrote:
> Flipside, HTML5 is actually a useful marketing buzzword to catch developer attention as long as you caveat / contexualize.
I think that Mark's comment represents the essence of what we're trying to focus on for the challenge thus far: HTML5 the term is quickly becoming a generic umbrella for several technologies, e.g., Web Apps 1.0, CSS3, new JavaScript APIs, etc.
When you take a look at the "HTML5" demos from Google[1], Apple[2], or Mozilla[2], they each present more than just the new semantics and Web forms in the HTML5 spec.
[1] http://slides.html5rocks.com/
[2] http://www.apple.com/html5/
[3] https://demos.mozilla.org/
That said, I think the point is that we need to make this clearer. :)
On 2011-05-16, at 10:19 PM, Wray Cummings wrote:
> Hey Phillip,
>
> FTA: "HTML5 presents an opportunity to create entirely new ways of
> interacting with journalism."
>
> and: "HTML5 is being developed specifically to address these limitations,
> and to enable true 'web applications,' applications that are both *on* the
> web, and *of* the web."
>
> Don't want to get all pedantic and stuff but "HTML5" in this context is the
> visible piece of a bigger structure that includes CSS and JavaScript.
> Together, these components (perhaps the "HTML5 stack"??) open a universe of
> client-based possibility. Sure, as we figure out how to implement and use
> <canvas>, local storage, local database, etc, our devices should appear to
> get smarter. In the meantime CSS3 is here, now (for 80% of the main browsers
> anyway). And CSS3 is *very* useful.
"HTML5 stack" works for me. :)
On 2011-05-16, at 11:29 PM, Scott Klein wrote:
> Philip,
>
> I'm not sure I understand the challenge. Is the end-product an individual piece of journalism like Mapping LA or Dollars for Docs, or an innovative story collection like the Times chrome app? I think they're quite different.
Hi Scott,
You're right, of course, they are completely different. What I was hoping to evoke was a combination of the two, e.g.: What if Dollars for Docs was 'explorable' in the same way that the AP demo is? What if the Mapping LA project was presented as a Yelp-like experience on appropriate devices?
The challenge is not a journalistic challenge, to be clear, it's a technical one. Basically, the questions to ask yourself are:
+ If news app developers had unlimited time and resources, what would news apps look like?
+ Could that same journalistic content be experienced differently on different devices, in different locations, or based on when it was being viewed?
+ What is the experience like when news apps can run directly in the browser as a stand-alone application?
On 2011-05-17, at 12:29 AM, Nicholas Doiron wrote:
> I'm a programmer and I work with maps, so I'm approaching it from that bias.
>
> 1) The challenge seems to be of two minds - one is making a news app which
> is open, and one is creating an HTML5-centric app. There's plenty of
> cross-over, sure, but what about interactive and open web platforms - such
> as OpenStreetMap - that don't revolve around <video> and WebGL?
Hi Nicholas,
You're right. The challenge should make it clear that we're talking about all 'open web' technologies, not just HTML, JS, and CSS.
> 2) This paragraph is critical of maps and information mash-ups:
>
> --->"News organizations are actively creating interactive tools, web and
> mobile applications, and information visualizations that combine reporting
> and data. But most of these news applications and tools -- like ProPublica's
> "Dollars for Docs" or the LA Times' "Mapping LA" projects -- are confined to
> a single web site or page, and a single platform or device"
It's not meant to be *critical* at all, in fact. I'm using those two examples because I think they're *exemplary* of the current state-of-the-art in news apps. But, in re-reading it, I see how it could be seen as critical... the point is, however, that these examples are "limited" in that they can only be experienced 'as is' -- the same no matter what device I'm on, where I am, what type of viewer I've indicated I am, etc.
> Based on its placement in the problem statement, it implies that maps and
> mash-ups (a) don't use HTML5, (b) do not work on mobile and tablet devices,
> and (c) should be replaced by HTML5 web apps, which are webpages that can be
> viewed on all devices. That interpretation doesn't make sense to me, but I
> can't figure out what else it could mean.
Sorry for the confusion here. Maps and and mash-ups are big part of what we're asking people to think about in this challenge.
> 3) The challenge asks us to make a page for all platforms
> (browser/client-side). Then it compares the ideal app to Yelp, which is
> more of a social network or API (server-side, and not HTML5).
Not meant as a *technical* comparison, but a _conceptual_ one: e.g., What Yelp is to location, [Your idea here] is to news.
Many thanks for the feedback. Please keep the comments, edits, and examples coming -- either here, or on the Etherpad:
http://etherpad.mozilla.com:9000/MoJo-News-Apps-Challenge
Phillip Smith
On 2011-05-17, at 10:36 AM, Scott Klein wrote:
> I share Nick's concerns. I'd also add that news apps are not just about
> presentation, they're pieces of journalism. The description ought to talk
> about gathering and analyzing data and reporting, etc.
Hey there Mr. Scott,
I hear what you're saying, but -- and correct me if you think this is way off -- my gut says that 'gathering and analyzing data and reporting' would be stronger as a separate challenge.
When I was yammering-on about possible challenges last month (http://ps.ht/fbDhZ3 ), I discussed challenge ideas that focused specifically on 'Reporting news' (See: http://ps.ht/g59af5 ) -- ideas like working with data, working with sources, and so on. I'm still keen to get input on these ideas, as they will likely become part of the challenges that are run in early 2012.
Specifically, what this news applications challenge is seeking to do is to push the boundaries of the *presentation* of this new form of journalism that is being referred to as 'news apps.'
I think this is a particularly interesting challenge specifically because the field is relatively new and evolving so rapidly.
The outcome of the challenge would probably look more like Pro Publica's TimelineSetter (http://propublica.github.com/timeline-setter/) than Dollars for Docs.
Does that help to clarify the intent a bit? If so, what changes would you make to the copy in that light?
Many thanks for your comments, as always. :)
Nicholas Doiron
In the description you're setting the scene (current news info projects, the
HTML5 demos, the successful information hubs like Yelp) and asking how news
will fit into this new media space. Sounds like these projects will be
emblematic of the whole Knight-Mozilla partnership.
If you could emphasize in the description what you've said here, that the
task is about presenting stories and information across users' devices, that
would make it easier to start coming up with ideas.
--
Nick
> Phillip.
>
> --
> Phillip Smith
> http://phillipadsmith.com
> http://twitter.com/phillipadsmith
> http://linkedin.com/in/phillipadsmith
>
>
>
>
>
>
>
Phillip Smith
On 2011-05-17, at 10:59 AM, Jonathan Eyler-Werve wrote:
Hi Jonathan,
> Most of the barriers to technology adoption in newsroom are not engineering.
> They are costs, office politics, training, legal barriers, documentation
> and other boring stuff.
Indeed, that has been a key message that I have heard over the last few months. :)
Some thinking has been done with our colleagues at The Guardian to engage these barriers head-on:
http://www.pbs.org/idealab/2011/03/fresh-from-sxswi-6-ways-to-integrate-hacking-in-newsrooms075.html
... and, as we get closer to the time when the fellows will depart for their respective newsrooms, we'll be circling back to this question in more detail.
> Perhaps that's out of scope for this effort. But I'd like to see solutions
> that reflect those realities - posting code to sourceforge does not finish
> the job.
*Cough*GitHub*Cough*
It does not "finish the job," but it *does* at least make it possible for _other people_ to finish the job.
Just one example from Mozilla's recent history:
+ Processing (http://processing.org/) is a magnificent visualization language, but it's not very Web-friendly.
+ John Resig -- one of our upcoming learning lab lecturers, I should mention! :) -- decided to start porting the language to JavaScript (http://ejohn.org/blog/processingjs/) and to release it on Github (http://github.com/jeresig/processing-js/tree/master).
+ But John's a busy guy, so it would be unfortunate if the continued development of the language rested entirely on his shoulders.
+ Thus, when Mozilla started working with a local college here in Toronto, one of the projects that students worked on was the continued development of Processing.js (http://www.senecac.on.ca/media/2010/2010-12-15.html?page=1).
+ That work resulted in the recent release of Processing.js 1.0 (http://processingjs.org/blog/?p=250).
That's co-creation and peer-based innovation in action. :)
Phillip Smith
This is super-helpful feedback, Nick. Many, many thanks. :)
>> --
>> Phillip Smith
>> http://phillipadsmith.com
>> http://twitter.com/phillipadsmith
>> http://linkedin.com/in/phillipadsmith
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> community-mojo mailing list
>> communi...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/community-mojo
>>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/community-mojo
--
Erin Polgreen
have a support component--i.e. how can this product or tool be easily
integrated by a news organization? What are the entry points? Where does
education need to happen? I love that github exists, but how can we empower
newsrooms to actually implement and get forking?
Best,
E
On Tue, May 17, 2011 at 9:59 AM, Jonathan Eyler-Werve <
jonathan.e...@globalintegrity.org> wrote:
> Most of the barriers to technology adoption in newsroom are not
> engineering.
> They are costs, office politics, training, legal barriers, documentation
> and other boring stuff.
>
> Perhaps that's out of scope for this effort. But I'd like to see solutions
> that reflect those realities - posting code to sourceforge does not finish
> the job.
>
> Perhaps asking participants to clearly describe the journalist end user (by
> name!) and their pain points would help promote this thinking?
>
> For context I just talked with some very smart people who do not use
> spreadsheets when analysing reporting data because they don't know how.
> Everything on a word doc.
>
> On May 17, 2011 9:37 AM, "Scott Klein" <Scott...@propublica.org> wrote:
> I share Nick's concerns. I'd also add that news apps are not just about
> presentation, they're pieces of journalism. The description ought to talk
> about gathering and analyzing data and reporting, etc.
>
> /s
>
>
> --
> Scott Klein
>
> Editor of News Applications
> ProPublica <http://www.propublica.org/>
> office: 917 512-0205
> twitter: @kleinmatic
>
>
>
>
>
>
>
>
>
>
> On 5/17/11 12:29 AM, "Nicholas Doiron" <ndo...@mapmeld.com> wrote:
>
> >I'm a programmer and ...
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/community-mojo
>
--
Erin Polgreen
Managing Director, The Media Consortium
@tmcmedia <http://twitter.com/tmcmedia> /
@erinpolgreen<http://twitter.com/erinpolgreen>
312.841.0553
Scott Klein
One way you might want to evolve this idea, if there's time: How about apps that "hack the core" in Matt Waite's sense<http://www.niemanlab.org/2011/03/matt-waite-to-build-a-digital-future-for-news-developers-have-to-be-able-to-hack-at-the-core-of-the-old-ways/>, by which I mean ones that rethink the story production process and make news stories themselves more useful and more of the web:
Imagine a crime story that had each location in the crime story stored, providing readers with maps that show not just where the crime happened, but crime rates in those areas over time and recent similar crimes, automatically generated for every crime story that gets written. A crime story that automatically grabs the arrest report or jail record for the accused and pulls it up, automatically following that arrestee and updating the mugshot with their jail status, court status, or adjudication without the reporter having to do anything. Then step back to a page that shows all crime stories and all crime data in your neighborhood or your city. The complete integration of oceans of crime data to the work of journalists, both going on every day without any real connection to each other. Rely on the journalists to tell the story, rely on the data to connect it all together in ways that users will find compelling, interesting, and educational.
Now take that same concept and apply it to politics. Or sports. Or restaurant reviews. Any section of the paper. Obits, wedding announcements, you name it.
I realize we're a little close to the deadline here so this might not be possible. But it's a thought.
Cheers
Scott
--
Scott Klein
Editor of News Applications
ProPublica <http://www.propublica.org/>
office: 917 512-0205
twitter: @kleinmatic
On 5/17/11 12:12 PM, "Phillip Smith" <p...@phillipadsmith.com<mailto:p...@phillipadsmith.com>> wrote:
On 2011-05-17, at 10:36 AM, Scott Klein wrote:
I share Nick's concerns. I'd also add that news apps are not just about
presentation, they're pieces of journalism. The description ought to
talk
about gathering and analyzing data and reporting, etc.
Hey there Mr. Scott,
I hear what you're saying, but -- and correct me if you think this is way
off -- my gut says that 'gathering and analyzing data and reporting'
would be stronger as a separate challenge.
When I was yammering-on about possible challenges last month
(http://ps.ht/fbDhZ3 ), I discussed challenge ideas that focused
specifically on 'Reporting news' (See: http://ps.ht/g59af5 ) -- ideas
like working with data, working with sources, and so on. I'm still keen
to get input on these ideas, as they will likely become part of the
challenges that are run in early 2012.
Specifically, what this news applications challenge is seeking to do is
to push the boundaries of the *presentation* of this new form of
journalism that is being referred to as 'news apps.'
I think this is a particularly interesting challenge specifically because
the field is relatively new and evolving so rapidly.
The outcome of the challenge would probably look more like Pro Publica's
TimelineSetter (http://propublica.github.com/timeline-setter/) than
Dollars for Docs.
Does that help to clarify the intent a bit? If so, what changes would you
make to the copy in that light?
Many thanks for your comments, as always. :)
Phillip.
--
Phillip Smith
http://phillipadsmith.com
http://twitter.com/phillipadsmith
http://linkedin.com/in/phillipadsmith
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
Daniel Bachhuber
http://stdout.be/2010/04/22/we-are-in-the-information-business/
When I first heard about the challenge from Phillip, this is what immediately came to mind. It's 10% actual technology though, and 90% getting the workflow/organization/culture to adopt it.
Just two cents,
Daniel
Matthew Terenzio
make it queryable via API and machine readable via microformat and semantic
markup.
Stories get built with those atoms and automatically pull in related data to
fill out the picture.
Hope I'm not getting off topic.
Chase Davis
The challenge description talks about using emerging technologies to create
"applications that are both on the web, and of the web." As it is now, most
news apps are "on" the web. They function as discrete units of content, not
unlike stories, graphics, photos, etc. For better or worse, that's the
outgrowth of an old-school news production process that divvies things up by
content type. I think in an ideal world, we'd do exactly what Scott and
Daniel mentioned: Blow up those old boxes, realize we're in the information
business, and start structuring content in a way that makes more sense.
Obviously culture doesn't change overnight, so the nice thing about news
apps is that they function like little sandboxes. Most of the time, apps
operate outside of an organization's CMS and often run on their own
infrastructure. That makes it much easier to innovate and prove concepts in
small scale without having to worry about stepping over kludgy legacy
infrastructure or waging war against decade of established newsroom culture.
I call it the Mythbusters Method: Start in the small scale, use that to
justify full-scale, then ramp it up to overkill.
I think where this challenge could be hugely helpful is in demonstrating
real-life examples of the approach Scott and Daniel mentioned. Build a
portable crime app that tackles not just a cool HTML5/Node.js/whatever
interface, but also data entry and standardization -- then productize and
market it to small newspapers that still send their reporters to the cop
shop to jot down blotter entries everyday. Do the same with sports, or
elections, or whatever. Point being, I think it would be helpful to cover
the whole production process, from information gathering to display, if the
goal is to push newsrooms toward a smarter approach.
Just a thought,
Chase
--
Chase Davis
Director of Technology
Center for Investigative Reporting
Phone: 916-674-2482
E-mail: cda...@cironline.org
--
Chase Davis
Reporter
California Watch
Center for Investigative Reporting
Phone: 916-674-2482
E-mail: cda...@californiawatch.org
Rhiannon Coppin
There's a whole data collection / data entry / data sharing / data archiving
side of things that never really gets discussed, but is really at the heart
of making sustainable, truly useful (and even profitable) systems for this
'new' type of news.
Rhiannon Coppin
@rhiannoncoppin
Vancouver, B.C.
Phillip Smith
On 2011-05-17, at 2:55 PM, Scott Klein wrote:
> Imagine a crime story that had each location in the crime story stored, providing readers with maps that show not just where the crime happened, but crime rates in those areas over time and recent similar crimes, automatically generated for every crime story that gets written. A crime story that automatically grabs the arrest report or jail record for the accused and pulls it up, automatically following that arrestee and updating the mugshot with their jail status, court status, or adjudication without the reporter having to do anything. Then step back to a page that shows all crime stories and all crime data in your neighborhood or your city. The complete integration of oceans of crime data to the work of journalists, both going on every day without any real connection to each other. Rely on the journalists to tell the story, rely on the data to connect it all together in ways that users will find compelling, interesting, and educational.
>
> Now take that same concept and apply it to politics. Or sports. Or restaurant reviews. Any section of the paper. Obits, wedding announcements, you name it.
This is great. Very helpful to hear ideas expressed in this level of practical detail.
Phillip Smith
On 2011-05-17, at 3:03 PM, Daniel Bachhuber wrote:
> Following up on Scott's points, I've always thought Stijn's piece accurately summarizes the billion dollar opportunity:
>
> http://stdout.be/2010/04/22/we-are-in-the-information-business/
>
> When I first heard about the challenge from Phillip, this is what immediately came to mind. It's 10% actual technology though, and 90% getting the workflow/organization/culture to adopt it.
That's a curious take on Stijn's piece, IMHO.
Stijn says: "But we’re forgetting the most important point at issue: what should a news website look like in 2010 and beyond? The fundamentals of website design and information architecture somehow lack appeal as a topic for debate among journos."
When I read that piece in the context of this thread, I thought it drove to the core of what this third challenge is all about: How would you use the web to dramatically improve how we make & share news.
Stijn's piece goes on to say "That technology should reach right into the core of our journalistic endeavors, not just touch the periphery like yet another infographic or mashup" and "The news industry needs to start thinking about journalism in terms of information and the myriad ways in which we can present that information to our readers."
Yet, I hear a persistent hum from those working in newsrooms and those on this list of of "workflow, CMS, workflow, CMS!"
**Is that not thinking about re-tooling the printing press vs. re-tooling the system of news itself?**
What Mozilla brings to the table here is expertise in open culture, peer-based co-production, and -- most importantly -- *consumer* Internet experiences. Mozilla doesn't build corporate content-management systems, or corporate IT solutions -- they have little expertise to offer there. Mozilla focuses on those point where the Internet and people come together. That's where these news innovation challenges aim to land as well: the place where news & people come together on the Internet.
And herein lies one of the big tensions: Many news organizations are _still_ thinking about innovation (as pointed out frequently on this list) through the lens of corporate IT.
There needs to be a radical shift toward thinking about news as a problem of creating successful consumer Internet experience vs. filling column inches or news holes, press deadlines, and delivery trucks. That is where the innovation and potential lies, I would propose, not in a re-arrangement of the chairs on the deck of the corporate IT Titanic inside of news organizations.
"Innovation should be aimed at the heart of what we do. Innovation should allow us to do exciting things with everyday news. Innovation should be all-encompassing. " http://stdout.be/2010/04/22/we-are-in-the-information-business/
Two cents,
Phillip.
Jonathan Eyler-Werve
not enough.
For the purposes of this contest, I think many of these issues can be
addressed by* requiring developers to talk to the end users *before they
start writing code. Ask the applicants these questions:
*
What problem are you solving?
Who has this problem?
What kind of research have you done to understand this problem**? (ie, who
have you talked to; did you visit them on site?; have you recruited
potential users into your team?)*
I think that will create better software, and perhaps even build community
in the process.
This idea is as old as the Cluetrain Manifesto, but I don't see a lot of
attention to users in these contests. It's so top-down. It's all about the
data and the tech stack. I think talking to people will lead to adoptable
solutions. Ignoring them will lead to kickass demos being posted to Github,
and then not being adopted. We can do better.
Cheers,
Jonathan
**
Jonathan Eyler-Werve // Director of Technology and Innovation //
www.globalintegrity.org
*
GLOBAL INTEGRITY*: Independent Information on Governance and Corruption
Direct: +1-202-449-8123 // Office: +1-202-449-4100 // Fax: +1-866-681-8047
Follow us on Twitter: http://twitter.com/globalintegrity
Matthew Terenzio
of these ideas about creating tools for news creators, not site end-users.
Journalists will need to be very technical for some time to come, or at
least have someone on their team that is. At least it seems to me that it
will be some time before a Journalist can create some of these end-products
in the way that they create a page with InDesign. I could be wrong, or
misunderstanding.
Jonathan Eyler-Werve
journalists/creators (defined broadly as people creating news content or
news-sharing venues), not the readers (people consuming information). We're
making tools for better story telling; we should talk to the storyteller and
ask what they need.
Daniel Chaffey
around an article, rather that something which addresses a journalism
lifecycle where public discussion is an integral part of the work - to me
this seems to be what you're saying.
But I see a slightly larger issue, in that you need three main reasons for
adoption
1. Institutional Benefit, both financial and externally / politically
2. Staff benefit for the editors and journalists
3. Public benefit
The most useful thing I could hear from a Journalist, when it comes to my
research on this topic, would be what the financial drivers were when they
last changed systems.
Is it advertising revenue? Harvesting user data through Facebook
integration? Analytics being channelled for marketing dollars? Lower support
costs?
After that I'll listen to points on public interaction features they'd like
to see, which as you rightly say, should definitely be a consideration. But
as I understand it this is what the internship section of the program is
intended to produce?
---------- Forwarded message ----------
From: Jonathan Eyler-Werve <jonathan.e...@globalintegrity.org>
Date: Wed, May 18, 2011 at 9:21 PM
Subject: Re: [mojo] Do you have a sharp red pencil & a passion for 'news
applications' ?
To: Discuss the Knight-Mozilla News Technology Partnership <
Ian Hill
Appreciate for a moment that there are many journalists out there who don't understand how to use Facebook, much less HTML/CSS. If you're going to create a tool for journalists, that's your target. I don't know if you could create anything more complex than Soundslides<http://www.soundslides.com/>. One of the reasons Storify<http://storify.com/> has taken off, besides the fact that it involves social media, is that it's so easy to use.
Cheers,
Jonathan
www.globalintegrity.org<http://www.globalintegrity.org>
*
GLOBAL INTEGRITY*: Independent Information on Governance and Corruption
Direct: +1-202-449-8123 // Office: +1-202-449-4100 // Fax: +1-866-681-8047
Follow us on Twitter: http://twitter.com/globalintegrity
On Wed, May 18, 2011 at 1:40 PM, Phillip Smith <p...@phillipadsmith.com<mailto:p...@phillipadsmith.com>
wrote:
http://stdout.be/2010/04/22/we-are-in-the-information-business/
Two cents,
Phillip.
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
__________________________________
Ian Hill
Community engagement specialist
KQEDnews.org<http://www.kqednews.org/>
Phone: (415) 553-2216
Follow KQED News on Facebook<http://Facebook.com/KQEDnews> and Twitter<http://twitter.com/kqednews>
Share your knowledge and become a KQED News source by joining the Public Insight Network<http://www.kqed.org/news/publicinsightnetwork/>
Ian Hill
At my last newspaper we used InCopy<http://www.adobe.com/products/incopy.html> for story production and Saxotech<http://www.saxotech.com/> as our website CMS. They did not necessarily play well together, and because of cost, our paper would occasionally skip upgrades. That, obviously, made things worse.
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org
Mark Surman
Awesome discussion.
As Phillip noted when he originally posted, we knew challenge #3 was off
base -- that's why we wanted input on how to reboot.
I know Phillip is close to a new challenge statement that includes much
(but definitely not all) of the feedback here.
A couple of personal opinions from my side:
- +1 on bottom up software design. We need to bend the challenge more
that way, so constructive ideas on how totally welcome.
-> Right now, the main way we're getting entries is via
Hacks/Hackers-like events, which are half journos / half devs so far.
We're seeing real collaborating and brainstorming at these events.
-> Also, the whole idea of the fellowships is to embed talented devs and
designers *with journalists* in places like Al Jazeera, etc. We've
picked the initial partners we have because they have good track records
doing dev + journalist collaboration. We'll also pick fellows based on
their ability to play well w/ journalists.
- Also +1 on not expecting journalists to be designers or techies.
-> Kind of ideas I am hoping to see personally are things that make hard
to do things like data viz and semantic video easy for journalists and
end users to work with.
-> This builds on Mozilla's history and strength: making hard to use
software simpler. That is the Firefox tradition and core to what we believe.
- Focus-wise, we're pretty consciously focused on software that is
public facing in some way, even if it's to help journalists.
-> e.g. we might get excited about fact checking and data mind workflow,
but in a way that involves readers.
-> This is again about building on the Mozilla community's strengths:
creating consumer facing software. Purely journalist focused software
starts to get into the enterprise realm, something that our community
has no real experience or strength with.
Again, these are only my opinions. We've got a whole group of people
reviewing and pitching in on the program. But figured some of these
thoughts might be useful in the mix.
ms
On 11-05-18 5:01 PM, Ian Hill wrote:
> +1 Jonathan. For further clarification, journalists don't create pages with inDesign. Journalists write / record / shoot. Page designers use inDesign. Multimedia producers create web content and manage websites. True, those three groups are merging at a rapid rate. But they're not merged yet, and they're not going to be merged before any product is created as a result of this thread.
> Appreciate for a moment that there are many journalists out there who don't understand how to use Facebook, much less HTML/CSS. If you're going to create a tool for journalists, that's your target. I don't know if you could create anything more complex than Soundslides<http://www.soundslides.com/>. One of the reasons Storify<http://storify.com/> has taken off, besides the fact that it involves social media, is that it's so easy to use.
>
>
>
> On May 18, 2011, at 12:54 PM, Matthew Terenzio wrote:
>
> I agree with the part about bottom up software development, but aren't some
> of these ideas about creating tools for news creators, not site end-users.
> Journalists will need to be very technical for some time to come, or at
> least have someone on their team that is. At least it seems to me that it
> will be some time before a Journalist can create some of these end-products
> in the way that they create a page with InDesign. I could be wrong, or
> misunderstanding.
>
> On Wed, May 18, 2011 at 3:34 PM, Jonathan Eyler-Werve<
> web to dramatically improve how we make& share news.
>
> Stijn's piece goes on to say "That technology should reach right into the
> core of our journalistic endeavors, not just touch the periphery like yet
> another infographic or mashup" and "The news industry needs to start
> thinking about journalism in terms of information and the myriad ways in
> which we can present that information to our readers."
>
> Yet, I hear a persistent hum from those working in newsrooms and those on
> this list of of "workflow, CMS, workflow, CMS!"
>
> **Is that not thinking about re-tooling the printing press vs. re-tooling
> the system of news itself?**
>
> What Mozilla brings to the table here is expertise in open culture,
> peer-based co-production, and -- most importantly -- *consumer* Internet
> experiences. Mozilla doesn't build corporate content-management systems,
> or
> corporate IT solutions -- they have little expertise to offer there.
> Mozilla
> focuses on those point where the Internet and people come together.
> That's
> where these news innovation challenges aim to land as well: the place
> where
> news& people come together on the Internet.
>
> And herein lies one of the big tensions: Many news organizations are
> _still_ thinking about innovation (as pointed out frequently on this
> list)
> through the lens of corporate IT.
>
> There needs to be a radical shift toward thinking about news as a problem
> of creating successful consumer Internet experience vs. filling column
> inches or news holes, press deadlines, and delivery trucks. That is where
> the innovation and potential lies, I would propose, not in a
> re-arrangement
> of the chairs on the deck of the corporate IT Titanic inside of news
> organizations.
>
> "Innovation should be aimed at the heart of what we do. Innovation should
> allow us to do exciting things with everyday news. Innovation should be
> all-encompassing. "
> http://stdout.be/2010/04/22/we-are-in-the-information-business/
>
> Two cents,
>
> Phillip.
>
> --
> Phillip Smith
> http://phillipadsmith.com
> http://twitter.com/phillipadsmith
> http://linkedin.com/in/phillipadsmith
>
>
>
>
>
>
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> __________________________________
> Ian Hill
> Community engagement specialist
> KQEDnews.org<http://www.kqednews.org/>
> Phone: (415) 553-2216
> Follow KQED News on Facebook<http://Facebook.com/KQEDnews> and Twitter<http://twitter.com/kqednews>
> Share your knowledge and become a KQED News source by joining the Public Insight Network<http://www.kqed.org/news/publicinsightnetwork/>
>
>
>
>
>
>
>
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/community-mojo
--
Derek Willis
to focus on what it does best and is most interested in. My point,
which I tried to make in spades to Phillip back in February, is that
if you want to make it easier for journalists to do things like data
viz or semantic video and you *don't* address the fundamental problems
in how newsrooms handle information, your impact is likely to be
lessened and fleeting. Yes, the fellows may do awesome work while in
house, and may even make it possible for a handful of others to
continue some of the work, but in terms of putting the tools in front
of the most people in order to get the results in front of readers,
you're just tinkering around the edges.
I say this as someone with 15 years in newsrooms and the past 4 doing
web development in them. For all of the amazing and wonderful things
that developers have done at my employer (NYT) and others, if tomorrow
we all disappeared those organizations - excepting pure Web orgs such
as ProPublica and the like - would not suffer a tremendous loss,
because we've rarely been allowed to work with the good stuff, the
actual materials of reporting and publishing the news. Maybe the best
path to follow is one where the software can exist in multiple
environments, like what DocumentCloud has been able to do via embeds.
But even that is, imho, not really solving the core problem that
prevents newsroom from truly providing the kind of news experience
that readers deserve, since it is detachable from the rest of the
newsroom's processes and products. DocCloud is an incredibly useful
tool that addresses a big need, but that need goes so far beyond
simply being able to intelligently and appealingly publish source
documents. It goes to the core of how newsrooms treat their
information and make it available to their users.
This is why I suggested that the fellows be placed within a single
chain or network like NPR, where they might be able to produce the
most results by getting deep into the actual processes. One person in
one newsroom for even a year is better than what most newsrooms have.
It is not, I believe, the best way to permanently move the practices
of journalists forward. In tech terms, it does not scale. Without
getting into the guts of how newsrooms do their jobs, the experience
is likely to prove frustrating for the people championing this good
idea. That would be a regrettable outcome.
Derek Willis
Phillip Smith
Hi folks,
In the hopes of continuing to enjoy the benefit of your wisdom, may I propose that we narrow the focus of this thread a bit?
1. I think it would be helpful to speak to personal experience vs. generalizations when possible, e.g., "In my experience as a journalist...," "In my experience as a developer...," "In my experience as a passionate news user..." (Kudos to Derek Willis for always starting with his experience! ;) )
2. I might also be helpful to remember that the 'user' in this thread is broader than just professional journalists, or publishers, or developers, or news users (or consumers, or readers, or whatever term you prefer) -- it's all of us. How the MoJo team originally framed it is like this:
> Geeks alone cannot keep the web open for the long haul. We also need teachers, artists, lawyers, journalists and everyone else who works and plays online to get involved. At the same time, it's not journalists alone that will reinvigorate news -- it will, at least in part, flow from the technology and culture of the open web.
3. For those new to the list, maybe it's the right time to reiterate why we're here discussing ideas and having these conversations. At its core, the Knight-Mozilla News Technology Partnership sets out to do three things:
+ Generate great ideas: through design challenges & open conversations;
+ Train people: on taking ideas from concept to code;
+ Make software: demos & reference implementations of the best ideas and experiments.
(Reference: http://www.phillipadsmith.com/2011/02/creating-a-space-for-journalism-technology-experimentation.html )
So, on that note, I'd like to say quickly:
+ In my experience as a technology consultant, I have seen a huge shift from the old way of doing software development on sites like SourceForge to the new forms of peer-based co-creation on social coding sites like Github. My question to you is: What is the equivalent paradigm shift when it comes to the creation and presentation of news, journalism, and reporting?
+ In my experience as a publishing consultant, I've heard professional journalists say "Twitter? I'll never use that," "Facebook? I'll never use that," "Google Docs? I'll never use that." But that has since changed. Most recently, at the Al Jazeera English forum in D.C., the head of AJE called Andy Carvin the "second most influential news organization in the world." Change *is* happening. Where are you seeing that change happen? What is the most exciting change you are seeing?
+ In my experience as a NICAR attendee this year (my first time! I can't recommend it highly enough.), I can say with confidence that many of you don't give yourselves, or your colleagues, enough credit when it comes to learning new technologies and the impact it has on your work, and -- to Derek's point -- in your organizations. At NICAR, I saw journalists using Github and Python and Django and loving it. Perhaps they are the exception, not the rule, but they are exception that is changing the Web, and -- in turn -- the Web changes them.
"The Web is changing, and we at the PBS Newshour are changing with it through experiments like these." - Hari Sreenivasan, PBS Newshour.
http://www.pbs.org/newshour/rundown/2011/01/experimenting-with-sotu-and-html5.html
Have a great Wednesday all. Talk to you tomorrow. :)
Derek Willis
> + In my experience as a NICAR attendee this year (my first time! I can't recommend it highly enough.), I can say with confidence that many of you don't give yourselves, or your colleagues, enough credit when it comes to learning new technologies and the impact it has on your work, and -- to Derek's point -- in your organizations. At NICAR, I saw journalists using Github and Python and Django and loving it. Perhaps they are the exception, not the rule, but they are exception that is changing the Web, and -- in turn -- the Web changes them.
=====
Make no mistake - they are a dramatic exception. And for many of them
- and I've experienced this first-hand - their employers don't know
what they do, why it's important, or why they should, when push comes
to shove, keep them over any other journalist. And it has been that
way for years for journalists with what we'd call "digital" skills.
They are viewed as luxuries, not essential. From that viewpoint, a
fellow is a nice addition, to be sure, but a temporary one - unless
they work at the core of the product.
Derek
Matthew Terenzio
create a page that queries data in a unique way and displays it, I consider
that journalism. Gathering data from Social Networks to tell a story is
journalism too. In fact, I might argue the design of a print page is
journalism because it affects how the reader perceives the importance of the
subjects by the layout. But that wasn't my intention with the mention of
InDesign, just the technical level of the end-user or the skill level.
That said, great journalism doesn't need technology, but techies are in a
position to do innovative things right now and I'm all for making these
tools accessible to a much wider group of users. That's what it's all about.
It does happen incrementally, sometimes.
> web to dramatically improve how we make & share news.
>
> Stijn's piece goes on to say "That technology should reach right into the
> core of our journalistic endeavors, not just touch the periphery like yet
> another infographic or mashup" and "The news industry needs to start
> thinking about journalism in terms of information and the myriad ways in
> which we can present that information to our readers."
>
> Yet, I hear a persistent hum from those working in newsrooms and those on
> this list of of "workflow, CMS, workflow, CMS!"
>
> **Is that not thinking about re-tooling the printing press vs. re-tooling
> the system of news itself?**
>
> What Mozilla brings to the table here is expertise in open culture,
> peer-based co-production, and -- most importantly -- *consumer* Internet
> experiences. Mozilla doesn't build corporate content-management systems,
> or
> corporate IT solutions -- they have little expertise to offer there.
> Mozilla
> focuses on those point where the Internet and people come together.
> That's
> where these news innovation challenges aim to land as well: the place
> where
> news & people come together on the Internet.
>
> And herein lies one of the big tensions: Many news organizations are
> _still_ thinking about innovation (as pointed out frequently on this
> list)
> through the lens of corporate IT.
>
> There needs to be a radical shift toward thinking about news as a problem
> of creating successful consumer Internet experience vs. filling column
> inches or news holes, press deadlines, and delivery trucks. That is where
> the innovation and potential lies, I would propose, not in a
> re-arrangement
> of the chairs on the deck of the corporate IT Titanic inside of news
> organizations.
>
> "Innovation should be aimed at the heart of what we do. Innovation should
> allow us to do exciting things with everyday news. Innovation should be
> all-encompassing. "
> http://stdout.be/2010/04/22/we-are-in-the-information-business/
>
> Two cents,
>
> Phillip.
>
> --
> Phillip Smith
> http://phillipadsmith.com
> http://twitter.com/phillipadsmith
> http://linkedin.com/in/phillipadsmith
>
>
>
>
>
>
>
Daniel Bachhuber
Brighton, John B
about a huge oil spill in the Gulf of Mexico (perish the thought). The
story refers to chemical dispersants poured into the water, the potential
impact on gulf fisheries and tourism, seepage from other oil wells, and
comparisons with other deep-ocean oil blowouts over the past 50 years. It
mentions federal agencies, state and local responders, and contractors
engaged in assessment and cleanup. The story provides a narrative about
what's happening, but it also connects that narrative to primary source
data on every element: the chemical dispersants and whatever research has
been done on them; data on the size and nature of the gulf fisheries and
tourism sectors, mapped against the growing spill; locations of other
active, abandoned, and test wells in gulf waters, presented as maps or
sortable lists by owner, activity status, age, depth, risk and other
facets; maps or lists (or lists that link to maps) of other oil spills
with parameters for comparison, including size, economic and ecological
impact, ownership and jurisdiction, outcomes of regulatory response,
criminal and civil liability, and scientific research; plus links to data
on the agencies, people, and corporate interests mentioned. I think that
semantics can provide a method for automagically mashing up deep layers of
data, and the story becomes starting point for exploration by the human
user.
What do you need to do this? I think mostly just metadata and links. With
good metadata, you can build links that say what kind of links they are.
Then you build applications that mine these links as data which you can
mash up with other links as data from other sources. Now you can build a
user interface to explore all that data, with your story narrative as the
default view.
Journalists won't write the code for this, they mainly just have to write
the story. I would argue, though, that journalists need to adopt strong
new practices with adding key metadata, which seeds the news in the
growing web of linked data.
Best regards,
Jack Brighton
>--
>Phillip Smith
>http://phillipadsmith.com
>http://twitter.com/phillipadsmith
>http://linkedin.com/in/phillipadsmith
>
>_______________________________________________
>community-mojo mailing list
>communi...@lists.mozilla.org
ih...@kqed.org
(And as someone who now works at a public media outlet, I think I can say that many member stations would be thrilled to host a fellow, even if in the end the experience benefits the fellow more.)
______________________________
*Sent from my iPhone. Please excuse any typos.
Wray Cummings
of the story. Instead of an event visible from space let's say a tornado
hits a small town in Alabama. Prior to the unfortunate natural event this
town's streets have been thoroughly spidered by Google's Street View
vehicles. A timely revisit to the disaster scene by the Google cam-car (or
handheld if streets are not vehicularly accessible) synced to the pre-storm
Street View can wordlessly tell a huge part of this news story. This is
doable (assuming the application software existed before the storm).
> >_______________________________________________
> >community-mojo mailing list
> >communi...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/community-mojo
>
--
Wray Cummings
402.419.3889
Scott Klein
________________________________________
From: community-mojo-bounces+scott.klein=propubl...@lists.mozilla.org [community-mojo-bounces+scott.klein=propubl...@lists.mozilla.org] On Behalf Of Mark Surman [ma...@mozillafoundation.org]
Sent: Wednesday, May 18, 2011 5:21 PM
To: Discuss the Knight-Mozilla News Technology Partnership
Subject: Re: [mojo] Do you have a sharp red pencil & a passion for 'news applications' ?
Hey all
Awesome discussion.
ms
> On Wed, May 18, 2011 at 1:40 PM, Phillip Smith<p...@phillipadsmith.com<mailto:p...@phillipadsmith.com>
> wrote:
>
>
> On 2011-05-17, at 3:03 PM, Daniel Bachhuber wrote:
>
> Following up on Scott's points, I've always thought Stijn's piece
> accurately summarizes the billion dollar opportunity:
>
> http://stdout.be/2010/04/22/we-are-in-the-information-business/
>
> When I first heard about the challenge from Phillip, this is what
> immediately came to mind. It's 10% actual technology though, and 90%
> getting
> the workflow/organization/culture to adopt it.
>
> That's a curious take on Stijn's piece, IMHO.
>
> Stijn says: "But we’re forgetting the most important point at issue: what
> should a news website look like in 2010 and beyond? The fundamentals of
> website design and information architecture somehow lack appeal as a
> topic
> for debate among journos."
>
> When I read that piece in the context of this thread, I thought it drove
> to
> the core of what this third challenge is all about: How would you use the
> web to dramatically improve how we make& share news.
>
> Stijn's piece goes on to say "That technology should reach right into the
> core of our journalistic endeavors, not just touch the periphery like yet
> another infographic or mashup" and "The news industry needs to start
> thinking about journalism in terms of information and the myriad ways in
> which we can present that information to our readers."
>
> Yet, I hear a persistent hum from those working in newsrooms and those on
> this list of of "workflow, CMS, workflow, CMS!"
>
> **Is that not thinking about re-tooling the printing press vs. re-tooling
> the system of news itself?**
>
> What Mozilla brings to the table here is expertise in open culture,
> peer-based co-production, and -- most importantly -- *consumer* Internet
> experiences. Mozilla doesn't build corporate content-management systems,
> or
> corporate IT solutions -- they have little expertise to offer there.
> Mozilla
> focuses on those point where the Internet and people come together.
> That's
> where these news innovation challenges aim to land as well: the place
> where
> news& people come together on the Internet.
>
> And herein lies one of the big tensions: Many news organizations are
> _still_ thinking about innovation (as pointed out frequently on this
> list)
> through the lens of corporate IT.
>
> There needs to be a radical shift toward thinking about news as a problem
> of creating successful consumer Internet experience vs. filling column
> inches or news holes, press deadlines, and delivery trucks. That is where
> the innovation and potential lies, I would propose, not in a
> re-arrangement
> of the chairs on the deck of the corporate IT Titanic inside of news
> organizations.
>
> "Innovation should be aimed at the heart of what we do. Innovation should
> allow us to do exciting things with everyday news. Innovation should be
> all-encompassing. "
> http://stdout.be/2010/04/22/we-are-in-the-information-business/
>
> Two cents,
>
> Phillip.
>
> --
> Phillip Smith
> http://phillipadsmith.com
> http://twitter.com/phillipadsmith
> http://linkedin.com/in/phillipadsmith
>
>
>
>
>
>
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> __________________________________
> Ian Hill
> Community engagement specialist
> KQEDnews.org<http://www.kqednews.org/>
> Phone: (415) 553-2216
> Follow KQED News on Facebook<http://Facebook.com/KQEDnews> and Twitter<http://twitter.com/kqednews>
> Share your knowledge and become a KQED News source by joining the Public Insight Network<http://www.kqed.org/news/publicinsightnetwork/>
>
>
>
>
>
>
>
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/community-mojo
--
Mark Surman
Executive Director
Mozilla Foundation
ma...@mozillafoundation.org
commonspace.wordpress.com
Jeff Stanger
Some sobering thoughts from Derek, Scott, et al. It sounds like what's at play here are several sets of barriers -- technical yes, but perhaps more importantly, structural and psychological. First, pep talk -- the journalism industry, as evidenced by the end product that emerges each day, is in much better shape than other fields. There are truly revolutionary things happening in the presentation of information. They might not happen often enough or easily enough, but they are happening. (It is my goal to bridge those techniques to other legacy non-journalism institutions.)
In my experience, visible examples win the day -- but only if...
a) they are created in direct collaboration with information "gatherers," in your case "reporters," giving voice to their stories with the technology, rather than an independent/parallel activity. Taking the Gov 2.0/open gov movement as a case study -- a lot of that IMO is techies coming into institutions and demanding data for what end up being independent projects... great stuff results no doubt, but without enlisting the actual *gatherers* of the information and changing their methods and output, the structural and psychological barriers remain (and not to mention funding gets threatened because value isn't immediately apparent to non-techies). "Collaboration" is sort of a meaningless buzzword in a lot of cases, so it has to be real.
b) they are documented -- a roadmap... What skills were needed and when were they involved? Was it serendipitous or intentional? What common vocabulary was established to bridge the gap between techs and non-techs? How long did it take? What was the cost? Is the end product reproducible every time with increased efficiency?
Most non-techies I've talked to, when they see the sorts of interactive products that are possible, *DO* want them...and quickly...and always. They just don't know how to get there, and most of all want to ensure that these new forms preserve the integrity of their efforts. So solving the technology once or twice is good, but collaboration and replicable roadmaps I think are part of the answer to breaking down the substantial structural and psychological barriers in "digital-second" institutions.
I look forward to watching this thread more. I am interested in the solutions and how you arrive at them. They will have application outside commercial journalism/news.
Jeff Stanger
Center for Digital Information
http://digitalinfo.org
http://twitter.com/jeffcdi
J. Heasly
J. Heasly
jacob fenton
reporter and another 4 as something in between, it seems to me that the apps
challenge's apparent focus on data presentation tools -- rather than
internal / data gathering tools that might integrate deeply with / replace a
newsroom's own editing software / cms / etc -- also misses an opportunity to
use what I think of as a core strength of Mozilla: exploiting the browser as
a tool-building platform loosely coupled to a modular backend for technical
non-sophisticates (aka reporters) to use. I confess I have no idea what
Mozilla actually does--but even without any actual knowledge of what they do
I still love them to death because they built the platform that makes
firebug, and s3 organizer, and all the other firefox plugins I rely on
possible.
When I heard that the Mozilla was doing the challenge, my first thought was
of a Firefox plugin that, if memory serves, Tom Torok talked about at a
NICAR a few years back (maybe Brian Hamman was on the panel too, or worked
on building the plugin? ). Developed as an internal NYT tool, it allowed
reporters, from their browsers, to suck documents (pdfs? web pages?) into an
internal database hooked up with fancy-dancy data-mining/entity extraction
software. So, just by browsing the web with the plugin running (and clicking
an add-to-corpus-type-button when they found a choice document) reporters
could build a well tagged/parsed/semantically-hoo-hawed collection of
'evidence' to build their stories from, and maybe even leads to follow. (I
may be getting crucial details dramatically wrong here, so if anyone out
there knows how this process actually worked--or if it worked--please
correct me.) Would building a stripped-down version of that project fit
within the apps challenge? Or would a presentation tool have to be welded
onto it to shoehorn it in as an entry?
My point, I think, is that there's a pretty viable data viz community out on
the webbernets building nifty tools that make awesome visualizations
accessible to non-techies--and they'd keep doing so if all news media went
away (I include mapping as data viz, of course). But it's a much thinner
crowd building newsgathering/reportering-specific apps, so I can't help but
be a bit bummed if internally-focused tools aren't part of the apps
challenge (of course, internal vs external tools is a false dichotomy; the
best tools are both: see documentcloud ). Maybe later in the process there
will be a challenge with room for this sorta thing? I get that Mozilla wants
to build something that helps everyone--but ultimately journalistic tools
are gonna diverge from what teachers/artists want to use. Maybe we can add
prosecutors, private investigators, financial analysts and congressional
research staffers to the list of whom the challenge might benefit?
--
Jacob Fenton
Director of Computer-Assisted Reporting
Investigative Reporting Workshop
American University School of Communications
investigativereportingworkshop.org
On Wed, May 18, 2011 at 5:57 PM, Phillip Smith <p...@phillipadsmith.com>wrote:
>
> Hi folks,
>
> In the hopes of continuing to enjoy the benefit of your wisdom, may I
> propose that we narrow the focus of this thread a bit?
>
> 1. I think it would be helpful to speak to personal experience vs.
> generalizations when possible, e.g., "In my experience as a journalist...,"
> "In my experience as a developer...," "In my experience as a passionate news
> user..." (Kudos to Derek Willis for always starting with his experience! ;)
> )
>
> 2. I might also be helpful to remember that the 'user' in this thread is
> broader than just professional journalists, or publishers, or developers, or
> news users (or consumers, or readers, or whatever term you prefer) -- it's
> all of us. How the MoJo team originally framed it is like this:
>
> > Geeks alone cannot keep the web open for the long haul. We also need
> teachers, artists, lawyers, journalists and everyone else who works and
> plays online to get involved. At the same time, it's not journalists alone
> that will reinvigorate news -- it will, at least in part, flow from the
> technology and culture of the open web.
>
> 3. For those new to the list, maybe it's the right time to reiterate why
> we're here discussing ideas and having these conversations. At its core, the
> Knight-Mozilla News Technology Partnership sets out to do three things:
>
> + Generate great ideas: through design challenges & open conversations;
> + Train people: on taking ideas from concept to code;
> + Make software: demos & reference implementations of the best ideas and
> experiments.
>
> (Reference:
> http://www.phillipadsmith.com/2011/02/creating-a-space-for-journalism-technology-experimentation.html)
>
> So, on that note, I'd like to say quickly:
>
> + In my experience as a technology consultant, I have seen a huge shift
> from the old way of doing software development on sites like SourceForge to
> the new forms of peer-based co-creation on social coding sites like Github.
> My question to you is: What is the equivalent paradigm shift when it comes
> to the creation and presentation of news, journalism, and reporting?
>
> + In my experience as a publishing consultant, I've heard professional
> journalists say "Twitter? I'll never use that," "Facebook? I'll never use
> that," "Google Docs? I'll never use that." But that has since changed. Most
> recently, at the Al Jazeera English forum in D.C., the head of AJE called
> Andy Carvin the "second most influential news organization in the world."
> Change *is* happening. Where are you seeing that change happen? What is the
> most exciting change you are seeing?
>
> + In my experience as a NICAR attendee this year (my first time! I can't
> recommend it highly enough.), I can say with confidence that many of you
> don't give yourselves, or your colleagues, enough credit when it comes to
> learning new technologies and the impact it has on your work, and -- to
> Derek's point -- in your organizations. At NICAR, I saw journalists using
> Github and Python and Django and loving it. Perhaps they are the exception,
> not the rule, but they are exception that is changing the Web, and -- in
> turn -- the Web changes them.
>
> "The Web is changing, and we at the PBS Newshour are changing with it
> through experiments like these." - Hari Sreenivasan, PBS Newshour.
>
> http://www.pbs.org/newshour/rundown/2011/01/experimenting-with-sotu-and-html5.html
>
> Have a great Wednesday all. Talk to you tomorrow. :)
>
> Phillip.
>
> --
> Phillip Smith
> http://phillipadsmith.com
> http://twitter.com/phillipadsmith
> http://linkedin.com/in/phillipadsmith
>
>
>
>
>
>
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
Josh Wilson
what a reporter needs and how technology can help ... but most
importantly, it posits this technological advance as necessarily
breaking from the proprietary infrastructure of a legacy news
organization like the NYT to become an open-source service. What's
more, it assumes that this technology will be little more than a
plugin for your browser, i.e. easy and free and requiring no
complicated installation shenanigans.
So those are very important steps towards Open Journalism and the Open
Internet.
The one thing I would add, though -- where's the database gonna live
that will interface with the data-mining/entity-extraction software?
If that could again be a giant public repository and tool -- wow, what
a boon to the practice of journalism.
This is in the end about the practice of journalism, independent of
platforms, outlets, organizations, brands, etc. Open Journalism is
about the practice of journalism wherever it happens.
josh / newsdesk.org
Phillip Smith
On 2011-05-18, at 6:49 PM, Daniel Bachhuber wrote:
> I think I've solved journalism. Based on my experience as a newsroom & J-School developer who's had repeat experience with crappy vendor software, this Knight-Mozilla challenge needs to do to crappy CMSes & support ticketing software what Google Chrome Frame has done to IE6,7,8. We must subvert corporate IT like nobody's business.
The 'crappy CMS' is the horse and buggy.
'Subverting corporate IT' and waiting for perfect CMS is like asking for faster horses.
We need to be thinking about *cars* (or Jet-packs).
(With my compliments to @gsamek for the reference to innovators dilemma: http://geoffsamek.com/knight-i-know-you-can-do-it-right-part-deux )
jacob fenton
open calais, and already exists as a big public repository. The document
cloud source is public, and it'll ocr and run open calais on whatever you
throw at it--I believe with some (or perhaps lots and lots and lots?) of
work one could create a clone of the complete document cloud stack on one's
own amazon instances and use that as a backend (though that might take more
than a little bit of elbow grease). In theory one could just feed documents
into documentcloud (i.e. not on one's own clone ) directly, though one
wouldn't wanna slam their servers if one was processing a large corpus. The
entities can be a bit off (one of my favorites is a person named 'firearm
riot' ), but in general pretty darn good for the price.
The one thing that having a browser-based plugin could do is treat the
human-readable part of a web page as a document. And if there was some sorta
API attached and time permitted, one could take as input thousands of
documents, or the results of a google search query.
--jf
On Thu, May 19, 2011 at 1:15 PM, Josh Wilson <jo...@newsdesk.org> wrote:
>
> The one thing I would add, though -- where's the database gonna live that
> will interface with the data-mining/entity-extraction software? If that
> could again be a giant public repository and tool -- wow, what a boon to the
> practice of journalism.
>
>
>
>
>
> On May 19, 2011, at 9:54 AM, jacob fenton wrote:
>
> Developed as an internal NYT tool, it allowed
>> reporters, from their browsers, to suck documents (pdfs? web pages?) into
>> an
>> internal database hooked up with fancy-dancy data-mining/entity extraction
>> software. So, just by browsing the web with the plugin running (and
>> clicking
>> an add-to-corpus-type-button when they found a choice document) reporters
>> could build a well tagged/parsed/semantically-hoo-hawed collection of
>> 'evidence' to build their stories from, and maybe even leads to follow. (I
>> may be getting crucial details dramatically wrong here, so if anyone out
>> there knows how this process actually worked--or if it worked--please
>> correct me.) Would building a stripped-down version of that project fit
>> within the apps challenge?
>>
>
Daniel Lathrop
Phillip, your blog post today about CMSes is right, a great new CMS
will not fix out problems. On the other hand, many of the problems we
have are hard-coded into the DNA of our content-management systems.
The story-centric worldview (where a print or video "story" is the
primary unit of content) and anything else is a second-class (or
third-class) citizen is a major stumbling block to the future.
To Derek's points and the big picture for the future of big-J
journalism, it would be great if Mozilla can take steps catalyze the
needed changes to the institutional views the predominate in an
industry where the oldthink of smug print/broadcast oligopolies has
now been grafted onto the Web world (see for example, the hilariously
bad ASNE whitepaper on social media "best practices"
http://bit.ly/kUgBYD ).
-Daniel
---------------------------
Daniel Lathrop
News Applications Editor
The Dallas Morning News
dlat...@dallasnews.com
daniel....@gmail.com
206.718.0349 (cell)
Scott Klein
and habits of the newsroom are restated in the rules that govern the
(customizeations to the CMS), and the CMS in turn enforces the values and
habits of the organization. Hard to change one without changing the other.
That's why, subconsciously I think, I've been so reluctant to want to
"hack at the core." Because I'd rather make things than convince people
they want to change their ways.
But my blog post will be way smarter. Funny even.
--
Scott Klein
Editor of News Applications
ProPublica <http://www.propublica.org/>
office: 917 512-0205
twitter: @kleinmatic
Rhiannon Coppin
trading the crappy CMS 'horse-and-buggy' for fancy new cars (which just
create more problems, as we've found out); we should perhaps be looking for
the simpler, more elegant solution -- something more like a bicycle.
Rhiannon
@rhiannoncoppin
For the record, I was an electronics engineering student and coder for seven
years, a freelance writer and newsroom journalist for seven years... and now
I am a crappy user-interface and crappy CMS expert, and I have no idea what
I want to be when I grow up.
Josh Wilson
and spurring new thinking. So in terms of efficiency and elegance, I'd
like to do away with CMSes altogether, and just have the content
itself as sovereign, self-promoting, and self-maintaining. In other
words, content should be its own ambassador, its own reporting
mechanism and its own instrument of quality control.
Perhaps we can reverse-engineer the goal (of content being independent
from the CMS) by identifying the standards required for ultimately
portable, coherent-but-remixable, platform-agnostic CONTENT.
At minimum, I would propose that liberated content should be able to
appear anywhere, in any recombination, on any platform, without having
specifically to be published by WordPress or Drupal or Joomla or
whatever, with version control identifying how it's changed or forked
since it was originally released into the medium, with all the
comments attached to its various incarnations/editions aggregated,
with all the citations and data sets and entities similarly tracked.
In other words: This liberated content would be coherent but
remixable, completely independent of its source -- but capable of
reporting to that source (or any user) all data about how it's been
used, modified, remixed, talked about, cited, etc.
* What are the performance standards -- the qualities and capabilities
-- required for any content item to do that?
* Would the app-as-content be a means to do this? In the end, is it
all about HTML5 and browsers?
josh / newsdesk.org
Bill Densmore
Yes, in the end its about the most standard, most network-ready, most
HTML-compliant format. If everything writes/produces to that, and
everything reads/pulls from that, you have the atomic building block of
content and can go from there.
So the requirement of any content remixing tool is that it always be able
to consume from HTML and always be able to output to HTML -- with as close
to no intervention or fiddling as possible.
-- bill densmore
http://www.frompapertopersona.org
"From Paper to Persona: Managing Privacy & Information Overload;
Sustaining Journalism in the Attention Age."
--
-------------------------------------
Bill Densmore, Consulting Fellow
Reynolds Journalism Institute
University of Missouri
Columbia MO 65211
mobile: 617-448-6600
dens...@rjionline.org
@infovalet
DISCLOSURE: http://newshare.com/wiki/index.php/Disclosure
"BEYOND BOOKS: News, literacy, democracy and America's Libraries"
Advancing a common mission for journalists and librarians
WRAUP REPORT: http://www.biblionews.org
"From Paper to Persona: Managing Privacy & Information Overload; Sustaining Journalism in an Attention Age"
http://www.papertopersona.org
Scott Klein
This would be impossible with the current CMSes, and reporters and editors would need to rearrange their heads a lot to accept this. But it would actually map very closely to how journalists themselves read the news ("what does this story add?") and it would give proper credit to newsgathering in a very granular way.
So I guess what I'm saying is it's kinda crazy but it just. Might. Work.
From Sue's
Kunal Bhalla
for quite a few days. I'm speaking as a recent engineering graduate with
some experience in web dev and open source projects—and I was wondering if
it would be possible for a few of the journalists on this group to point
me/us to their workflows in writing and publishing an article (focusing on
the tech they currently use and how they use it, but also a basic overview
of everything else—the review process, how/who makes related infographics,
et al).
For any app to gain traction and be actually useful it shouldn't come in the
way of a journalist writing an article and getting his point across
directly, and for users to be able to read and follow through the article
with references and date (including improved discussions and integrated
video)—essentially, something intuitive and really easy to use. However,
while I—and perhaps quite a few other people here?—have a lot of experience
consuming—and observing people consume—information on the net, I have never
had access to the other side, as it were.
That might help us make slightly better entries for the third challenge, and
perhaps improve our submissions to the 1st two. Thanks in advance for any
suggestions/links/etc!
Kunal
PS. my entry for the 2nd challenge is at (
http://kunalb.github.com/MoJo/beyond-comment-threads/<http://kunalb.github.com/MoJo/beyond-comment-threads/#4>
,
https://www.drumbeat.org/en-US/challenges/beyond-comment-threads/submission/179/
).
Wray Cummings
experience
consuming—and observing people consume—information on the net, I have never
had access to the other side, as it were."
This inquiry pokes diagnostically at the practical problem of bringing the
web into the newsroom. Coincidentally, I started watching season five of *The
Wire* last night which suggests another way to raise these same issues.
1) How realistic is the *Baltimore Sun *newsroom portrayed by this series?
2) How grounded to reality is Clark Johnson's City Editor Gus Haynes? (And
how, and to what degree, are these subjects dramatically enhanced?)
--
Wray Cummings
402.419.3889
Ian Hill
In addition, the process for a newspaper is different from that of a television or radio station.
But, very generally, here's the process for a morning newspaper, which is most newspapers at this point:
1. The story can start when the reporter gets a tip or an idea - perhaps from a reader, a meeting agenda, a government official at a public meeting, or an email or social media. It also can start when an editor - whose motivations can vary - assigns an idea for a story to a reporter.
2. The reporter often summarizes the idea for a story in an email and sends it back to his or her editor as a story pitch. The editor reads that pitch at a daily planning meeting of newsroom management - section editors, managing editors and the executive editor. Often, the pitches are read without comment from others at the meeting. However, at times newsroom management raises questions to be addressed in the story that are then communicated back to the reporter via his or her editor as questions that the story must answer. Newsroom management also can kill a story idea. (I'm writing this email while attending the morning assignment meeting here, actually.)
3. While the meeting is happening, the reporter often contacts a member of the photo staff to try an schedule a photo shoot related to the story. (Most readers do not understand how important a photo is to the final publication of the story. A story can be hard-hitting and vital to the interests of the community, and it still may go inside the paper if it doesn't have a photo.) At more and more newspapers, the reporter will be required to shoot the photo, typically on a small digital point-and-shoot camera.
4. If there is a data visualization possibility, the reporter may talk to a member of his or her publication's graphics staff or perhaps a page designer who doubles as the graphics person. The reporter will be responsible for getting the data to the graphics person.
5. Depending on how advanced your publication is, the reporter also may talk to the online or multimedia editor about ideas for video or interactive features that may or may not be be created for the story by the online/multimedia staff or the reporter.
6. The reporter then may have to file a graphics/photo/interactive request form with all the necessary data. This can be anything from a paper sign-up sheet to an online, in-house form.
7. While all this is going on, the reporter typically also is starting his or her reporting by making phone calls to sources. He or she may take notes in Word or another text editing program, or on paper with a pen. He or she also may leave the office and go to a news scene. While some reporters use digital recorders while interviewing sources, and a few use smartphones, many still use pen-and-paper.
8. By early afternoon, the reporter is back at his or her desk and ready to start writing. This happens in a program like InCopy, although it differs from publication to publication.
9. The reporter and editor also communicate about any changes to the story and confirm what other elements go along with it - a photo, an interactive feature, graphic, etc. The reporter may send the editor an updated pitch via email.
10. Newsroom management may have an afternoon meeting at which they hear updated pitches and determine what will be published in what section of the paper.
11. When the reporter is done with his or her story, perhaps at 5 or 6pm, he or she will "file" the story by changing the workflow in his or her organization's workflow CMS - at my last newspaper, it was Jazbox - and sending an email to an editor letting he or she know. Each publication has its own workflow.
12. The editor reads the story for content and grammar. He or she may put questions in a note in the story and send the story back to the reporter to be updated.
13. Once the editor is satisfied, he or she will move the story ahead in the workflow to a copy editor.
14. The copy editor is meant to read the story for spelling or grammar. However, he or she also may have a question on the content. They would take it back to the editor, who would have final say on content issues. The editor may send it back to the reporter.
15. Once the copy editor is satisfied, he or she would move it ahead in the workflow to the page designer, although the copy editor and page designer may be one and the same.
16. Meanwhile, the photographer and graphic designer will have filed any photos or inforgaphics in .eps format in the workflow CMS. An editor or reporter may or may not have seen the infographic before it was filed. Most of the graphic designers I've worked with use Illustrator; for the photogs, it has varied.
17. The page designer will put the story and any related photos or inforgraphics into something like InDesign and try and fit it into a hole they have on a page. In the end, the paginator may ask the reporter to shorten the story to fit a space. The paginator also may just lop off the last few paragraphs of the story. The paginator also will probably finalize or write the headline to fit the space available. Fewer and fewer newspapers are allowing stories to "jump" from one page to another; the goal is often to keep the story in its entirety on one page.
18. Once all the stories are done on the page, the paginator will move the page ahead in the workflow to production, who will work their magic with printing it. I've never worked in a pressroom, but I imagine the workflow depends on your press. Some presses are decades old.
19. How the story makes it to the newspaper's website depends on the website CMS and workflow CMS. At my last newspaper, we used Saxotech for our website CMS. A page designer designated as the night updater (it was a rotating responsibility) would "transmit" the story and all its elements - photo, graphic, etc. - from Jazbox to Saxotech. Transmission took at least 5 min. The updater was then responsible for logging into Saxotech and making sure all the elements had arrived and everything was set in Saxotech so the story would appear in the right place in the right section of the website. The version of Jazbox we used had no social media or HTML capabilities, so if we wanted to link text in the story, we had to hand-code it. For that reason, we never linked text in the story. Any automated sharing on FB or Twitter was done through RSS.
And the next day, we repeated the whole process.
On May 22, 2011, at 10:30 AM, Wray Cummings wrote:
"However, while I—and perhaps quite a few other people here?—have a lot of
experience
consuming—and observing people consume—information on the net, I have never
had access to the other side, as it were."
This inquiry pokes diagnostically at the practical problem of bringing the
web into the newsroom. Coincidentally, I started watching season five of *The
Wire* last night which suggests another way to raise these same issues.
1) How realistic is the *Baltimore Sun *newsroom portrayed by this series?
2) How grounded to reality is Clark Johnson's City Editor Gus Haynes? (And
how, and to what degree, are these subjects dramatically enhanced?)
Kunal
https://www.drumbeat.org/en-US/challenges/beyond-comment-threads/submission/179/
).
On Sat, May 21, 2011 at 9:03 AM, From Sue's <suec...@aol.com<mailto:suec...@aol.com>> wrote:
Anything useful for this discussion from wolfram alpha
josh / newsdesk.org<http://newsdesk.org>
On May 20, 2011, at 2:01 PM, Rhiannon Coppin wrote:
I don't mean to hijack this thread by arguing metaphors, but instead
of
trading the crappy CMS 'horse-and-buggy' for fancy new cars (which
just
create more problems, as we've found out); we should perhaps be
looking
for
the simpler, more elegant solution -- something more like a bicycle.
Rhiannon
@rhiannoncoppin
For the record, I was an electronics engineering student and coder
for
seven
years, a freelance writer and newsroom journalist for seven years...
and
now
I am a crappy user-interface and crappy CMS expert, and I have no
idea
what
I want to be when I grow up.
On Thu, May 19, 2011 at 11:26 AM, Phillip Smith
<p...@phillipadsmith.com<mailto:p...@phillipadsmith.com>>wrote:
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
--
-------------------------------------
Bill Densmore, Consulting Fellow
Reynolds Journalism Institute
University of Missouri
Columbia MO 65211
mobile: 617-448-6600
dens...@rjionline.org<mailto:dens...@rjionline.org>
@infovalet
DISCLOSURE: http://newshare.com/wiki/index.php/Disclosure
"BEYOND BOOKS: News, literacy, democracy and America's Libraries"
Advancing a common mission for journalists and librarians
WRAUP REPORT: http://www.biblionews.org
"From Paper to Persona: Managing Privacy & Information Overload;
Sustaining Journalism in an Attention Age"
http://www.papertopersona.org
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/community-mojo
--
Wray Cummings
402.419.3889
_______________________________________________
community-mojo mailing list
Ian Hill
2. It varies. I've worked with driven "true believers" not unlike Johnson's character. They've been great to work with, but they've often ended up where that character ended up. At the same time, I've worked with editors who seem very happy where they are and want to do as little to make waves as possible.
Wray Cummings
this piece, but my immediate takeaway is this: the biggest baddest dude in
the newsroom is not the accountants, the editors, the advertisers, or the
news hole, it's Time. Or, because it's well worth repeating --
"And the next day, we repeated the whole process."
--
Wray Cummings
Ted Han
should help you accomplish what you want, and not get in your way.
Sometimes that requires realigning a user's workflow a bit, and sometimes
that requires building new tools. But if you're not helping your users do
what they want as quickly as they can, then everyone's got a problem. :)
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
Jake Bayless
My experience is vastly different as I've been involved in digital-only
hyperlocal news & public broadcasting workflows for the last several years.
The face|face interaction to develop a story is significantly less in my
environment & I'd argue it's vastly more efficient... but not necessarily
any better, as it's cobbled together & not standardized.
It would seem to me that the ideal solution to come out of this project
needs to be a birth to death digital article-ish workflow (something that
can equally perform the necessary data gathering for text, audio, video,
imagery, for corporate, nonprofit and even community information
organizations).
I can think of a myriad of ways to do this - for example, using Microsoft
Sharepoint a story would/could be a "list item" that had several dozen
fields and checklists, email alerts and approvals, and a final publication
trigger + workflow. Joomla, Plone, Wordpress & Django are nowhere near as
easy without a developer to create something for the
participants/contributors. I saw a presentation at the Microsoft Sharepoint
2010 conference a year and a half ago by staff from the AP - and what they
had put together for their contributors was very impressive. But what's not
developed & widely accepted are the parameters they/we all use. (I haven't
seen mention of *licensing* on this MoJo thread yet either... every piece of
work should have some license attached to it - preferably a standard license
paradigm like Creative Commons)
So, to offer a starting point:
A recognition is due here for someone who already HAS worked out this
digital inception to delivery workflow and that would be David Cohn over at
http://Spot.us... it just so happens that his model also is driven around
the killer-app of a crowd-funding model (something every newsroom should
have the capability to leverage at their discretion). But what if the
Spot.us system was used as a data gathering template for gathering the
necessary components of story development workflow & metadata? I think it'd
be useful... and it's another Knight open-source community journalism
project.
Wouldn't it be great if the whole birthing to delivery process for each
individual piece of work could be selectively exposed (a la wiki) to the
consuming public at the publishers/editors/authors discretion? I imagine
this to mean great flexibility and transparency inside a news org ("hey,
what you workin on?") as well as a means by which the public can more easily
understand and vet the credibility of any piece of work.
Hard not to be excited by all of this!
Kindly,
jake bayless
ja...@northbayvoice.org
Ian Hill
Spot.us<http://Spot.us> system was used as a data gathering template for gathering the
necessary components of story development workflow & metadata? I think it'd
be useful... and it's another Knight open-source community journalism
project.
Wouldn't it be great if the whole birthing to delivery process for each
individual piece of work could be selectively exposed (a la wiki) to the
consuming public at the publishers/editors/authors discretion? I imagine
this to mean great flexibility and transparency inside a news org ("hey,
what you workin on?") as well as a means by which the public can more easily
understand and vet the credibility of any piece of work.
Hard not to be excited by all of this!
Kindly,
jake bayless
ja...@northbayvoice.org<mailto:ja...@northbayvoice.org>
_______________________________________________
community-mojo mailing list
communi...@lists.mozilla.org
https://lists.mozilla.org/listinfo/community-mojo
__________________________________
Jake Bayless
On Mon, May 23, 2011 at 11:03 AM, David Cohn <Da...@spot.us> wrote:
> Thanks Jake
>
> Nice to meet you all ;)
>
> I don't know the full background of the discussion - but if anyone thinks I
> can ever be of help, just contact me.
>
> best
> David
>> Spot.us system was used as a data gathering template for gathering the
>> necessary components of story development workflow & metadata? I think it'd
>> be useful... and it's another Knight open-source community journalism
>> project.
>>
>> Wouldn't it be great if the whole birthing to delivery process for each
>> individual piece of work could be selectively exposed (a la wiki) to the
>> consuming public at the publishers/editors/authors discretion? I imagine
>> this to mean great flexibility and transparency inside a news org ("hey,
>> what you workin on?") as well as a means by which the public can more easily
>> understand and vet the credibility of any piece of work.
>>
>> Hard not to be excited by all of this!
>>
>> Kindly,
>> jake bayless
>> ja...@northbayvoice.org
>>
>>
>
>
> --
> David Cohn
> (310) 365-3600
> http://Spot.Us
> [image: Follow me on twitter]<http://movableink.com/twitter_pics/157/link>
>
>
>
Ted Han
Thanks for a detailed look at a newsroom workflow. As a developer and
someone who's familiar with some publishing workflows, it's useful to see
this process at this granularity.
I've had conversations with tech people in news organizations who have
remarked that the tech that has built up in news rooms has tended to codify
a news room's workflow into a rigid system from which deviation isn't
feasible or possible. I don't know to what degree that is a mentality that
has also taken root within the minds & workflows of journalists themselves,
or whether they're interested in exploring alternatives to their publishing
process.
Why i ask is that CMS systems like these just *scream* tight coupling to me.
They're designed with only one set of inputs and outputs in mind, and those
inputs and outputs have to be custom tailored to the process for which they
were designed. And presumably if the news room becomes beholden to their
publishing process there's no chance for any innovation to take root,
because experimentation is effectively DOA.
Do you feel that to be the case?
-Ted
P.S. i don't see legacy CMSes as *necessarily* a blocker to innovation,
because tools can be built to wrap an existing CMS, or tools can be built to
help journalists in other ways outside, but in concert w/ a CMS, but all of
these sorts of projects are ugly, time consuming and challenging. And they
all start with having good ideas and alternatives to help journalists, in
short, the CMS is an impediment to be planned around.
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
>
> --
> -------------------------------------
> Bill Densmore, Consulting Fellow
> Reynolds Journalism Institute
> University of Missouri
> Columbia MO 65211
> mobile: 617-448-6600
> dens...@rjionline.org<mailto:dens...@rjionline.org>
> @infovalet
> DISCLOSURE: http://newshare.com/wiki/index.php/Disclosure
>
> "BEYOND BOOKS: News, literacy, democracy and America's Libraries"
> Advancing a common mission for journalists and librarians
> WRAUP REPORT: http://www.biblionews.org
>
> "From Paper to Persona: Managing Privacy & Information Overload;
> Sustaining Journalism in an Attention Age"
> http://www.papertopersona.org
>
>
>
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/community-mojo
>
>
>
>
> --
> Wray Cummings
> 402.419.3889
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org<mailto:communi...@lists.mozilla.org>
David Cohn
Ian Hill
NP. I think it's less that workflow is a rigid system from which deviation is impossible, and more that journalists aren't given the option to explore alternatives to the publishing process. The publisher, in conjunction with newsroom management, typically determines what's used in the publishing process. They tell the journalists what's being used. Usually, you'll get an email that says something like "The newsroom will be using Saxotech. We have determined that is the best option for everyone. IT will be training you on it in a month." An individual journalist doesn't have the freedom to try WordPress or Joomla in a professional capacity, if they're so inclined.
That's something everyone on this thread needs to understand. If you're going to be building a CMS, journalists won't be your target market for adoption. It will be publishers and managers.
I think that also reflects a big difference worth noting when it comes to newsroom culture vs. tech culture. In tech, I think you're more likely to be encouraged to experiment and try new things. That type of encouragement typically doesn't happen in newsrooms. If you're lucky, you'll be told you can pursue innovation on your own time, and maybe the organization will adopt it in the future.
It's a pretty significant issue and one that's a popular topic of discussion among those of us that observe the journalism industry.
Thanks,
Ian
Hey Ian,
-Ted
SueSalinger
Hi Ian,
While I agree with you completely that the initial sales for adoption of a publishing/curation/creation data/news management system likes with the suits, historically newsrooms are competitive, and as soon as a successful new tech whatever (think, chopper, for example), is modeled in any given market with some success, the other stations come on board pretty quick. Because they can't stand having the other guy make the promo about the new tech.....messes up the ratings).
It might be interesting to partner with the existing news management systems people, as well as news organizations, to develop
a functionality that could then be offered to existing newsroom management 'customers'.
Like these guys with Avid Newscutter: http://www.wecom-me.com/newsroom.html
best,
sue salinger
-----Original Message-----
From: Ian Hill <ih...@KQED.org>
To: Discuss the Knight-Mozilla News Technology Partnership <communi...@lists.mozilla.org>
Hey Ian,
-Ted
Kunal
https://www.drumbeat.org/en-US/challenges/beyond-comment-threads/submission/179/
).
Rhiannon
@rhiannoncoppin
https://lists.mozilla.org/listinfo/community-mojo
Ian Hill
True, some adoption can be driven by what the other guy is doing. That's how I probably first started using Storify. At the same time I think there's a big difference between hyping a new chopper - something big and shiny that the consumer can understand - and a new CMS. There's a big difference between a chopper and Storify, even. The suits look at a new CMS like they look at buying a new press. It's first and foremost about money (particularly today), then reliability, then some mix of the perceived needs to the readers, tradition what the competition is doing. It might be one factor, but it's far from the only factor nor is it a major factor in what's considered.
This brings me to a weird Catch 22 of the for-profit news business today. In general, news companies are losing readers and revenue and could use some free help. But the suits tend to be skeptical of free. It might be that old attitude of, you can't get something for nothing. Getting around that might be tougher than you think.
Ian
Ted Han
the question of how much discretion journalists have within their respective
organizations. I guess it'd also be interesting to find out more about how
bloggers that have moved into news orgs like WaPo and NYT (or elsewhere!)
have had to adjust to their new surroundings. I'd also be interested to
know how non-profits like NPR & PBS stations compare with for-profit
organizations, since i presume that the news gathering mechanism must be
similar, if properly insulated from revenue generation.
Stijn Debrouwere
Truly an interesting back-and-forth. I thought I'd chime in with some
very practical considerations, with regards to the wording of
Challenge #3 as it exists at https://drumbeat.org/en-US/challenges/open-webs-killer-app/full
and in the Etherpad doc.
In a nutshell: it confuses the hell out of me.
The Challenge asks for new interfaces and cross-platform experiences,
but because every newsroom works with a different CMS and has
different needs, that would seem to point to interface mockups,
because an actual news app wouldn't work in that environment. Unless
that app would exist as a layer on top of existing software... but
another requirement is that we should be "hacking at the core". Whoah,
very Ibn Rushd.
Hacking at the core, indeed, but at the same time we're not supposed
to create back-end tools, and need to focus on involving audiences. We
should create a unique cross-platform user-experience without touching
the machinery, the CMS that's supposed to power those experiences,
instead making software that is widely adoptable with minimal effort.
How? Somehow.
We're not supposed to suggest interface tweaks, but we are supposed to
be building new kinds of interfaces.
A lot of the examples within the brief are created using Django or
Ruby on Rails, yet the challenge asks for web-native technologies.
Those two frameworks are open, but they require a server to run and
they're not web-native at all.
I'm getting a wee bit dizzy.
After reading this thread, and going through the Challenge brief
another couple of times, I think I finally have some grasp on what
kind of projects would suit the Challenge and which proposals would be
off-base. I also agree wholeheartedly (though with some sadness) that
we can't let the Challenge get out of hand by encouraging proposals
that call for the creation of an entirely new software stack, even if
bad CMSes *are* keeping us hostage. But maybe it'd be best if
understanding the challenge didn't require an advanced degree in
hermeneutics? :-)
Best,
Stijn
On May 18, 11:21 pm, Mark Surman <m...@mozillafoundation.org> wrote:
> Hey all
>
> Awesome discussion.
>
> As Phillip noted when he originally posted, we knew challenge #3 was off
> base -- that's why we wanted input on how to reboot.
>
> I know Phillip is close to a new challenge statement that includes much
> (but definitely not all) of the feedback here.
>
> A couple of personal opinions from my side:
>
> - +1 on bottom up software design. We need to bend the challenge more
> that way, so constructive ideas on how totally welcome.
>
> -> Right now, the main way we're getting entries is via
> Hacks/Hackers-like events, which are half journos / half devs so far.
> We're seeing real collaborating and brainstorming at these events.
>
> -> Also, the whole idea of the fellowships is to embed talented devs and
> designers *with journalists* in places like Al Jazeera, etc. We've
> picked the initial partners we have because they have good track records
> doing dev + journalist collaboration. We'll also pick fellows based on
> their ability to play well w/ journalists.
>
> - Also +1 on not expecting journalists to be designers or techies.
>
> -> Kind of ideas I am hoping to see personally are things that make hard
> to do things like data viz and semantic video easy for journalists and
> end users to work with.
>
> -> This builds on Mozilla's history and strength: making hard to use
> software simpler. That is the Firefox tradition and core to what we believe.
>
> - Focus-wise, we're pretty consciously focused on software that is
> public facing in some way, even if it's to help journalists.
>
> -> e.g. we might get excited about fact checking and data mind workflow,
> but in a way that involves readers.
>
> -> This is again about building on the Mozilla community's strengths:
> creating consumer facing software. Purely journalist focused software
> starts to get into the enterprise realm, something that our community
> has no real experience or strength with.
>
> Again, these are only my opinions. We've got a whole group of people
> reviewing and pitching in on the program. But figured some of these
> thoughts might be useful in the mix.
>
> ms
>
> On 11-05-18 5:01 PM, Ian Hill wrote:
>
>
>
>
>
> > +1 Jonathan. For further clarification, journalists don't create pages with inDesign. Journalists write / record / shoot. Page designers use inDesign. Multimedia producers create web content and manage websites. True, those three groups are merging at a rapid rate. But they're not merged yet, and they're not going to be merged before any product is created as a result of this thread.
> > Appreciate for a moment that there are many journalists out there who don't understand how to use Facebook, much less HTML/CSS. If you're going to create a tool for journalists, that's your target. I don't know if you could create anything more complex than Soundslides<http://www.soundslides.com/>. One of the reasons Storify<http://storify.com/> has taken off, besides the fact that it involves social media, is that it's so easy to use.
>
> > On May 18, 2011, at 12:54 PM, Matthew Terenzio wrote:
>
> > I agree with the part about bottom up software development, but aren't some
> > of these ideas about creating tools for news creators, not site end-users.
> > Journalists will need to be very technical for some time to come, or at
> > least have someone on their team that is. At least it seems to me that it
> > will be some time before a Journalist can create some of these end-products
> > in the way that they create a page with InDesign. I could be wrong, or
> > misunderstanding.
>
> > On Wed, May 18, 2011 at 3:34 PM, Jonathan Eyler-Werve<
> > jonathan.eyler-we...@globalintegrity.org<mailto:jonathan.eyler-we...@globalintegrity.org>> wrote:
>
> > I don't know what to say. Github is not where the journalists are. Github
> > is
> > not enough.
>
> > For the purposes of this contest, I think many of these issues can be
> > addressed by* requiring developers to talk to the end users *before they
> > start writing code. Ask the applicants these questions:
> > *
> > What problem are you solving?
> > Who has this problem?
> > What kind of research have you done to understand this problem**? (ie, who
> > have you talked to; did you visit them on site?; have you recruited
> > potential users into your team?)*
>
> > I think that will create better software, and perhaps even build community
> > in the process.
>
> > This idea is as old as the Cluetrain Manifesto, but I don't see a lot of
> > attention to users in these contests. It's so top-down. It's all about the
> > data and the tech stack. I think talking to people will lead to adoptable
> > solutions. Ignoring them will lead to kickass demos being posted to Github,
> > and then not being adopted. We can do better.
>
> > Cheers,
> > Jonathan
>
> > **
> > Jonathan Eyler-Werve // Director of Technology and Innovation //
> >www.globalintegrity.org<http://www.globalintegrity.org>
> > *
> > GLOBAL INTEGRITY*: Independent Information on Governance and Corruption
> > Direct: +1-202-449-8123 // Office: +1-202-449-4100 // Fax: +1-866-681-8047
>
> > Follow us on Twitter:http://twitter.com/globalintegrity
>
> > On Wed, May 18, 2011 at 1:40 PM, Phillip Smith<p...@phillipadsmith.com<mailto:p...@phillipadsmith.com>
> > wrote:
>
> > On 2011-05-17, at 3:03 PM, Daniel Bachhuber wrote:
>
> > Following up on Scott's points, I've always thought Stijn's piece
> > accurately summarizes the billion dollar opportunity:
>
> >http://stdout.be/2010/04/22/we-are-in-the-information-business/
>
> > When I first heard about the challenge from Phillip, this is what
> > immediately came to mind. It's 10% actual technology though, and 90%
> > getting
> > the workflow/organization/culture to adopt it.
>
> > That's a curious take on Stijn's piece, IMHO.
>
> > Stijn says: "But we’re forgetting the most important point at issue: what
> > should a news website look like in 2010 and beyond? The fundamentals of
> > website design and information architecture somehow lack appeal as a
> > topic
> > for debate among journos."
>
> > When I read that piece in the context of this thread, I thought it drove
> > to
> > the core of what this third challenge is all about: How would you use the
> > web to dramatically improve how we make& share news.
>
> > Stijn's piece goes on to say "That technology should reach right into the
> > core of our journalistic endeavors, not just touch the periphery like yet
> > another infographic or mashup" and "The news industry needs to start
> > thinking about journalism in terms of information and the myriad ways in
> > which we can present that information to our readers."
>
> > Yet, I hear a persistent hum from those working in newsrooms and those on
> > this list of of "workflow, CMS, workflow, CMS!"
>
> > **Is that not thinking about re-tooling the printing press vs. re-tooling
> > the system of news itself?**
>
> > What Mozilla brings to the table here is expertise in open culture,
> > peer-based co-production, and -- most importantly -- *consumer* Internet
> > experiences. Mozilla doesn't build corporate content-management systems,
> > or
> > corporate IT solutions -- they have little expertise to offer there.
> > Mozilla
> > focuses on those point where the Internet and people come together.
> > That's
> > where these news innovation challenges aim to land as well: the place
> > where
> > news& people come together on the Internet.
>
> > And herein lies one of the big tensions: Many news organizations are
> > _still_ thinking about innovation (as pointed out frequently on this
> > list)
> > through the lens of corporate IT.
>
> > There needs to be a radical shift toward thinking about news as a problem
> > of creating successful consumer Internet experience vs. filling column
> > inches or news holes, press deadlines, and delivery trucks. That is where
> > the innovation and potential lies, I would propose, not in a
> > re-arrangement
> > of the chairs on the deck of the corporate IT Titanic inside of news
> > organizations.
>
> > "Innovation should be aimed at the heart of what we do. Innovation should
> > allow us to do exciting things with everyday news. Innovation should be
> > all-encompassing. "
> >http://stdout.be/2010/04/22/we-are-in-the-information-business/
>
> > Two cents,
>
> > Phillip.
>
> > --
> > Phillip Smith
> >http://phillipadsmith.com
> >http://twitter.com/phillipadsmith
> >http://linkedin.com/in/phillipadsmith
>
> > _______________________________________________
> > community-mojo mailing list
> > community-m...@lists.mozilla.org<mailto:community-m...@lists.mozilla.org>
> >https://lists.mozilla.org/listinfo/community-mojo
>
> > _______________________________________________
> > community-mojo mailing list
> > community-m...@lists.mozilla.org<mailto:community-m...@lists.mozilla.org>
> >https://lists.mozilla.org/listinfo/community-mojo
>
> > _______________________________________________
> > community-mojo mailing list
> > community-m...@lists.mozilla.org<mailto:community-m...@lists.mozilla.org>
> >https://lists.mozilla.org/listinfo/community-mojo
>
> > __________________________________
> > Ian Hill
> > Community engagement specialist
> > KQEDnews.org<http://www.kqednews.org/>
> > Phone: (415) 553-2216
> > Follow KQED News on Facebook<http://Facebook.com/KQEDnews> and Twitter<http://twitter.com/kqednews>
> > Share your knowledge and become a KQED News source by joining the Public Insight Network<http://www.kqed.org/news/publicinsightnetwork/>
>
> > _______________________________________________
> > community-mojo mailing list
> > community-m...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/community-mojo
>
> --
> Mark Surman
> Executive Director
> Mozilla Foundation
> m...@mozillafoundation.org
> commonspace.wordpress.com
Jake Bayless
for newsy-ish information.
The AP took a stab at it in 2009 - it seemed to have high praise from the
suits for focusing on how to monetize information... but it left a huge
culture of news & information subversion nonplussed. It missed the
pre-publication workflow... the things that make community interaction,
community involvement, community engagement & news great... Which is NOT to
say that professional journalism isn't necessary - it's just a wedge of the
information pie - and for most intents, the AP's "Media Standards Trust" has
done a component of the metadata standardization... shoulders to build upon.
More about MST: http://goo.gl/pKroZ
Can you imagine what the Django, Wordpress, Joomla, Plone, Sharepoint,
etcetera communities could make for news sites if built atop a much more
broad "community information standard"?
The missing link, for all of us then, is simply someone or some group to
build a theme or template that leverages the new cradle/grave standards to
free the data. Suddenly CMS's become the dogfood as well as the delivery
mechanism for news orgs. Efficiency at its very best...
My nickel :-)
Cheers,
jake bayless
Ben Moskowitz
Thanks for your very valuable feedback. Two things:
1. This is meant to be the most open-ended challenge. You're right that the language we've chosen does more to constrain. So I've replaced the paragraph you call out with something much less ambiguous:
"We're asking you to forget old conventions like the story form, column inches & deadlines and propose new ways to connect news producers to news readers."
2. Your point about "web-native" technologies is well taken. We should clarify that Django and Rails and the like are OK, as long as the product is user-facing. This rule is here so we stay grounded on the web. Hopefully the more detailed explanation in the footer clarifies:
"Your idea can only use web-native technologies: the HTML5 stack, CSS, Javascript, you name it -- any open standard will do. No Flash, iOS or other proprietary SDK. We want cross-platform experiences for everyone, no matter their device."
Perhaps we should move that above the fold? Thanks again.
Cheers,
Ben
Ben Moskowitz
Thanks for your very valuable feedback. Two things:
1. This is meant to be the most open-ended challenge of the lot. You're right that the language does more to constrain. So I've replaced the paragraph you call out with something much less ambiguous:
"We're asking you to forget old conventions like the story form, column inches & deadlines and propose new ways to connect news producers to news readers."
2. Your point about "web-native" technologies is well taken. We should clarify that Django and Rails and the like are OK. This rule is here so we stay grounded on the web. Hopefully the more detailed explanation in the footer clarifies:
"Your idea can only use web-native technologies: the HTML5 stack, CSS, Javascript, you name it -- any open standard will do. No Flash, iOS or other proprietary SDK. We want cross-platform experiences for everyone, no matter their device."
Perhaps we should move that above the fold?
Thanks again, Stijn, for pointing these out.
Cheers,
Ben
On May 25, 2011, at 8:04 AM, Stijn Debrouwere wrote:
Ben Moskowitz
Thanks for your very valuable feedback. Two things:
1. This is meant to be the most open-ended challenge of the lot. You're right that the language does more to constrain. So I've replaced the paragraph you call out with something much less ambiguous:
"We're asking you to forget old conventions like the story form, column inches & deadlines and propose new ways to connect news producers to news readers."
2. Your point about "web-native" technologies is well taken. We should clarify that Django and Rails and the like are OK. This rule is here so we stay grounded on the web. Hopefully the more detailed explanation in the footer clarifies:
"Your idea can only use web-native technologies: the HTML5 stack, CSS, Javascript, you name it -- any open standard will do. No Flash, iOS or other proprietary SDK. We want cross-platform experiences for everyone, no matter their device."
Perhaps we should move that above the fold?
Thanks again, Stijn, for pointing these out.
Cheers,
Ben
On May 25, 2011, at 8:04 AM, Stijn Debrouwere wrote:
Ben Moskowitz
On May 25, 2011, at 12:44 PM, Ben Moskowitz wrote:
> Hey Stijn,
>
> Thanks for your very valuable feedback. Two things:
>
> 1. This is meant to be the most open-ended challenge of the lot. You're right that the language does more to constrain. So I've replaced the paragraph you call out with something much less ambiguous:
>
> "We're asking you to forget old conventions like the story form, column inches & deadlines and propose new ways to connect news producers to news readers."
>
> 2. Your point about "web-native" technologies is well taken. We should clarify that Django and Rails and the like are OK. This rule is here so we stay grounded on the web. Hopefully the more detailed explanation in the footer clarifies:
>
> "Your idea can only use web-native technologies: the HTML5 stack, CSS, Javascript, you name it -- any open standard will do. No Flash, iOS or other proprietary SDK. We want cross-platform experiences for everyone, no matter their device."
>
> Perhaps we should move that above the fold?
>
> Thanks again, Stijn, for pointing these out.
>
> Cheers,
> Ben
>
>
> On May 25, 2011, at 8:04 AM, Stijn Debrouwere wrote:
>
>> _______________________________________________
>> community-mojo mailing list
>> communi...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/community-mojo
>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/community-mojo
Stijn Debrouwere
That's helpful, thanks!
With regards to "Your idea can only use web-native technologies..." --
isn't what you really mean, "Your idea should be built using open
technologies and languages, though whether that's PHP, node.js, Django
or something else is up to you. No Flash, iOS or other proprietary
SDK. Additionally, there are brownie points to be had for those who
leverage web-native technologies like HTML5, CSS and Javascript to
create true cross-platform experiences."
Maybe I'm just interpreting "web-native" too strictly, though, I don't
know how others use the term.
Cheers,
Stijn
On May 25, 6:46 pm, Ben Moskowitz <b...@mozillafoundation.org> wrote:
> Hey Stijn,
>
> Thanks for your very valuable feedback. Two things:
>
> 1. This is meant to be the most open-ended challenge of the lot. You're right that the language does more to constrain. So I've replaced the paragraph you call out with something much less ambiguous:
>
> "We're asking you to forget old conventions like the story form, column inches & deadlines and propose new ways to connect news producers to news readers."
>
> 2. Your point about "web-native" technologies is well taken. We should clarify that Django and Rails and the like are OK. This rule is here so we stay grounded on the web. Hopefully the more detailed explanation in the footer clarifies:
>
> "Your idea can only use web-native technologies: the HTML5 stack, CSS, Javascript, you name it -- any open standard will do. No Flash, iOS or other proprietary SDK. We want cross-platform experiences for everyone, no matter their device."
>
> Perhaps we should move that above the fold?
>
> Thanks again, Stijn, for pointing these out.
>
> Cheers,
> Ben
>
> On May 25, 2011, at 8:04 AM, Stijn Debrouwere wrote:
>
>
>
> > Hi chaps,
>
> > Truly an interesting back-and-forth. I thought I'd chime in with some
> > very practical considerations, with regards to the wording of
> > Challenge #3 as it exists athttps://drumbeat.org/en-US/challenges/open-webs-killer-app/full
> >>> which we can present that information to...
>
> read more »
Carrie Oviatt
Carrie
Kunal Bhalla
detailed entry over the weekend for my submission, my initial thoughts on
hacking all the workflows I've seen on this list, with reference to
transparency, etc.
First of all, Ian's daily(!) workflow (valid for any big newspaper) can be
broken down as: (I hope the following ASCII diagram survives email clients)
(Note: I've uploaded a text version of this at
https://github.com/kunalb/MoJo/blob/gh-pages/people-powered-news/mojo-notes.md
incase the formatting gets too messed up.)
Note: The numbers indicated are for labelling the stages, and are not really
indicative of any ordering.
------------------------------------------------------------------------------
|
1) |
Inception of an idea with a lot of back |
and forth between the editors and | 2)
journalists. | Start obtaining photos
|
3) | 4)
The journalist starts working on his | Contact media department/devs
report, contacting resources, etc. | for visualizations, media.
|
5) | 7) Visualizations, media prepared
The reporter remains in contact with | according to data provided by
the editor about changes made to the | the reporter.
story and discuss it. |
|
6) |
The story might be discussed once again |
a few hours before the finishing time. |
| 9)
8) | Somewhere around this point the
The reporter files the story and | designers/devs submit requested
informs the editor, who reviews and | media.
forwards it to the copy editor. Back |
and forth between the editors and | (Not necessarily
approved/reviewed
journalist. | by the editor or the journalist)
|
------------------------------------------------------------------------------
10)
Paginator 'fits' the story into available space using available
infographics,
photographs with back and forth with the journalist to strech or crop the
article.
11)
The story finally goes for printing and is exported (somehow) to the website
(either by hand or by using a software, etc.)
12)
**REPEAT FROM 1**
------------------------------------------------------------------------------
I hope I've understood the workflow more or less correctly. Issues raised
about
really being able to hack on this workflow involve getting this tech
adopted,
cost and working with the existing legacy CMSs; apart from attempting
together
improve transparency, crowdsourcing, etc.
Considering the vast amount of possible use cases, I'd say the requirements
can be broken down into, and solved by using a variation of tech.:
1. Managing and merging various discrete units of data while keeping a store
of everything that has happened: a DVCS seems to be perfectly suited to
this. Customized applications built on top of (Git)[http://git-scm.com
][]
as the core would be able to manage the history of the creation and
merging
of any article.
2. Because of the existing CMSs and workflows at organizations, any solution
we make must be completely atomic by stage of solution--it must be able
to read in data from any source, and output data that can be consumed by
any
software with minimum work in conversion. This would ideally require a
standard format along the lines of what Jake mentioned (Metadata for
news [
http://www.buzzmachine.com/2009/07/11/metadata-for-news/][])--though
the link to the actual specification seems to be broken.
Something worked around JSON would be a rather elegant solution here,
considering its readability and the availability of parsers. Having fixed
formats also makes the process tool independent--every journalist can
work using his own favourite open source (perhaps) tool for each stage
of work, a sort of mix-and-match which ensures consistency.
3. Essentially I'd propose a series of tools built around a central format
for
news data with all required metadata, fine grained control of access to
users (j,e) and subscribers, with options to suggest changes to the
document
with comments (like a bug issue tracker, for example).
The tools -- with functionality -- I can imagine based on the workflows
is:
1. Wave-like tool that allows the journalists and the editors to
collaborate; something that records the complete history of the
document as it is being edited (allowing a replay for interested
people).
The document will be configurable to allow for various sections a
journalist can use: the initial idea and surrounding discussion,
data the journalist collects from various sources, inputs FROM
news subscribers, automated sources of data (like picking up a hashtag
from twitter; or following a user, etc. -- automatically aggregating
data from different sources -- so that 9 separate teams aren't
required
for aggregating information from a 5 day walk-about, as in Bill's case),
photographs, finished/in progress visualizations, etc.
Adding information will have to be platform agnostic--phone based
native applications to HTML5 based webapps to a headless browser
running on journalist's computers. The views will based on the role of
the person--copy editor/editor/journalist/paginator/photographer
--based on their particular work requirements.
2. Simplified creation of visualizations and videos--again, using
platform agnostic webapps that are configured to consume most APIs
and built around the article metadata standard. Something that could
be used as a base for designers/developers at news agencies for rapid
prototyping and then building upon; and relatively standard
infographics that can be directly created by journalists without
having to touch a line of code.
With fine grained permissions, large parts of the history of an article
can be made public for comments, further discussion and possibly newspaper
articles--essentially allowing anyone to contribute to a paper and perhaps
change the way news is published: crowd sourced information edited,
verified
and published.
3. Content Exporter/Importer: A way to move the standard format to any
of the CMS's; say, for example a WordPress importer. The same
article
can be published to a wiki, to wordpress, drupal or anywhere you care
to name as required.
This is just an initial draft written by me while almost falling asleep, so
please forgive typos, etc. I need to go into a bit more detail about how
anyone apart from those directly involved in the workflow can contribute.
What do you think--suggestions, technical and otherwise?
Kunal
http://kunal-b.in
Bill Densmore
Jake:
I hope folks will take a serious look at our proposal to create an
Information Trust Association which could foster standards, protocols and
voluntary business rules for a shared-user network handing trust, identity
and information commerce.
http://www.journalismtrust.org
http://www.papertopersona.org
On Wed, 25 May 2011, Jake Bayless wrote:
> In just a few words, I think the goal is to create cradle to grave standards
> for newsy-ish information.
>
> The AP took a stab at it in 2009 - it seemed to have high praise from the
> suits for focusing on how to monetize information... but it left a huge
> culture of news & information subversion nonplussed. It missed the
> pre-publication workflow... the things that make community interaction,
> community involvement, community engagement & news great... Which is NOT to
> say that professional journalism isn't necessary - it's just a wedge of the
> information pie - and for most intents, the AP's "Media Standards Trust" has
> done a component of the metadata standardization... shoulders to build upon.
> More about MST: http://goo.gl/pKroZ
>
> Can you imagine what the Django, Wordpress, Joomla, Plone, Sharepoint,
> etcetera communities could make for news sites if built atop a much more
> broad "community information standard"?
>
> The missing link, for all of us then, is simply someone or some group to
> build a theme or template that leverages the new cradle/grave standards to
> free the data. Suddenly CMS's become the dogfood as well as the delivery
> mechanism for news orgs. Efficiency at its very best...
>
> My nickel :-)
>
> Cheers,
> jake bayless
>
> On Wed, May 25, 2011 at 5:04 AM, Stijn Debrouwere <st...@stdout.be> wrote:
>
>>>> Stijn says: "But weяяre forgetting the most important point at issue:
>> _______________________________________________
>> community-mojo mailing list
>> communi...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/community-mojo
>>
> _______________________________________________
> community-mojo mailing list
> communi...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/community-mojo
>
--
-------------------------------------
Bill Densmore, Consulting Fellow
Reynolds Journalism Institute
University of Missouri
Columbia MO 65211
mobile: 617-448-6600
dens...@rjionline.org
@infovalet
DISCLOSURE: http://newshare.com/wiki/index.php/Disclosure
"BEYOND BOOKS: News, literacy, democracy and America's Libraries"
Advancing a common mission for journalists and librarians
WRAUP REPORT: http://www.biblionews.org
"From Paper to Persona:
Managing Privacy & Information Overload;
Sustaining Journalism in an Attention Age"
WHITE PAPER AND COMMENTS:
http://www.papertopersona.org
http://socialmediatoday.com/paulgillin/297526/paid-content-model-makes-sense