Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

September 05 2012

15:39

Miranda Mulligan: Want to produce hirable grads, journalism schools? Teach them to code

Editor’s Note: It’s the start of the school year, which means students are returning to journalism programs around the country. As the media industry continues to evolve, how well is new talent being trained, and how well are schools preparing them for the real world?

We asked an array of people — hiring editors, recent graduates, professors, technologists, deans — to evaluate the job j-schools are doing and to offer ideas for how they might improve. Over the coming days, we’ll be sharing their thoughts with you. Here’s Miranda Mulligan — new executive director of the Knight News Innovation Lab at Northwestern, formerly digital design director for The Boston Globe — arguing that journalists need to learn how to code if they want to become better (and employable) storytellers.

Learning how to make software for storytelling and how to realize news presentations into code are currently the hottest, most pressing skillsets journalists can study. There has never before been more urgency for our industry to understand enough code to have meaningful conversations with technologists.

And yet if you attend any event with a collection of jouro-nerd types, inevitably the same question will come up. Someone will ask — philosophically, of course — “How can we tell better stories on the web?” and proceed to bemoan the tedium of reading a daily newspaper and a newspaper website, likening it to Groundhog Day, the same stories presented the same way, day after day. Sooner or later others add their frustrations that “we” — in 2012 — are still writing for the front page instead of the homepage.

It is our job as educators to remove fear of learning, a fear notoriously prevalent in journalists.

We’ve all had this discussion a thousand times. But now, it’s not just the visual journalists complaining about the stagnation of online storytelling and presentation.

For me, there’s only one response to this: Journalists should learn more about code. Understanding our medium makes us better storytellers. For an industry that prides itself on being smart, tolerating ignorance of the Internet is just stupid.

The time is now for our future journalists to learn about code. We need to innovate our curricula, really looking at what we are teaching our students. Learning, or mastering, specific software is not properly preparing our future journalists for successful, life-long careers. No one can learn digital storytelling in a semester. Mastering Dreamweaver and Flash isn’t very future-friendly, and having a single mid-level “Online Journalism” course offered as an elective does more harm than good. We should be teaching code in all of our journalism courses — each semester, each year, until graduation.

The list of jobs for designers and journalists who can write code is growing — seemingly exponentially. So, let’s all grab our copies of The Art of War and attack this problem from every angle: We need to teach our students to be more technologically literate. We need to teach them how to learn and how to fail. That, my friends, is making the Internet.

I am not arguing that every single writer/editor/publisher who learns some programming should end up becoming a software engineer or a refined web designer. The end goal here is not programming fluency. However, there’s a lot of value in understanding how browsers read and render our stories. Reporting and writing a story, writing some code (HTML, CSS, Javascript), and programming complex applications and services are all collections of skills. A fundamental knowledge of code allows for:

  • More significant conversations about digital presentation, ultimately leading to better, more meaningful, online storytelling. Understanding your medium makes you better at your craft.
  • Deeper thought and understanding of data. Learning more about what goes into writing and programming software teaches you to think in terms of abstractions, functions, parameters, components, frameworks, object classes, templates, and more.

Journalism needs hirable graduates that can create sophisticated visual presentations and can realize them in code. But many students are intimidated, not excited, by the tools now fundamental to visual storytelling. In fact, the prevailing sentiment throughout journalism and communications specialties is that “we” are still intimidated. Maybe this attitude is trickling down to the universities — or maybe up from them. But “we” have all got to get over our fear of the Internet.

Last September, I participated in a half-day student seminar at the Society of News Design’s annual workshop in St. Louis. To be brazen and speak for my panel-mates, we were all shocked by how apprehensive the students were toward HTML, CSS, and Javascript. In fact, after three hours of nudging them to make the time to learn some code, a female student boldly asserted that she really didn’t care about digital design and wanted advice for students hoping to break into print design.

It’s our job as educators to remove fear of learning, a fear notoriously prevalent in journalists. HTML is not magic. Writing code is not wizardry; it’s just hard work. Learning to program will not save journalism and probably won’t change the way we write our stories. It is, however, a heck of a lot more fun being a journalist on the web once “how computers read and understand our content” is understood.

Learning to program not only provides a practical skill — it also teaches problem solving. Students are learning more precise and nuanced thought processes, and the depth of their understanding of information and data will only grow. Also, for visual journalists, teaching code is teaching information design. Both news designers and web designers are burdened with the same responsibilities: organizing and rationally arranging content, illustrating ideas to deepen the understanding of a story, and working within the constraints of the medium.

I believe the most important thing an instructor can ever do is inspire students to be open-minded about their skills. No one knows what the storytelling landscape will look like in two years, let alone a decade from now. As educators, we can make becoming a digital journalist feel accessible and attainable. Graduates should leave armed with a skillset that includes the ability to learn quickly and adapt, to be open to new ideas and solutions, and to take initiative like the self-starters they were born to become. They will never get bored, and they will always be employable.

Our journalism pedagogy should inspire future digital journalists to be Internauts, to continually grow, constantly teaching themselves the newest storytelling tools and techniques, instilling processes for life-long learning.

Image by Steve Rhode used under a Creative Commons license.

August 29 2012

08:38

How to teach a journalist programming

Cross-posted from Data Driven Journalism.

Earlier this year I set out to tackle a problem that was bothering me: journalists who had started to learn programming were giving up.

