Have you been noticing all the pretty sliding/scrolling articles that are popping up around the Internetz? My students think they’re wonderful, and so do I. So let’s look at a roundup of some great ones.
Pitchfork magazine used the technique as a showcase for photography, featuring Bat for Lashes singer Natasha Khan, in a cover story titled Glitter in the Dark.
Lost and Found, an NPR story about photographer Charles W. Cushman, has a beautiful horizontal scrolling audio story in the middle of the page. Look for the Play button below the heading “The Year Is 1938.” Framework: popcorn.js.
The Guardian‘s Burgess linked to a scrolling graphic story about fracking — What goes in and out of hydraulic fracturing (it appears that designer Linda Dong rolled her own scrolling code for this one) — which reminded me a little of Every Last Drop, which uses scrolling graphics to tell the story of how much water we waste every day (parallax scrolling library: skrollr). I found the fracking story to be more journalistic, especially given the sources listed at the end.
Another long-form narrative dressed up very nicely with this technique: Cycling’s Road Forward, from The Washington Post. Framework: Bootstrap. Tools include Modernizr.
Unfit for Work (from Planet Money, a program that runs on NPR) has a beautiful responsive article design. I love the big data graphics embedded throughout the article. I’ve been all over the code looking for the bit that slides the sections up and down, but all I can find is very clean CSS and HTML, great attention to responsiveness, and assorted JavaScript files that don’t reference the section element, the H3, or the wallpaper class. I’m super-impressed by the code, because it looks like it can be replicated for other articles. In other words, this design is repeatable.
Too Young to Wed (from the United Nations Population Fund) is a little harder to navigate than the others, in my opinion (it interrupts the vertical scroll with horizontal-scrolling slideshows), but the gorgeous photography and heartbreaking story make it well worth a look. jQuery plugin: ScrollTo.
There are many tutorials for parallax scrolling — here’s one.
You need to learn particular software programs (e.g. Dreamweaver) so you can make things for the Web.
Journalists work inside corporate content management systems (CMSs), so there’s no need for them to know Web coding.
Both of those are incorrect. Let’s proceed.
Software for Web work
Dreamweaver is a nice program. I’ve used it for many years. But you don’t need it, and what’s more, too many people unknowingly make a lot of very bad code because they are using Dreamweaver. This last is the basis for my strongest objection to Dreamweaver: It does not help you learn how to use code correctly.
Another reason to ignore Dreamweaver: You’re not likely to find Dreamweaver in most professional newsrooms.
The software a Web coder needs:
A text editing program, for writing code. Windows Notepad and Mac TextEdit are not — repeat NOT — recommended. The best entry-level (free) programs are TextWrangler (Mac) and Notepad++ (Windows). People who code recommend TextMate (Mac) or Sublime Text (Windows or Mac).
An FTP program, for uploading files to a Web server. There are many options. FireFTP is a free Firefox plugin. FireZilla is a free stand-alone program (Mac, Windows, Linux).
An image editing program, for photo sizing and optimization, as well as creating graphics. I use Adobe Photoshop; there are numerous options.
In teaching journalism students, I think it’s worthwhile to spend some time teaching an image editing program, because serious ethical issues are involved in photo editing.
The text editing programs require no instruction. Every student can download and use those programs without help.
A demonstration of FTP might be helpful. Students can be surprisingly clueless about how the Web works. What happens when you type a URL into your Web browser? Where are those files that the browser downloads for you? They are on a Web server. How does the Web server interact with the Web browser on your computer? If you don’t understand how to manage files and folders on your own computer, and on your server, you’re going to run into problems.
No time should be spent teaching Dreamweaver.
‘Infect the CMS’
That was the title of a session at the 2013 NICAR conference, presented by Heather Billings, Jacob Harris and Al Shaw. The gist of the idea: Coders cannot build news apps, or data apps, inside the CMS — the content management system.
The CMS is built for handling articles, text, and photos. Maybe it handles video well, or maybe not. The CMS is not flexible. It expects articles, and pages that are like a big table of contents, with links to articles. The CMS does not expect an interactive animated feature with multiple options. The CMS does not expect a map that allows interactions.
So innovative features, interactive features, must be built (by coders) outside the CMS. And then (as explained in “Infect the CMS”) the coders must build new hooks into the system that allow those features to be discoverable — to be found by the CMS search engine, to be visible in the CMS archives, to show up in the “related items” sidebars of related stories in the CMS.
So when you hear someone say, “Journalism students don’t need to learn code, because they will always work inside a CMS,” you need to remember that every CMS has limitations. The limitations prevent innovation inside the CMS — so all the innovation must take place outside.
Those who cannot work outside the CMS are trapped in the CMS.
WordPress and hosted Web templates
A writer who wants only to write does not need to learn any code at all to have a website. Anyone can start a free blog at WordPress.com and write to her heart’s content.
A student or professional who wants to create an online portfolio of photos, videos, articles, etc., can do so at various sites, including Wix, Weebly and Squarespace. No coding required.
So the person who says, “I want to learn to code,” really needs to think, first, what he or she wants to do online. What does he want to build? If all he wants is to display old media works — photos, illustrations, text, videos — then code is not required.
If you want to design the future, these readymade templated sites will not help you do that.
So there’s code, and then, there’s code. Code (with a capital C, italics, spinning pinwheels and possibly fireworks accompanying it) is what my roommate in college studied. She spent long nights in a lab with mostly guys, most with foreign accents, and earned a B.S. in computer science, while I spent long nights at school board and city council meetings and earned a B.A. in journalism.
There’s no reason for my ex–college roommate to learn how to cover city council, so why would I need to learn how to write code?
One semester, my roommate had to write a compiler. In a required course. I will never know enough to write a compiler.
I’m not saying the journalists of the world have to become what she became — a systems analyst. But my roommate could (and still can) write standard English correctly, grammatically. She can communicate clearly. Her writing skills helped her rise in her profession. She wouldn’t know how to write a news story about a school board meeting, but in many situations in her jobs when writing was necessary, she could get that done quickly and well. It gave her an edge. It made her a better manager. It helped keep her projects on track.
For journalists in 2013, code starts to look more like that. Someone has even said: “In the digital age that we all live in, you are essentially illiterate if you can’t code.”
Back in the 1980s when real computers were starting to appear in people’s homes, the command line was what you got. A blinking cursor, waiting for your input. There was no graphical interface, no menus, no Windows.
The command line is still there, on every computer. Most people never know that. And why should they?
Well, here’s one reason. A few years ago, I wanted to scrape some data out of some websites, so I emailed a few people who knew about that kind of thing and asked them how they would do it. One wrote back and said she would write something in Ruby. Another wrote back and said he would write something in Python. I felt very deflated. I didn’t know Ruby or Python. Moreover, it did not seem worth it to learn a whole programming language just to do the little project I had in mind.
So I never did that project.
The command line is not a programming language — it’s more like the gateway drug to programming. Without it, you will keep hitting roadblocks if you try to learn a programming language. The command line is where programming happens.
Go ahead, take a look at the command line. Do it now. It’s on your computer already. It’s waiting for you.
Learn how to use the command line
I discovered Zed Shaw while I was searching for a way to teach journalism students to use Python (a programming language). It turns out that Zed not only wrote the world’s best introduction to programming for complete beginners — he also wrote a streamlined, basic introduction to the command line.
This book isn’t a book about master wizardry system administration. It’s just a quick introduction to get newbies going. — Zed Shaw
First, you must read the introduction, and you must do what Zed says. It’s not hard, but it requires a certain level of commitment. You have to want to learn it, not just memorize some stuff to pass a test and then forget it.
Here is where I see a big stumbling block for students. If you’re thinking about learning code as something you do just for this class, the one you’re in now, then you are not going to actually learn how to code. At all. If you think you don’t need to memorize things for the long term — the way I was forced to learn my multiplication tables back in fifth grade, which left me in tears on more than one schoolday — then you will never be able to code. Not in any real way.
Anyway, if you get acquainted with the command line (especially if you use Zed’s friendly little book to do so), it will be much, much easier for you to start learning any programming language.
If you only want to work inside a CMS (like WordPress, or Drupal, or newsroom systems such as Publicus), then don’t worry about it. You’re just a cog in the machine. You can write text in a little box and click the send button.
But if you want to work on projects like The New York Times‘s Snow Fall, or create animated graphics that tell a story, or produce data visualizations, you’re going to need a deeper understanding. You’re going to need to learn the fundamental programming structures (really learn them) and understand how they work. You will not need the equivalent of a B.S. in computer science, and you will not know as much as a systems analyst. You will need to work with variables and if statements and for loops. These exist in JavaScript, and they — these structures — are the mechanics of Web interaction.
So if you begin at the command line — at that blinking naked cursor — you can get there.
If you try to get there with JavaScript only, and no other programming languages, I’m not so sure.
I’ve been thinking for a long time about how to write this post. This is the second in a series about coding, for journalists. It’s taken a while to get to this second post because I’m still feeling conflicted about exactly what to say.
In the first post, I wrote about HTML and CSS. I have no qualms about urging journalism educators to teach some HTML and CSS in journalism courses. I even say it should be required — not as a whole course with nothing else in it, but as part of some normally required journalism course such as editing or publication design.
I’m not willing to say every journalism student needs to learn JavaScript. But I believe strongly that journalists and educators and students need to understand how the Web works, and what must happen before you see something you can interact with — on a mobile phone or a tablet or a website.
So that’s how I’m going to start — with something simple and basic that you should understand.
When you see things that move or react to your clicking and typing in any Web-based story or feature or app, that’s probably JavaScript making it all happen. Only JavaScript. Even the control buttons on an audio player or a video player — now that Flash is far out of favor, even those little buttons are created with a combination of CSS and JavaScript.
How JavaScript works
“JavaScript is a cross-platform, object-oriented scripting language” (learn more here). It’s not a small thing — JavaScript is powerful and can do most of the things that any full-fledged programming language can do. In general, it works hand-in-hand with Web pages in a very direct way, and that makes it different from all other scripting/programming languages.
In the past, we used to embed bits of JavaScript directly into our HTML, like this:
That is no longer considered good professional practice. (In fact, it’s been frowned upon for several years already.) I’ll say more about that in the next section.
So usually we make a separate file — a separate text document — and write the JavaScript code there. For any HTML page that needs to use that JavaScript code, we link the JS file to the HTML file by placing the URL of the JS file inside a <script> tag in the header of the HTML file. Okay, I know that might have been too much information for some readers. Just think of two separate text documents on your own computer. One contains all HTML. One contains all JavaScript. And the two files work together to make things happen.
What kinds of things? An example of something that everyone has used is a registration form. When you register for a website or a service, you fill in a form. The boxes you type into are made with HTML. The button you click to submit the form is made with HTML. But if the form tells you your password is too weak, and forces you to choose a different password — that’s JavaScript. If the form tells you that you did not type a valid email address – that’s JavaScript. JavaScript is testing the contents of the box (the form field) and determining whether they are valid. If not, JavaScript sends you a message.
Form validation is not very sexy, of course. JavaScript is also responsible for pretty much anything that slides, moves, unfolds, fades, hides or reveals — on any Web page. And that usually involves jQuery.
jQuery is JavaScript
jQuery is a JavaScript library. All that means is, it’s a big JavaScript file. Remember those text files I mentioned above? jQuery is one. It’s just a really big text file, full of JavaScript code. The filename is jquery.js or, more properly and completely, jquery-1.9.1.js (you can download the latest version here).
One of the best arguments for learning jQuery: It can do beautiful things with data tables. But I’m getting ahead of myself.
Beginners making Web pages can download and use various jQuery plugins — among the most popular are “lightbox” plugins (see an example), which usually display photos in an overlay, fading the rest of the page beneath a semi-transparent gray screen. Increasingly popular is the jQuery UI library, which includes all kinds of readymade pretty things such as pop-up dialog boxes. You can also use ThemeRoller to create a whole interface where everything matches and looks perfectly professional.
jQuery looks like JavaScript when you are writing (or using) functions, variables, and other standard programming structures. But it also includes syntax that was completely unfamiliar to me until I started digging into jQuery, and that syntax gives you the power to change dynamically what your HTML contains.
You can make things move. You can change the order of data (as you can see in the tables example linked above). You can change colors and styles. You can make anything respond to clicking or dragging or mouse movements. You do this by using CSS styles and selectors embedded in your HTML (which means you need to know CSS to use jQuery well).
But how can we learn these?
Ah, there’s the rub. In the first post in this series, I recommended Codecademy for an introduction to HTML and CSS. Codecademy has a JavaScript track, and it’s pretty good — but I have to say I do not consider it suitable for code beginners. In fact, I think JavaScript is daunting for anyone who has never learned any programming language before, and that’s largely why I found it hard to write this post.
Programming languages have lots of things in common — variables, loops, if statements, Booleans. They work basically the same way (especially all the object-oriented languages). If you have ever learned even one programming language — then go to Codecademy today and start learning JavaScript!
If not — do you give up? Well, no. I would never suggest that.
But I am going to suggest that you start with another language — not JavaScript. That will be the subject of my next post in this series.
If you’re proficient with HTML and CSS, you could probably start with JavaScript. Journalism students, however, are seldom proficient. Even after creating a couple of small Web projects, they tend to use both the structure (HTML) and the design elements (CSS) in a haphazard manner. The exceptions are students who fall in love with designing and problem solving and start thinking about making a career in Web development or design. Not surprisingly, those students are not plentiful in a journalism department.
Next steps
Be aware there’s a lot (really a lot!) of old, non-optimal JavaScript code and jQuery plugins out there on the Web. Searching with Google can do more harm than good when it comes to this stuff. You should check for jQuery plugins at the jQuery Plugin Registry, and you should check JavaScript syntax and methods at Mozilla Developer Network (MDN).
Two very excellent books have answered most of my questions about these things:
jQuery: Novice to Ninja (the clearest text with the most useful, practical examples; there’s a new second edition) Update: According to a post from SitePoint staffer Simon Mackie on Feb. 8, 2012, the changes in the second edition include “a fairly substantial addition to Chapter 9″ regarding jQuery Mobile, as well as updates for jQuery 1.7 (first edition covered 1.4).
As always, please post a comment here if you have a correction or a question.
Oh, and by the way — never say “Java” when you mean JavaScript. Java is a whole different language. Not the same at all.
There’s been a lot of talk about journalists learning to code, and that conversation mainly centers on programming. When we say programming, we mean the use of computer programming languages, which cause things to happen. Things happen because a user — a member of the audience — touches something or adds some information. Interaction. Programming makes things happen.
I want to write a short series of posts about coding, for journalists. That includes journalism students. And yes — it includes the journalism educators too.
Today I’m starting with something we call code, but most people would agree it is not programming. The system we use to present information on Web pages begins with HTML, a markup language that structures the content of the page.
I’m starting with HTML because I know a heck of a lot of journalism educators have never tried to learn HTML, and that’s just wrong. You know how to use a comma? Good, I would expect that. The basic use of HTML is just as important as correct use of commas, and it’s certainly not harder to learn.
In fact, it’s probably easier.
Introducing HTML to the timid, the skeptical, the downright terrified
When you think about a magazine or newspaper article, you know it probably has a headline, a byline and paragraphs. HTML is used to identify each of those things, to mark each one as a structural element of the document. Each element is surrounded by a pair of tags. Tags look like this:
<html> </html>
Similarly, when some text in a paragraph appears as bold or italic, or as a functional link to another Web page, that bit of text is surrounded by a pair of tags.
You can be fairly fluent in HTML if you memorize about seven basic tags. Go ahead, click that right now and show yourself how un-scary this is.
Now, thanks to the brilliant folks at Codecademy, you can learn HTML in a painless, even fun, way — free, online. Go there, sign up for a 100 percent free account, and get started with their Web Fundamentals track. I’ve tested this with real live journalism students, and it is just great. Go. Go now. Start at the top, do everything from top to bottom, and don’t skip anything.
So you go to Codecademy. Good! You complete a few exercises on a Sunday afternoon. Good! And then … you don’t look at any code again for two months.
Bad! Very bad!
Even more important than having a nice little project in mind is coding every day. Yes. I said every day.
Yes, of course, you’re going to miss a day now and then. But here’s my biggest, best tip ever: NEVER miss two days in a row. Never. We forget this stuff even faster than we forget foreign language vocabulary when we fail to use it.
Also, don’t exhaust yourself by working on your code-learning goals for too long at one stretch. This makes it a chore, and tedious — and you will start to associate feeling grumpy with learning code. And then you won’t learn it.
I’ve been telling my students to aim for one hour a day. Some days you’ll do less. Some days, you’ll do much more. And those are great days, when you want to keep working! I got this idea from Zed Shaw, who wrote about this idea in his introduction to his online book Learn Python the Hard Way. He compares it to learning to play the guitar. Practice, practice, practice. It’s a fine analogy.
Introducing CSS, the style that dresses up the structure
I have one complaint about the current Codecademy exercises for Web Fundamentals, and that’s the way they introduce CSS styles.
CSS can be added to HTML directly in three ways (and there are other, indirect ways too). But first, let me give you an analogy.
HTML makes the structure of a document explicit, so it’s rather like a skeleton, or the girders and beams that frame a building. On top of that skeleton, we add muscles and skin and hair. On top of the frame, we add plaster and paint and decorative flourishes. CSS is the code that governs colors and font families, size and shape, the way it all looks. This is HTML. And this is HTML with CSS.
So this code can be inserted directly into the structural areas of a document — right inside the HTML tags. This is the worst approach, because it’s a pain in the neck to change it. Codecademy starts you out with this way of inserting CSS, and that’s what I don’t like.
The second way to add CSS to HTML is to place all the styles at the top of the document, inside an area called the head (not to be confused with headings). This is slightly better, but it still means that if you needed to update or change your styles, you would have to go in and open every darned page on your website. Yeah. Imagine doing that at The New York Times.
The third way is the best way, and (I would say) the right way: All the CSS code is written in a separate document, a separate file. This way, when you have to make a change, you change it once, in one single document, and instantly it changes all the instances of that style everywhere it is used, on every page in your website.
By completely separating the style from the structure, we make it easy to update, correct and improve the styles.
But I don’t mean any disrespect toward Codecademy — they’ve done a great job overall, and the second half of their excellent Web Fundamentals track is all about using CSS in a separate document.
Why start with HTML and CSS if these are not ‘programming’?
This is an excellent question, and there is not complete agreement on the answer. In the fantastic journalism-based project Code With Me, everyone starts with HTML and CSS. Then they move on to JavaScript. Tom Giratikanon (@giratikanon) of The New York Times and Sisi Wei (@sisiwei) of ProPublica decided to match brand-new coders with mentors who agree to be available after the workshop ends. (Read more about Code With Me and check out their lovely online materials.)
ScriptEd, a program to teach code in the New York City public schools, starts with JavaScript. Here’s more information about ScriptEd.
My thought is that most journalism people — students, teachers, reporters, editors — work a lot with words. If you start them out with words, and formatting that makes their headlines look pretty and lets them incorporate photos and captions, then they are starting from a place where they already have some level of comfort. If you start them out with code, the alien nature of that world might seem to be too great a leap.
JavaScript is definitely necessary, and I’ll be writing about that in this series, a little later.
I’m not saying everyone needs to memorize massive quantities of HTML and CSS, or master these to the extent that you could code an entire 10,000-page website. No. I am saying you need to understand how this stuff works, because all the Web uses HTML and CSS.
And note, I have not mentioned any software programs in this post. This is not about software. This is like learning how to use commas.
Update: New Resource for Learning HTML and CSS
(May 4, 2013) Recently I discovered that an old favorite of mine, the HTML Dog site, has redone all their tutorials for HTML5 and CSS. Everything has been updated to reflect today’s new coding environment! Highly recommended!! Note: This site is vastly better than the W3 Schools site, where you will be misled by some outdated materials.
My university played host this weekend to several dozen journalism educators and some very wonderful working journalists. They all came to the Journalism Interactive conference to share what they know and learn new things about digital media and training the next generation of journalists.
Most of our conference sessions were in the historic building in the photo above, which provided a warm atmosphere unlike the typical conference hotel or campus-based venue. We had lovely sunny weather and lots of happy attendees. Those who were stranded overnight because of canceled flights (thanks to a big snowstorm in the northeastern U.S.) didn’t seem put out at the prospect of spending an extra day in Florida.
I produced a Storify using the tweets I had favorited during the events of Friday and Saturday at J/i. This was an interesting exercise in curation for me — I tried to keep up with all tweets tagged #jiconf as they appeared, and I favorited only about 1 in 20. Then I opened my own Twitter Favorites in the Storify editing window and made selections with the aim of representing different attendees and different panels and speakers.
Between Dan’s blog post, the Storify summary and the session videos soon to appear on the J/i website, you can get most of the resources and tips that were shared at the conference.
But if you weren’t there in person — well! You missed a really good time.
When you’re writing a blog, you should check your stats from time to time (I’m not as obsessive about it as some are) to see what people are reading, where they came from (referrers), what they click in your posts.
Search terms are especially interesting to me. They don’t exactly correlate with the most-viewed posts on a blog.
I find the popularity of the search terms timeline, timelines, and — check out the detail list! — the Chinese characters for “timeline” to be mystifying. When I do a Google search for timelines,my post about that topic doesn’t even appear on the first two pages of results.
That brings me to a key observation about paying attention to your stats. If people are coming to your site because of a search, you should think about whether you might want to offer them more on that topic. I don’t mean you should add stuff that doesn’t match the mission or purpose of your blog — but think about whether it makes sense for you to beef up your content to satisfy those searchers.
Early in 2011, I looked at my blog stats and saw that a large number of searches then included the word timeline. So I searched my blog and found I didn’t have any posts devoted to the design or production of timeline graphics. So I made a mental note to get around to that, someday — because those graphics are part of teaching about online journalism.
Later that year, in April, I was asking students in a journalism course to create an interactive timeline graphic in Adobe Flash. I wanted to show them examples, so I dug into my bookmarks — and then I had the material for a blog post about timelines (already linked above). I suppose that accounts for the extraordinary dominance of related terms in my stats for 2012.
There are hundreds of search terms (in my WordPress stats for this blog) that resulted in fewer than 40 site visits in 2012. If I did a text analysis of all the search terms (maybe using a clustering algorithm from Overview?), maybe I would find others in the 200-300 count range, or even higher, but I’m not that into it. I had enough interest to paste the top search terms into Excel and generate the chart you see above — which took a lot less time to do than writing this post!
Take a look at your blog’s search stats — if you’re serious about blogging.
Update: Total search terms that people used in 2012 to come to Teaching Online Journalism: 498 (my WordPress logs do not show any terms that were used fewer than 5 times). Total visits from those search terms: 10,837. (So the people who came for timelines may represent about one-fifth of all who came via search.) Total site visits for the year: 99,567.