They were hitting a wall. In trying to learn the more advanced programming techniques – particularly those involved in scraping – they seemed to fall into one of two camps:

  • People who learned programming, but were taking far too long to apply it, and so losing momentum – the generalists
  • People who learned how to write one scraper, but could not extend it to others, and so becoming frustrated – the specialists

In setting out to figure out what was going wrong, I set myself a task which I have found helpful in taking a fresh perspective on an issue: I started writing a book chapter.

The nice thing about writing books is that they force you to put together a coherent and complete narrative about an entire process. You identify gaps that you weren’t otherwise aware of, and you have to put yourself in the place of someone with no knowledge at all. You take nothing for granted.

So my starting point was this: what is a good way to learn how to write scrapers?

That’s a different question to ‘How do I write a scraper?’ and also to ‘How do I learn programming?’ And that’s important. Because most of the resources available fell into one of those two camps.

The people trying to learn programming were hitting a common problem in learning: lack of feedback. They might be able to change a variable in Ruby, but how would that help in journalism? It was like learning the structure of the entire French language just so they could go to the corner shop and ask for a loaf of bread.

The people learning how to write one scraper were hitting another common problem: learning how to do one task well, rather than the underlying principles. This was like someone learning how to ask for a loaf of bread in French, but not being able to extend that knowledge into asking for directions home.

I tackled both by beginning the chapter with probably the simplest scraper you can write: a spreadsheet formula in Google Docs. This provided the instant feedback that the generalists lacked, but the formula was also used to introduce some key concepts in programming: functions, strings, indexes, and parameters. These would provide key principles that the specialists lacked, and which future chapters could build on.

Learning differently

I also looked at how journalists tried to learn programming, and how programmers developed, and realised something else: journalists and programmers learned differently.

I’m generalising wildly, of course, but journalists – particularly student journalists – often try to learn programming from books. That may sound like common sense, but it’s not in an art or a science – and programming is both.

Programmers – if I’m to generalise wildly again – typically combine books (which they don’t read cover to cover) with documentation, adapting other code, trial and error, and each other. When they teach journalists, they often don’t realise that journalists don’t always share that culture.

And journalists – coming traditionally from a background in the humanities – are used to learning from books: static knowledge. Teaching programming to journalists then, I realised, would also mean teaching how programmers learn.

So my chapter introducing that first scraper introduced some other key concepts as well. It would direct readers to the documentation on the function being used, and invite them to engage in some trial and error to work out a solution to a problem. As more scraper tutorials were added, they introduced more key concepts in programming – importantly, without having to learn an entirely new language, and with documentation and trial and error running throughout, along with the principle of adapting other code.

I tested the approach at the News:Rewired conference. Can you teach scraping in 20 minutes? At a basic level, yes: it seemed you could.

Agile publishing

After 20,000 words I realised that my book chapter was turning into a book. Meanwhile, a colleague had told me about Leanpub: a website that allowed people to publish books as they were being written, with readers able to download new updates as they came.

The platform suited the book perfectly: it meant I could stagger the publication of the book, Codecademy-style, with readers trying at least one scraper per week, but also having the time to experiment with trial and error before the next chapter was published. It meant that I could respond to feedback on the earlier chapters and adapt the rest of the book before it was published (in one case a Brazilian reader pointed out after the first chapter was published that the Portuguese-language Google Docs uses semi colons instead of commas). If examples used in the book changed then I could replace them. And it meant that if new tools or techniques emerged, I could incorporate them.

It is a programming-style approach to publishing – trial and error – which very much suits the spirit of the book. It’s extra work, but it makes for a much better writing experience. I hope the readers think so too.

Scraping for Journalists is available at Leanpub.com/ScrapingForJournalists

08:38

How to teach a journalist programming

Cross-posted from Data Driven Journalism.

Earlier this year I set out to tackle a problem that was bothering me: journalists who had started to learn programming were giving up.

They were hitting a wall. In trying to learn the more advanced programming techniques – particularly those involved in scraping – they seemed to fall into one of two camps:

  • People who learned programming, but were taking far too long to apply it, and so losing momentum – the generalists
  • People who learned how to write one scraper, but could not extend it to others, and so becoming frustrated – the specialists

In setting out to figure out what was going wrong, I set myself a task which I have found helpful in taking a fresh perspective on an issue: I started writing a book chapter.

The nice thing about writing books is that they force you to put together a coherent and complete narrative about an entire process. You identify gaps that you weren’t otherwise aware of, and you have to put yourself in the place of someone with no knowledge at all. You take nothing for granted.

So my starting point was this: what is a good way to learn how to write scrapers?

That’s a different question to ‘How do I write a scraper?’ and also to ‘How do I learn programming?’ And that’s important. Because most of the resources available fell into one of those two camps.

The people trying to learn programming were hitting a common problem in learning: lack of feedback. They might be able to change a variable in Ruby, but how would that help in journalism? It was like learning the structure of the entire French language just so they could go to the corner shop and ask for a loaf of bread.

The people learning how to write one scraper were hitting another common problem: learning how to do one task well, rather than the underlying principles. This was like someone learning how to ask for a loaf of bread in French, but not being able to extend that knowledge into asking for directions home.

I tackled both by beginning the chapter with probably the simplest scraper you can write: a spreadsheet formula in Google Docs. This provided the instant feedback that the generalists lacked, but the formula was also used to introduce some key concepts in programming: functions, strings, indexes, and parameters. These would provide key principles that the specialists lacked, and which future chapters could build on.

Learning differently

I also looked at how journalists tried to learn programming, and how programmers developed, and realised something else: journalists and programmers learned differently.

I’m generalising wildly, of course, but journalists – particularly student journalists – often try to learn programming from books. That may sound like common sense, but it’s not in an art or a science – and programming is both.

Programmers – if I’m to generalise wildly again – typically combine books (which they don’t read cover to cover) with documentation, adapting other code, trial and error, and each other. When they teach journalists, they often don’t realise that journalists don’t always share that culture.

And journalists – coming traditionally from a background in the humanities – are used to learning from books: static knowledge. Teaching programming to journalists then, I realised, would also mean teaching how programmers learn.

So my chapter introducing that first scraper introduced some other key concepts as well. It would direct readers to the documentation on the function being used, and invite them to engage in some trial and error to work out a solution to a problem. As more scraper tutorials were added, they introduced more key concepts in programming – importantly, without having to learn an entirely new language, and with documentation and trial and error running throughout, along with the principle of adapting other code.

I tested the approach at the News:Rewired conference. Can you teach scraping in 20 minutes? At a basic level, yes: it seemed you could.

Agile publishing

After 20,000 words I realised that my book chapter was turning into a book. Meanwhile, a colleague had told me about Leanpub: a website that allowed people to publish books as they were being written, with readers able to download new updates as they came.

The platform suited the book perfectly: it meant I could stagger the publication of the book, Codecademy-style, with readers trying at least one scraper per week, but also having the time to experiment with trial and error before the next chapter was published. It meant that I could respond to feedback on the earlier chapters and adapt the rest of the book before it was published (in one case a Brazilian reader pointed out after the first chapter was published that the Portuguese-language Google Docs uses semi colons instead of commas). If examples used in the book changed then I could replace them. And it meant that if new tools or techniques emerged, I could incorporate them.

It is a programming-style approach to publishing – trial and error – which very much suits the spirit of the book. It’s extra work, but it makes for a much better writing experience. I hope the readers think so too.

Scraping for Journalists is available at Leanpub.com/ScrapingForJournalists

April 20 2012

06:26

Programming and journalism students: A conversation

I think it’s pretty cool to use Storify to sort out the threads of a bunch of simultaneous conversations on Twitter:

[View the story "Programming and journalism students: A conversation" on Storify]

Please join in — on Twitter, on Facebook, or here.

06:26

Programming and journalism students: A conversation

I think it’s pretty cool to use Storify to sort out the threads of a bunch of simultaneous conversations on Twitter:

[View the story "Programming and journalism students: A conversation" on Storify]

Please join in — on Twitter, on Facebook, or here.

February 05 2012

06:04

Python Web Scraping 101 (Hacks/Hackers)

Python Web Scraping 101 resources, links, etc. How to do it.

February 04 2012

13:48

How a Poet Learned to Program | P2PU Blog

"In the fall of 2011, John Britton and I undertook a learning experiment. John would mentor me in webmaking. I would work on an idea for an interactive world history atlas. John would help me as much as I wished, upon the condition that I document each moment of the experience."

December 08 2011

17:27

Daily Must Reads, Dec. 8, 2011

The best stories across the web on media and technology


1. The choice of BBM over Twitter in the recent UK riots illustrates social stratification (Guardian)

2. New businesses pop up to teach web programming (Wall Street Journal)

3. How Twitter's trending algorithm picks its topics (NPR)

4. 70% of Americans have no idea what geolocation apps are (ReadWriteWeb)

5. David Goetzl: Email is the new social (MediaPost)




Subscribe to our daily Must Reads email newsletter and get the links in your in-box every weekday!



Subscribe to Daily Must Reads newsletter

This is a summary. Visit our site for the full post ».

April 13 2011

15:28

What schools offer innovative academic programs that mix journalism and technology?

I'm working to compile a list of academic programs that are experimenting in the news-technology space. The list will be used for outreach around the Knight-Mozilla News Technology Partnership. We'd like to engage as many of the people as possible that have already self-identified as wanting to work at the intersection of journalism, storytelling, and computing -- and academic programs are one of six areas that we want to reach out to, i.e.: undergrads, graduate students, or alums of innovative programs.

Some of the more obvious examples of what I'm looking for are programs like Studio 20 at NYU, Medill's scholarships for programmers, and the new Tow Centre for Digital Journalism at Columbia University. I know there are more -- hopefully many, many more -- institutions doing this kind of experimentation in an academic setting. Can you help me find them (and not just the ones in North America)?

There's a good list of journalism programs over on Wikipedia. Perhaps you know that one of them is doing some really innovative work? If so, please list it below with a one-sentence explanation of what they're doing, and a URL, and I'll move it up into the larger list.

I'm also looking for unusual suspects like the ITP at NYU, or any other programs that are producing potentially journalism-impacting innovations.

Again, suggestions for programs outside of the United States are highly encouraged.

This is a community wiki question.

Here's the current state of the list (with thanks to Justin Arenstein, Brian Loffler, and Ross Settles for non-North American pointers):

Africa

Asian continent/Australasia

Europe

North America (Canada, US, Mexico)

Canada Mexico
  • ???
United States

Latin America

  • ???

March 15 2011

02:14

Circles and Euclidian Rhythms: Off the Grid, a Few Music Makers That Go Round and Round

Loopseque on the iPad. Courtesy the developer.

We continue our 3.14 celebration with a round-up of circular logic.

There’s no reason apart from the printed score to assume music has to be divided into grids laid on rectangles. Even the “piano roll” as a concept began as just that – a roll. Cycles the world around, from a mechanical clock to Indonesian gamelan, can be thought of in circles.

Imagine an alternate universe in which Raymond Scott’s circle machine – a great, mechanical disc capable of sequencing sounds – became the dominant paradigm. We might have circles everywhere, in place of left-to-right timelines now common in media software. Regardless, it’s very likely Scott’s invention inspired Bob Moog’s own modular sequencers; it was almost certainly the young Moog’s exposure to the inventions in Scott’s basement that prompted that inventor to go into the electronic music business, thus setting the course for music technology as we know it.

See:
Raymond Scott’s Circle Machine
For more background: “Circle Machines and Sequencers”: The Untold History of Raymond Scott’s Pioneering Instruments [as reprinted from Electronic Musician]
One superb modern re-creation, via Synthtopia

Scott’s creation was shaped the way that it was partly out of mechanical necessity. Now we’re gifted with the ability to make any form we like for our electrified music tools. Circles can have appeal not because they’re somehow novel, but for just the opposite reason: they’re ubiquitous, intuitive, and geometrically elegant. So, let’s first consider these in their most abstract, in software.

Euclidean Rhythms

Incredible things are happening to our understanding of music theory as the gap between fields is shortened. Say what you will about the state of communication in our modern society; for the self-motivated, the trip “across the quad” (between academic departments) has nothing on the trip across the Internet.

Godfried Toussaint, a computer scientist with a strong math background based at Montreal’s McGill University, has a whole body of fascinating writing linking math, geometry, and music. One research paper has had a big influence on many of us, myself included. Here’s the beauty of math: an algorithm developed by Euclid in Alexandria around 300 BC also works for calculating timing systems in neutron accelerators and makes nice poly-rhythms for music. It’s rather amazing we don’t talk to each other about math more often.

Toussaint’s paper:
The Euclidean Algorithm Generates Traditional Musical Rhythms [PDF, 2005]

Our friend wesen wrote about the technique, suggesting it could be used to generate new rhythms, and included code in Lisp:
Generating african rhythms using the euclidean algorithm

wesen even made code for his amazing MiniCommand sequencing box, which I hope we’ll see more of this year. (I should have some time to work on it myself.) The actual demo is part of the way through the video:

The algorithm – the recent Bjorklund reinterpretation of Euclid’s millenia-old work – has in turn found musical life in other languages:

Python – the bjorklund algorithm and generative music[astomo.us]
Ruby – Rhythm Generation With an Euclidian Algorithm [Aleksey Gureiev]
More Ruby – jvoorhis GitHub
Java – Generating Musical Rhythms [Kristopher Wayne Reese]
Pure Data + Java – Dave Poulter
Flash/ActionScript (pictured above) – Euclidean rhythms [Wouter Hisschemöller]
Max for Live (pictured below) – Euclidean sequencer [Robin Price]

I’m implementing a touch interface for it now using Pd, Processing, and Android; I had hoped to share it by now, but I’m still fleshing it out – I’ll give it away when it’s done.

You’ll notice in these, too, the similarity to the original Scott Circle Machine, down to the sweeping arm. But that’s a benefit: glancing at them on paper, Mozart and Haydn look the same, and they use the same musical technology, but think of the musical variety that results.

A Few Circular Sequencers

Circular sequencing interfaces are plentiful – indeed, I hope that this story prompts lots of people to say “hey, what about …?” Here are a few examples.

DominoFactory’s dial uses drifting circular geometries to control musical patterns. Created by Hiroshi Matoba, a young designer/DJ, it’s one of a body of work this student creator is building:

17 Dec, 2010
at ImageRama in Kyushu University(Fukuoka/Japan)

dial is a software sequencer using circle to control loop sequences in real time. I imply “speed sync” circular notation system which differ to “angle sync” in my past work “Overbug”.

Now under developing with openFrameworks and Bullet Physics. I use ofxConsole for custom CUI in this version.

*ImageRama is one night event hosted by Genda lab. in Kyushu univ., we setup surround sound(5.1ch) and 1 full HD projector. thank you for all stuff!!

See also Matoba’s earlier Overbug, which assembles polyrhythms in lacy, overlapping wheels, like some strange, elaborate clockwork:

Overbug

You can download it for yourself for the Mac; it even has Snow Leopard support.

Also from Japan, Nao Tokui has taken these ideas in another direction, still, with “mashup” application and, in three dimensions, his original Sonasphere. The latter was one of the first interfaces to really fire my imagination as far as alternative user interfaces and three-dimensional sequencing.

http://www.sonasphere.com/

For an instance of a commercial application, see the iPad Loopseque, the development of which we profiled extensively here on CDM in August:
Loopseque, New iPad App, Offers Circular Sequencing and Visual Inspiration

The one shortcoming for me of that application is the inflexibility of the grid, which is why the Euclidean ideas above interest me, but it’s still a lot of fun.

Dan Trueman (on the faculty at Princeton) built his own Cyclotron for experimentation with cycles, with work going back to 1996. The clever invention here is the use of the spokes themselves as musical information. Quite a lot more detail and code in Processing and ChucK:
Cyclotron project page

Rui Penha and Polygons

Rui Penha deserves his own category here, I think, as he’s done a great deal of research. He has worked with polygonal shapes as a way of displaying evenness in rhythms, and he’s built not only novel interfaces, but entire musical compositional environments using these paradigms. They’re all downloadable, too.

Instrument A, pictured below, uses sampled sounds and pre-composed loops which you can then assemble into a layered composition.

Gamelan, in the video at the top of this story, uses cyclic, circular notation to make interlocking parts of music more visible, in the style of an Indonesian ensemble. I was struck by this myself as I’d constructed a (much cruder) demonstration of the same idea for a talk in Ireland; here, Rui builds it into an entire interface. Also, there’s a meaning to the symbology of the circle: Gamelan looks for other networked players with which it can interact, making this a communal experience – and it can even be used to play a real gamelan ensemble, via robotic apparatus controlled wirelessly.

Políssonosis perhaps the most sophisticated of all of these, mapping those shapes into three dimensions and making the evenness of rhythms more apparent. See video, top, and the same ideas below.

Hardware and Kinectic Art

No discussion of circular design would be complete without the legendary synthesizers of FutureRetro, which uses a cyclical interface to divide patterns and even arranges synth parameters around the rotational theme. You can now pick up an Orb for $550.

http://www.future-retro.com/

It’s worth coming full (cough) circle here and revisiting the mechanical ideas, as I think part of what grounds these abstractions is the progression of time in physical contraptions. That’s what inspires the rotating arms above and so on. Because it’s so fundamentally tied to a motor, there are too many rotating soundmakers to name, but here are a couple. They’re inspired by a discussion following our post last month:

Music, Like Clockwork: Modular Music Boxes with Rotating Wheels, Inspired by monome

Invisible Rhythm worked from the notion of a music box to make their analog drum machine Rhythm 1001.

See also the Conspiring machine – thanks to an unfortunate use of Flash, I can’t link directly easily, but head to http://www.kristoffermyskja.com/, choose work, and then select Conspiring Machine (or some of the other, related ideas) from the left-hand column.

I’m going to turn loopy if I keep going, so I’ll leave it there. But have you found circular sequencers to be musically useful? Are there hardware or software designs you appreciate that I missed here? Research worth checking out? Or are you committed to the rectangle – and if so, can you explain why?

Happy PI day. May your oscillations always be in phase.

November 04 2010

14:10

A Six-Step Process for Managing Web Projects

After years of intensive work in the IT industry, I've put together a practical guide to project development that my company uses for 99 percent of our projects. So far we've done amazingly well with this approach. Once you know it, it feels so simple and natural that you don't even know you know it. In the interest of helping other folks with their development projects -- and to encourage you to offer your tips and suggestions in the comments -- I offer our process.

Step One: Consultations

This is where you start brainstorming about the core idea, as well as any potential solutions and technologies. Capture all of the the ideas, solutions, and any relevant prices etc. You can only proceed with the next step when you feel ready to talk about specific functionality, prices and timelines.

Step Two: Planning

Make a list of all the features and functions you can imagine for this project. Then start estimating how much money and time it requires for each. Now go through your list and prioritize the functions to determine which need to be launched right away, and which are less important and can wait for a future update. Now you can begin to see how much time and money you need to build architecture, interface, design and do the bug-fixing and configuration. Move to the next step once you've established the development timeline and resolved that with the available budget.

Step Three: Wireframe

Take a blank piece of blank paper and sketch the basic structure of a website or application, and the relationships between its pages or sections. Draw your menus and the main elements. Go into as much detail as you consider important, but know that you don't have to plan through each and every element or establish every detail about how things will work and look.

Step Four: Interface

Using your wireframe as a guide, draw everything that has to appear in the final product, including everything that needs to be there. Figure out all the links, all the menus and interface methods, such as pop-up, drop-down, slider etc. You can still do this on a blank piece of paper, but I suggest to using software such as yED, which is a free download. Take your time with this stage. When you have it perfect, set it aside for at least one day and then examine it with fresh eyes. Try to find at least two places where you can save a click, make a more intuitive menu, or make something else better. Then print it out and you're ready to go with the next step.

Step Five: Design

If you haven't already begun working with him/her, begin meeting with your designer(s). Present wireframe sketches and the interface. Explain the tricky spots, explain why things are there as they are, and how your ideas have evolved. Now it's time to let them get to work.

Step Six: Programming

You should provide three things to your development team: the list of functionality, the interface outline, and the design. Now they work to make it all real.

Obviously, a lot more happens in the development and testing stage, and in future posts I'll share more advice and lessons about that and more. For now, share your thoughts and process int the comments.

14:10

A Six-Step Process for Managing and Developing Web/IT Projects

After years of intensive work in the IT industry, I've put together a practical guide to project development that my company uses for 99 percent of our projects. So far we've done amazingly well with this approach. Once you know it, it feels so simple and natural that you don't even know you know it. In the interest of helping other folks with their development projects -- and to encourage you to offer your tips and suggestions in the comments -- I offer our process.

Step One: Consultations

This is where you start brainstorming about the core idea, as well as any potential solutions and technologies. Capture all of the the ideas, solutions, and any relevant prices etc. You can only proceed with the next step when you feel ready to talk about specific functionality, prices and timelines.

Step Two: Planning

Make a list of all the features and functions you can imagine for this project. Then start estimating how much money and time it requires for each. Now go through your list and prioritize the functions to determine which need to be launched right away, and which are less important and can wait for a future update. Now you can begin to see how much time and money you need to build architecture, interface, design and do the bug-fixing and configuration. Move to the next step once you've established the development timeline and resolved that with the available budget.

Step Three: Wireframe

Take a blank piece of blank paper and sketch the basic structure of a website or application, and the relationships between its pages or sections. Draw your menus and the main elements. Go into as much detail as you consider important, but know that you don't have to plan through each and every element or establish every detail about how things will work and look.

Step Four: Interface

Using your wireframe as a guide, draw everything that has to appear in the final product, including everything that needs to be there. Figure out all the links, all the menus and interface methods, such as pop-up, drop-down, slider etc. You can still do this on a blank piece of paper, but I suggest to using software such as yED, which is a free download. Take your time with this stage. When you have it perfect, set it aside for at least one day and then examine it with fresh eyes. Try to find at least two places where you can save a click, make a more intuitive menu, or make something else better. Then print it out and you're ready to go with the next step.

Step Five: Design

If you haven't already begun working with him/her, begin meeting with your designer(s). Present wireframe sketches and the interface. Explain the tricky spots, explain why things are there as they are, and how your ideas have evolved. Now it's time to let them get to work.

Step Six: Programming

You should provide three things to your development team: the list of functionality, the interface outline, and the design. Now they work to make it all real.

Obviously, a lot more happens in the development and testing stage, and in future posts I'll share more advice and lessons about that and more. For now, share your thoughts and process int the comments.

October 31 2010

15:43

What are the Javascript libraries you depend on for programming?

I'm getting back into "real programming(tm)" with Javascript, after years of reaching for it only when I needed to manipulate a web page in the browser. As I dive back in, I'm stumbling on some great libraries, like Underscore.js (developed by the folks at DocumentCloud), persistence.js, and require.js, which make aspects of writing large programs in Javascript easier or faster.

So, I'm wondering what other libraries are out there that I should look at? What are the libraries that you rely on every day when programming in Javascript?

(I should note, I'm not asking about libraries that are focused on DOM-manipulation, AJAX, or user interface elements, like jQuery, Prototype, Mootools, ExtJS, etc.)

P.S. This a community wiki question.

October 29 2010

14:37

What are the Javascript libraries you depend on?

I'm getting back into "real programming(tm)" with Javascript, after years of reaching for it only when I needed to manipulate a web page in the browser. As I dive back in, I'm stumbling on some great libraries, like Underscore.js (developed by the folks at DocumentCloud), persistence.js, and require.js, which make aspects of writing large programs in Javascript easier or faster.

So, I'm wondering what other libraries are out there that I should look at? What are the libraries that you rely on every day when programming in Javascript?

(I should note, I'm not asking about libraries that are focused on DOM-manipulation, AJAX, or user interface elements, like jQuery, Prototype, Mootools, ExtJS, etc.)

P.S. This a community wiki question.

August 30 2010

14:00

An iPhone app developer’s diary, and some thoughts on Android

The reaction to our new free iPhone app has been tremendously positive — if you’ve got an iPhone and haven’t downloaded it yet, I suggest you hop to. On my post announcing the app, there were a few comments I wanted to respond to. First, this one from Robin Sloan, who wants a little background on how the digital sausage got made:

I’d love to read a little mini “developer diary” about the behind-the-scenes process here — tools/frameworks you used, surprises along the way, etc. Bet it would be useful to a lot of folks working on iPhone apps at news organizations, too!

So, for those interested, here’s my tale of how the Lab iPhone app came into being — a tale I hope lots more news organizations can tell. Because if I can do it for a total cost of $624, there’s no reason more newspapers shouldn’t be on the platform.

Building with frameworks

I’m nerdier than your average journalist, and I’ve done some small, basic projects in Xcode — Apple’s development environment for Macs and iPhones/iPads — before. But there’s no way I could have built this app without the help of a framework. Frameworks are tools to abstract away layers of complication — they take a variety of common tasks and handle them for you, leaving you more time to deal with tasks specific to your app. (You may have heard of Django and Ruby on Rails, popular web frameworks for building web applications.)

The framework I used is TapLynx, which is aimed at building apps from one or more RSS feeds. It’s built by Brent Simmons, best known in the tech world as developer of the first great RSS reader for the Mac, NetNewsWire. Much of the guts of TapLynx uses the feed reading and parsing code from the iPhone version of NetNewsWire.

With RSS feeds as a base, the decisions around content are both more restricted and a little easier. We produce one major RSS feed — our posts. Another one comes from our Twitter feed. So those were obvious choices as the first two tabs. In TapLynx, creating tabs is largely a matter of editing a .plist file in Xcode with some simple customizations and editing an HTML template for the display of the individual story pages. If you don’t know any HTML or CSS, you’d find the latter a challenge, but the templating language is simple enough.

Beyond that, I knew I wanted to embed some of the best publicly available feeds related to journalism, so that the app could be a concentrated shot of news-about-news. And I also wanted it to be a tool that would also promote some of our friends here around Harvard. So I added a tab that would pull in some of those feeds called Friends of the Lab. That created some new challenges, since some of the feeds were malformed in a variety of ways. One didn’t present post dates correctly, so I ended up removing dates from the presentation of all feeds in the tab. (TapLynx, unfortunately, won’t let you customize presentation for different feeds in the same tab.) I also had to build in a few template-file CSS hacks for feeds that presented images incorrectly.

Shoehorning Hourly Press in

The most challenging tab (and the one that still needs some work) is the Hot Links tab. (The name is a slight nod to my Cajun heritage.) It uses Hourly Press, the great web service built by Steve Farrell and Lyn Headley, to pull in the most linked-to links in the future-of-news Twitterverse. For THP we define a set of “authorities” (see ours here) on Twitter; the people they follow end up having more weight in the system than people they don’t. Once an hour, everyone’s tweets are scanned for links, weighted according to how much authority the system gives them, and then output in a top-10 list. It’s perfect for those moments where you want a quick jolt of the biggest news of the moment, but curated within our particular field of interest.

Because TapLynx is optimized for RSS feeds, it’s a challenge to deal with HTML, which is THP’s output. I asked the THP guys to build an iPhone version of the rankings, formatted for the smaller screen and big fingers. But TapLynx works better with static HTML than with live web pages. So I ended up having to use a plugin called OOZWebView, built by Roberto Brega and expanded by Walter Tyree. It allows for some very basic web access in a tab. I even made a few changes to the code to allow user resizing of text in webpages — the only real Objective-C I wrote. It’s not perfect — refresh behavior is unreliable, particularly in iOS4 with state saving, and the UX looks as hacky as it is. But it was the best way available. (Any Objective-C coders want to help make it better? Lemme know.)

Lagniappe

Beyond that, the search tab just uses WordPress little-known search RSS feed to dive into our archives on command. There was a fair amount of Photoshop work to create transparent PNGs at precisely the right size (and again at twice that size, to look good on the better Retina Display of the iPhone 4). I built a few of the tab icons myself as greyscale PNGs with transparent alpha channels; others I took from the Glyphish collection of icons, including the Retina icons just released via Kickstarter. For the static About page and the Twitter template, I ended up using data URIs to embed our icon into the HTML itself — that prevented a weird resizing when the image was loaded after the rest of the page. And I, like many app developers, had to navigate the new waters of Twitter’s xAuth system (newly mandatory as of a few weeks ago) to allow tweeting from within the app.

All this is to say that the process was more complicated and self-directed than most people would be able to manage — but easy enough that any shop that has a Mac and a few nerds could pull it off. There’s nothing impossibly hard here. From my viewpoint, I don’t understand why more news organizations don’t use frameworks to build out apps quickly and easily. Even if the ad revenue from a mobile app isn’t astounding, it’s still better than nothing — and it’s a foot in the door for increasingly mobile news consumers.

The upfront costs of development were minimal. I paid $500 for a license to TapLynx (it currently goes for $599). It was $99 to get into Apple’s iPhone developer program and $25 for the Retina Glyphish icons. Total cost: $624. And a fair amount of my time, to be honest.

One constant throughout the process was that there were factors outside my control. Our app would have launched sooner if Apple hadn’t made the move to iOS 4, which necessitated waiting for a new TapLynx library to work with it. It would have launched sooner if the impending Twitter xAuth switchover hadn’t made me wait. It would have launched sooner if I wasn’t relying on the generous work of guys like Roberto and Walter to made one of my tabs function. And, frankly, it would have launched sooner if I wasn’t doing all this work on evenings and weekends around my other duties — or if I’d been happy with something closer to the TapLynx defaults in a number of cases.

Now comes the challenge of keeping the thing up-to-date and functional. They say a band has a lifetime to write its first album and six months to write its second; I feel the same thing is true for version 1.0 and version 1.01. I’ve already got a list of improvements and fixes ready to move on. I’d love to hear any suggestions on how to make it better.

On Android, BlackBerry, WebOS, Windows Phone, Symbian, et al.

Back to my original post. Another thread of comments — on the post and on Twitter — were from people upset there’s only an iPhone app. “Nothing for Android, huh?” one commenter wrote. “Seems shortsighted.” Others on Twitter called out for a BlackBerry app, or an iPad-specific app. (I didn’t see any calls for Windows Mobile/Phone, Symbian, or WebOS.) There are a few reasons why we’re just on the iPhone right now.

We’re tiny. The Nieman Journalism Lab is currently three people in a basement. (Two iPhones and one BlackBerry, if you’re counting.) Along with being director, I’m also house nerd. Our budget doesn’t allow for big investments in technology, which is why I ended up building the iPhone app as a personal side project. I’ve been a Mac guy since the early 1990s and an iPhone guy since 2007, so my own personal interests and knowledge base are going to play a role in what I develop in my spare time.

Our mobile audience is overwhelmingly on Apple devices. Here’s data from the past 30 days, as of August 24, 2010: 84 percent Apple (45 percent iPhone, 35 percent iPad, 4 percent iPod touch); 10 percent Android; 5 percent BlackBerry; 0.3 percent Symbian; 0.2 percent Windows Mobile.

(If you’re curious about the overall numbers for desktop and mobile combined, our readers are about 54 percent Windows, 34 percent Mac, 4 percent iPhone, 3 percent iPad, 3 percent Linux, 1 percent Android, 0.5 percent BlackBerry.)

If, as some predict, Android sweeps aside the iPhone and becomes the dominant platform on mobile, then maybe we’ll build one. But for now, we’re just putting our limited resources where we think they can have the most impact.

We need the tools. As I said above, if there wasn’t a framework like TapLynx to make the process easier, we wouldn’t even have an iPhone app. Google’s new App Inventor would seem to be a move in that direction, but the initial reviews I’ve read don’t make it seem particularly user-friendly. (And this TechCrunch piece indicates “there isn’t any RSS functionality baked in” App Inventor, which would limit its usefulness for our app.)

That said, I don’t pretend to be up to date on the latest state of Android development frameworks — or their equivalents on other platforms. If someone out there is interested in volunteering to help build an Android (or WebOS, or BlackBerry, or Windows Phone, or Symbian) version, I’d love to hear from you. We’ve got no animus against other platforms; we just don’t yet see an audience big enough to justify our scant resources.

August 16 2010

19:19

A "Joel Test" for Coders in the Newsroom?

A while back, someone, somewhere (probably on twitter) pointed me to the Joel Test for software shops.

After reading it a few times, I got to thinking we could really use something like this for newsrooms who have or need programmers. But what to include? Here's a few initial thoughts:

  1. Do you use version control?
  2. Do coders come into regular contact with reporters and editors?
  3. Can reporters and editors easily and accurately describe what coders do?
  4. Do you have a development environment and access to servers?
  5. Do coders have the software, hardware and admin access necessary to build things?
  6. Do you test? (unit tests? benchmarks? usability?)
  7. Do you debrief?

What else would you add?

(A lot of this comes from Brian Boyer's excellent list of best practices, which you should also read)

July 29 2010

14:56

Hacks/Hackers and Mozilla want to know: How should we structure an online curriculum for journalists and technologists to learn together?

Hacks/Hackers, Mozilla, the Medill School of Journalism, The Media Consortium, and others are teaming to develop a solid six-week online curriculum that will benefit both "hacks" and hackers.

To make this work, we need feedback from both journalists and programmers on the questions:

  • What topics should be covered?
  • Would you be interested in helping to teach a topic?

Read on for more context, or just jump to the topic suggestions posted below as answers and add your vote, or -- better yet -- ideas.

Quick background

As some of you in the this community may have read, Hacks/Hackers and Mozilla are teaming up to run a six-week peer-to-peer course for "hacks" and hackers. The overall theme of the course will be "Open Journalism on the Open Web," and -- being a peer-to-peer course that is all about "open" -- we need your input and involvement to make the course a success.

As part of Mozilla's ongoing work to keep the web open, we've been supporting a number of exciting education projects through the Mozilla Drumbeat initiative & Peer-to-Peer University (P2PU). Two great examples are the School of Webcraft course -- the ultimate environment in which to learn the craft of open and standards-based web development. -- and the recent Digital Journalism course with Joi Ito of the Keio Graduate School of Media Design.

Course format

Each week the course will focus on a different topic, and each week the participants will be joined by a different subject-matter expert from the field of news innovation. The weekly course readings, online participation, and a seminar are expected to require roughly 4-6 hours.

The topics that we've outlined to date are posted below as answers to this question. Please give them a vote up / vote down to let us know what you think, or -- better yet -- add your own answers.

We also want to know:

  • Courses you want: If you were running the show (and you are!), what topics would you want to see covered?
  • Courses you want to teach: Did I mention that this is a peer-to-peer course? Seriously, what topics are you a subject-matter expert on? Would you be willing to be part of our teaching team?

We need your help to make this happen. Please take a moment to vote on the answers posted below, or comment with your ideas. (Please also indicate your interest in attending, volunteering, or teaching.)

We're hoping to run a pilot course in September, so it would be great to have your quick comments as soon as possible.

Many thanks in advance for your input.

Phillip.
(On behalf of Mozilla)

July 27 2010

12:46

Hacks and Hackers look at health, education and leisure

Online journalism expert Paul Bradshaw gives a detailed post on his experiences of a recent Hacks and Hackers day in Birmingham organised by Scraperwiki, experiences which he claims will “challenge the way you approach information as a journalist”.

Talking through the days events, Bradshaw observes how journalists had to adapt their traditional skills for finding stories.

Developers and journalists are continually asking each other for direction as the project develops: while the developers are shaping data into a format suitable for interpretation, the journalist might be gathering related data to layer on top of it or information that would illuminate or contextualise it.

This made for a lot of hard journalistic work – finding datasets, understanding them, and thinking of the stories within them, particularly with regard to how they connected with other sets of data and how they might be useful for users to interrogate themselves.

It struck me as a different skill to that normally practised by journalists – we were looking not for stories but for ‘nodes’: links between information such as local authority or area codes, school identifiers, and so on. Finding a story in data is relatively easy when compared to a project like this, and it did remind me more of the investigative process than the way a traditional newsroom works.

His team’s work led to the creation of a map pinpointing all 8,000 GP surgeries around the UK, which they then layered with additional data enabling them to view issues on a geographical measure.

See his full post here…Similar Posts:



July 21 2010

10:08

I’m a journalist – should I learn programming?

Many reporters are starting to move on from the world of HTML or CSS coding and getting to grips with more technical programming knowledge.

But web development isn’t for everyone, so how do you know if it will be right for you? Using some trusty know-how and specially selected questions, digital journalist Mark Luckie has tried to help reporters answer that very question.

His flowchart, shown below, is hosted on his 10,000 words blog.

Similar Posts:



July 19 2010

17:37
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl