mitchchn.me

How Apple Can Solve Freemium Creep: Make a Freemium Ghetto

Mon, 19 May 2014 00:00:00 +0000

Count the problems in this picture:

I count eight, not including my crying-out-for-a-lightning-cable battery life and the one-bar reception on Rogers.¹

Eight of the top ten “Free” iPhone apps aren’t free at all. They contain in-app purchases. Apple even spells it out for us—in size 8-pt. Helvetica Neue, in text a shade darker than the white background, underneath big blue buttons that scream FREE.

These warnings, new as of iOS 7.1.1, are a welcome addition to the platform. (It only took an FTC investigation, $32-million in refunds, and a media backlash.) But they don’t address the problem of freemium creep on the App Store.

Apps with in-app purchases are still too easy to mistake for their free counterparts. They’re still cluttering up parts of the storefront where they don’t belong. And they’re more popular than ever, crowding out free and paid apps alike. None of those problems can be fixed with disclaimers.

It’s time for Apple to put its foot down and tell non-free apps where they belong. It’s time they were sent to the Freemium Ghetto.

Solution 1: Merge Freemium and Paid Apps

I don’t hate the freemium business model. Some companies wield in-app purchases for evil, but plenty of small developers have found well-deserved success by releasing their product for free with paid upgrades.

Freemium apps can be hugely effective, and that’s all the more reason why Apple needs to move them somewhere else. They’re are just too good at what they do. Their cost of entry—zilch—is just too compelling. They bulldoze everything in their path.

But where to put them? One possibility is to group freemium apps with paid apps. That way, consumers could browse the “Free” listings without having to worry about spending a cent, and all monetized apps would compete transparently and on the same level.

Here is what the App Store might look like if freemium and paid apps shared a single “Paid” list:

This setup might come across as more respectful of App Store browsers. But it’s got its problems. A merged list would be a slap in the face to developers of traditional paid apps. Only a handful would ever make it near the top ten when pitted against freemium competition.

Freemium developers wouldn’t be so thrilled with this arrangement either. They’d have to put up with the stigma of being called “Paid”. Nor would consumers be any less confused by the melange of payment options than they are now. Merging lists is a bad deal for everyone.

Solution 2: The Freemium Ghetto

A better solution requires a third type of app and a third category on the “Top Charts” screen. (The existing “Top Grossing” list would have to hit the chopping board, but that metric’s almost entirely meaningless for consumers anyway.) A new list would rise up—one where freemium apps could thrive:

The Freemium Ghetto.

All apps now belong to one of three types: Free, Paid, and Demo (freemium).²

This simple reorganization would improve the app-shopping experience immensely. Thanks to the Freemium Ghetto, “Free” would become a safe word on the App Store. There’d be no more need to question if that game you just impulse-downloaded wanted to sucker you in with hidden costs. Apps would wear their intentions on their sleeves. The App Store would feel less like the casino it resembles today.

More honest labeling would give paid apps more of a chance to succeed. Given the choice between an app labeled “FREE” and one that costs a buck, it’s obvious what most consumers will pick. But if the decision is between a demo of one app and a full version of another, the choice is more even-handed.

The Freemium Ghetto would be good news for freemium creators too—at least in the long run. They would avoid the kind of PR blow-ups that emerge when children (or childish adults) waste hundreds of dollars on an app or game they believed to be free. Parents would find the three-way distinction easier to understand than the existing choice between Paid, Free and “Free.”

By reserving the “FREE” label for those apps that truly deserve it, Apple would build consumer trust and confidence in its platform. That’s something all developers should want to see happen.

But the best part for developers? An exclusive category for apps with IAP would do wonders for exposure. No longer would freemium apps have to compete with free apps for positions in the rankings. In the Freemium Ghetto, the majority of them would be more visible than they are now.

These are all reasons why Apple should build the Freemium Ghetto. It might sound like kind of scary change that would make certain big name game publishers angry, but it’d be worth it.

Do it for your customers, Apple. Do it for your developer community. Do it the future of the App Store.

Agree? Not so much? Tell me: @mitchchn

For Americans: Pretend AT&T and Fox Broadcasting had a Canadian baby out of wedlock. That’s Rogers. One part Big Telecom, one part Big Media. ↩
I’m fond of the word “Demo” because of its connotations in the gaming world. Perhaps Apple could come up with a better moniker. It doesn’t matter. What matters is that there’s a clear separation between the three payment models on the App Store. ↩

(And eight hundred more)

Sat, 17 May 2014 00:00:00 +0000

On Wednesday night I went to bed pretty pleased with myself. My article abut the OS X command line had captured the attention of a few hundred visitors that evening. I’d even received a bit of feedback. Not bad for a week-old personal blog, eh?

I was in for one hell of a surprise. When I woke up on Thursday morning—my 25th birthday—the number of pageviews had reached 30,000. By Friday evening, just over 100,000 people had seen my article. And it feels like a good tenth of them have responded in some way: comments, compliments, and criticism. Gratitude. Typo corrections. Sage advice. Birthday wishes.

To someone entirely unused to online notoriety, it feels as though a very geeky flash mob materialized in my apartment one evening, stayed for dinner, then went home and reviewed my cooking on Yelp. I am a little dazed.

With any luck, at least a few of those visitors will invite themselves back. The Terminal post was meant for a more technical audience than my main series, Coding for Journalists. But it won’t be the last of its kind. And one of my goals for this place is to explore some of the more basic topics in hackerdom in a way that’s compelling for people of different backgrounds and skill levels. I hope I’m succeeding.¹

“You forgot X!”

Of course, there are far more than just eight utilities every Terminal user should know.

In the past couple days, dozens of people have shared with me their own favourite Terminal one-liners and scripts. I’ve learned new tricks about the tools I covered in my article, and discovered others I’d rarely or never touched. In fact, the best thing about the reaction to my article wasn’t the feedback directed at the post, my blog, or myself; it was the discussion that spawned all around the Mac-o-sphere about the command line and how to make the most of it.

I’m going to highlight a few of the more interesting utilities I missed in this post. It’s also worth taking a look at the comment section on Hacker News. There are troves of good information out there from people much more knowledgeable than I will ever be.

And now, in no particular order, the shortlist:

open

I covered open previously, but it deserves an encore for a feature several people brought to my attention. Typing open -a Safari will launch Safari—no matter where Safari is located on the system. The same shortcut works for any Mac application. There’s no need to have the full path.

This black magic is made possible thanks to Launch Services, the same system that associates filetypes with their applications in Finder. Thank you to all the users on reddit and Twitter who introduced me to this trick.

textutil

textutil uses Cocoa’s text engine to manipulate documents and convert them between various formats, including .doc, .txt, .html and .rtf. For example, here’s how to make an HTML file out of a simple Word document:²

$ textutil -convert html article.doc

Another interesting feature of textutil is its ability to concatenate (join together) multiple files into one long document. This command will join three Word documents together into one .rtf:

$ textutil -cat rtf article1.doc article2.doc article3.doc

Thanks to cstross from Hacker News for teaching me about textutil.

sips

sips is an image processing tool and a native alternative to ImageMagick. Because it’s built on top of Apple’s Core Image, the capabilities of sips go quite deep into areas such as colour profiles. But it’s also a nice tool for quick image manipulations, like converting, resizing, cropping, and rotating.

This script will convert a folder filled with jpegs to pngs:

$ for file in *.jpeg; do sips -s format png $file --out $file.png

Dr. Drang has a great writeup of his sips and how he uses it in workflows for his clients.

ssh-add

If you frequently use ssh to access a secure server, such as Amazon’s EC2, you should know about ssh-add. This command lets you save your private key file to the OS X Keychain. Set it up once, and you can use the bare ssh command without manually including the private key file or messing around with the contents of ~/.ssh/

Before:

$ ssh -i keyfile.pem [server]

After:

$ ssh-add -k keyfile.pem

$ ssh [server]

Thanks to a Hacker News user, pling, for reminding me about this one.

man

The man command to bring up help manuals isn’t exclusive to OS X, nor is there much that’s new to say about it. But Twitter user @peternlewis reminded me of a Terminal.app feature that is worth repeating. If you begin typing the name of a command into the Help menu, Terminal will automatically bring up the relevant man pages.

There are still more utilities I haven’t had a chance to cover in these two posts—and that’s not including the dozens of essential UNIX commands that are beyond the scope of a Mac-only list. But I hope that you’ve found at least some of these choices helpful for your own workflow. If you have your own favourites that you’d like to share, give me a shout on Twitter

Besides: *you* don’t need to learn basic web development—but surely you have an intelligent, non-hacker friend who does. Or maybe you’d just like to scrutinize my code, recommendations, and writing style for mistakes. Both types are welcome here. ↩
A Hacker News poster suggested that the HTML output of textutil is cleaner than what you’d get from TextEdit and MS Word. That’s good to know if true. As I’ve written before, it’s always better to write HTML by hand. ↩

Eight Terminal Utilities Every OS X Command Line User Should Know

Wed, 14 May 2014 00:00:00 +0000

The OS X Terminal opens up a world of powerful UNIX utilities and scripts. If you’re migrating from Linux, you’ll find many familiar commands work the way you expect. But power users often aren’t aware that OS X comes with a number of its own text-based utilities not found on any other operating system. Learning about these Mac-only programs can make you more productive on the command line and help you bridge the gap between UNIX and your Mac.

Update: Thanks to reader feedback, I’ve written about a few more commands in a follow-up post: (And eight hundred more).

1. open

open opens files, directories and applications. Exciting, right? But it really does come in handy as a command-line double-click. For instance, typing:

$ open /Applications/Safari.app/

…will launch Safari as if you had double-clicked its icon in the Finder.¹

If you point open at a file instead, it will try to load the file with its associated GUI application. open screenshot.png on an image will open that image in Preview. You can set the -a flag to choose the app yourself, or -e to open the file for editing in TextEdit.

Running open on a directory will take you straight to that directory in a Finder window. This is especially useful for bringing up the current directory by typing open .

Remember that the integration between Finder and Terminal goes both ways – if you drag a file from Finder into a Terminal window, its full path gets pasted into the command line.

2. pbcopy and pbpaste

These two commands let you copy and paste text from the command line. Of course, you could also just use your mouse—but the real power of pbcopy and pbpaste comes from the fact that they’re UNIX commands, and that means they benefit from piping, redirection, and the ability to be in scripts in conjunction with other commands. Typing:

$ ls ~ | pbcopy

…will copy a list of files in your home directory to the OS X clipboard. You can easily capture the contents of a file:

$ pbcopy < blogpost.txt

..or do something crazier. This hacked-up script will grab the link of the latest Google doodle and copy it to your clipboard.

$ curl http://www.google.com/doodles#oodles/archive | grep -A5 'latest-doodle on' | grep 'img src' | sed s/.*'<img src="\/\/'/''/ | sed s/'" alt=".*'/''/ | pbcopy

Using pbcopy with pipes is a great way to capture the output of a command without having to scroll up and carefully select it. This makes it easy to share diagnostic information. pbcopy and pbpaste can also be used to automate or speed up certain kinds of tasks. For instance, if you want to save email subject lines to a task list, you could copy the subjects from Mail.app and run:

$ pbpaste >> tasklist.txt

3. mdfind

Many a Linux power user has tried to use locate to search for files on a Mac and then quickly discovered that it didn’t work. There’s always the venerable UNIX find command, but OS X comes with its own killer search tool: Spotlight. So why not tap into its power from the command line?

That’s exactly what mdfind does. Anything Spotlight can find, mdfind can find too. That includes the ability to search inside files and metadata.

mdfind comes with a few conveniences that make it stand out from its big blue brother. For instance, the -onlyin flag can restrict the search to a single directory:

$ mdfind -onlyin ~/Documents essay

The mdfind database should stay up to date in the background, but you can also troubleshoot it (as well as Spotlight) using mdutil. If Spotlight isn’t working the way it should, mdutil -E will erase the index and rebuild it from scratch. You can also turn off indexing entirely with mdutil -i off.

4. screencapture

screencapture lets you take many different kinds of screenshots. It’s similar to Grab.app and the keyboard shortcuts cmd + shift + 3 and cmd + shift + 4, except it’s far more flexible. Here are just a few different ways you can use screencapture:

Capture the contents of the screen, including the cursor, and attach the resulting image (named ‘image.png’) to a new Mail message:

$ screencapture -C -M image.png

Select a window using your mouse, then capture its contents without the window’s drop shadow and copy the image to the clipboard:

$ screencapture -c -W

Capture the screen after a delay of 10 seconds and then open the new image in Preview:

$ screencapture -T 10 -P image.png

Select a portion of the screen with your mouse, capture its contents, and save the image as a pdf:

$ screencapture -s -t pdf image.pdf

To see more options, type screencapture --help

5. launchctl

launchctl lets you interact with the OS X init script system, launchd. With launch daemons and launch agents, you can control the services that start up when you boot your computer. You can even set up scripts to run periodically or at timed intervals in the background, similar to cron jobs on Linux.

For example, if you’d like to have the Apache web server start automatically when you turn on your Mac, simply type:

$ sudo launchctl load -w /System/Library/LaunchDaemons/org.apache.httpd.plist

Running launchctl list will show you what launch scripts are currently loaded. sudo launchctl unload [path/to/script] will stop and unload running scripts, and adding the -w flag will remove those scripts permanently from your boot sequence. I like to run this one on all the auto-update “helpers” created by Adobe apps and Microsoft Office.

Launchd scripts are stored in the folllowing locations:

~/Library/LaunchAgents    
/Library/LaunchAgents          
/Library/LaunchDaemons
/System/Library/LaunchAgents
/System/Library/LaunchDaemons

To see what goes into a launch agent or daemon, there’s a great blog post by Paul Annesley that walks you through the file format. And if you’d like to learn how to write your own launchd scripts, Apple provides some helpful documentation on their Developer site. There’s also the fantastic Lingon app if you’d prefer to avoid the command line entirely.

6. say

This is a fun one: say converts text to speech, using the same TTS engine OS X uses for VoiceOver. Without any options, say will simply speak whatever text you give it out loud.:²

$ say "Never trust a computer you can't lift."

You can also use say to speak the contents of a text file with the -f flag, and you can store the resulting audio clip with the -o flag:

$ say -f mynovel.txt -o myaudiobook.aiff

The say command can be useful in place of console logging or alert sounds in scripts. For instance, you can set up an Automator or Hazel script to do batch file processing and then announce the task’s completion with say.

But the most enjoyable use for say is rather more sinister: if you have ssh access to a friend or coworker’s Mac, you can silently log into their machine and haunt them through the command line. Give ‘em a Siri-ous surprise.

You can set the voice (and language!) used by say by changing the default setting in the Dictation & Speech panel in System Preferences.

7. diskutil

diskutil is a command line interface to the Disk Utility app that comes with OS X. It can do everything its graphical cousin can, but it also has some extra capabilities—such as filling a disk with zeroes or random data. Simply type diskutil list to see the path names of disks and removable media attached to your machine, and then point the command at the volume you want to operate on. Be careful: diskutil can permanently destroy data if it’s used incorrectly.

8. brew

Alright–this isn’t technically a native command. But no OS X power user should be without Homebrew. The website calls it “The missing package manager for OS X,” and that couldn’t be truer. If you’ve ever used apt-get in Linux, you will feel right at home in Homebrew.³

brew gives you easy access to thousands of free utilities and libraries from the open source community. For instance, brew install imagemagick will set you up with ImageMagick, a powerful utility that makes it possible to do anything from whipping up animated gifs to converting images between dozens of different types. brew install node will introduce you to NodeJS, the hot new tool for developing and running server-side JavaScript apps.

You can have fun with Homebrew too: brew install archey will get you Archey, a cool little script for displaying your Mac’s specs next to a colourful Apple logo. The selection in Homebrew is huge—and because it’s so easy to create formulas, new packages are being added all the time.

Archey—My command line brings all the boys to the yard.

But the best part about Homebrew? It keeps all its files in a single directory: /usr/local/. That means you can install newer versions of system software, such as python and mysql, without interfering with the built-in equivalents. And if you ever want to get rid of your Homebrew installation, it’s easy to remove.

Edit—May 15: Someone suggested to me that that you should not blindly delete the contents of /usr/local/. That’s a fair precaution. To remove Homebrew safely, use the uninstall script.

For more fun with Terminal.app, here is an A-Z list of all available console commands in OS X 10.9 Mavericks.

Recall that OS X apps are not true executables, but actually special directories (bundles) with the extension .app. open is the only way to launch these programs from the command line. It can also launch other “files” that are truly bundles, such as Pages documents. ↩
https://www.youtube.com/watch?v=G0FtgZNOD44 ↩
In truth, Homebrew is more similar to FreeBSD’s Ports system than Linux’s apt. It uses a hybrid source/binary system: if no binary is available for a particular package it will simply download the source tarball and compile it—not a problem on today’s multicore Macs. ↩

Coding for Journalists, Part 2: HTML — Workflows, Nesting and Paragraphs

Tue, 13 May 2014 00:00:00 +0000

In Part 1, we set up our environment and tested it out with a little HTML code. More importantly, we built a basic coding workflow.

Having and practicing a good workflow is important—not just for the sake of productivity, but because every project is different. A new employer might mean having to learn a new CMS, for instance, or even a new programming language. That’s why it’s important not to learn specific tools, but to have simple procedures that you know well and can fall back on.

Your new coding environment might not be as fancy as something like Codeacademy, but it will work anywhere, from your blog to the Huffington Post. To recap, the steps in our HTML workflow are:

Write your prose and code in a text editor.
Save the file with the extension .html
Double-click the HTML file to view it in your web browser.
Make changes and corrections to your code, re-save the file, and reload the page.

Now that we’re comfortable with this process, it’s time to learn more HTML.

Nesting

As we saw in Part 1, HTML is a language of tags. There are a few dozen tags in HTML5 (down from well over a hundred in HTML4). We’ll learn what many of them are for, but first let’s take a look at what they all have in common.

HTML tags interact in predictable ways. One features of tags is that they can nest, stacking together like Russian dolls. Nested tags inherit the properties of their surrounding tags. For instance, this line of code:

<strong><em>It was the best of times, it was the blurst of times.</em></strong>

…produces the following output:

It was the best of times, it was the blurst of times.

The  tag encapsulates the  tag, which encloses the text on the inside. Both tags apply their respective formatting inward, causing the contents to be rendered in both bold and italic.

Tag nesting does not have to be symmetrical:

<strong>It was the best of times, <em>it was was the blurst of times.</em></strong>

It was the best of times, it was was the blurst of times.

In this case, the  tag applies to the entire line, but the  tag only affects the second half.

Notice that in both examples, the tags are closed in reverse order from how they were opened. This pattern is called Last In, First Out (LIFO). Following this practice in your own code is crucial. The innermost opening tag should always get the innermost closing tag. The outermost opening tag should always get the outermost closing tag.

This line:

<strong><em>Please don't do this.</strong></em>

…is bad HTML. So is this:

<em><strong>Also don't do</em> this. Please.</strong>

If you ignore my advice and type these lines of code into your text editor (try it!) they will still work as expected. HTML is designed to be resilient, and browsers are forgiving of simple mistakes.¹ But why learn bad habits? Learn to nest correctly. LIFO.²

Parents, children, and siblings

Tags can be on the outside of other tags (“parents”), inside other tags (“children”), or at the same level as other tags in the tag hierarchy (“siblings”). This line of code contains parent, child and sibling tags:

<em><strong>All TV</strong> and no beer make Homer <strong>go crazy.</strong></em>

All TV and no beer make Homer go crazy.

In this example,  is a parent tag with two children (the two  tags). The  tags are siblings to each other. Child tags inherit properties from parent tags, but tags don’t have any effect on their siblings. Child tags can also be parents to their own child tags—passing down their own traits along with those of the original parents (“grandparents”).

As you can imagine, nesting more than a few tags together can make your code difficult to read—and almost impossible to bugfix. When your code involves multiple levels of tags, consider formatting it in indented style. The above example could be written out like this:

<em>
    <strong>All TV</strong> and no beer make Homer
    <strong>go crazy.</strong>
</em>

On each new line, hit the tab key to indent child tags and line up sibling tags. Your text editor will keep track of what level you’re on when you press enter. To go “up” a level, press backspace at the beginning of a line. You can also select one or more lines of code and press shift + tab to unindent them by a single level. Because it’s a good habit to get into, I’ll be using indented style for most examples from now on.

There is no limit to how deep the tag hierarchy can go—grandchildren, great-grandchildren, etc.—or how many sibling tags can exist at a particular level. As a matter of fact, most webpages are built with long and intricate tag trees.

But no matter how many tall the tree gets or how many branches it sprouts, the same principle applies everywhere: child tags inherit all the inheritable properties of their parents (and grandparents, and great-grandparents…). For this reason, writing good HTML is as much about structuring your tags as it is about choosing them.

Whitespace and the Paragraph Tag: ``

Whitespace in HTML is insignifcant. Extra spaces, tabs and line breaks are treated by web browsers as if they weren’t there at all:

<strong>This</strong>       is
        weirdly-formatted

and ugly<em> but
</em>            
  technically correct
              code.

This is weirdly-formatted and ugly but technically correct code.

Because HTML ignores whitespace, you have the freedom to format your code however you like (such as in the indented style demonstrated above). But this little “feature” creates problems for writers who need the ability to write in paragraphs:

This is <strong>one</strong> paragraph.

This is supposed to be <strong>another</strong> paragraph.

This is one paragraph. This is supposed to be another paragraph.

Unless you instruct the browser otherwise, your beautifully-crafted paragraphs will all be smushed together onto one line. Thankfully, there’s a tag for that. Using the HTML paragraph tag , we can get the expected behaviour:

<p>
    This is <strong>one</strong> paragraph.
</p>

<p>
    This is supposed to be <strong>another</strong> paragraph.
</p>

This is one paragraph.
This is supposed to be another paragraph.

Like most tags, the  tag has an opening tag and a closing tag:  It’s good practice to wrap every paragraph in  tags. Not only will they get the proper amount of line-spacing, but also the correct fonts, colours, and formatting that your site has set up for body copy.³

Manually inserting  tags between paragraphs is one of the most tedious parts of writing prose in HTML. For that reason, coders and writers have come up with several ways to make the task easier:

WordPress will automatically convert blank lines into paragraph breaks. If you know your code will be going into WordPress, simply ignore the  tag and press enter twice between paragraphs. Then copy your code into the WordPress text editor and submit your post. Other CMSes may also have an option to work this way.
Markdown treats blank lines as paragraph breaks, just like WordPress. Many CMSes support Markdown either natively or with plugins.
Use the Find feature in your text editor to search for line breaks and replace them with  tags. Write your article with blank lines between paragraphs, and then use a regular expression to replace \n\n (two consecutive line breaks) with .

Replacing paragraph breaks with tags—In TextWrangler, go to Search -> Find and set up the above search. Make sure 'Grep' is checked. Hit Replace All. Afterward, you will need to add a single opening  tag before your first paragraph and a single closing tag after your last.

Alternatively, just get used to writing  a whole lot. It’s not so bad. Better than manually fixing the multi-column layout in your coworker’s Word document which for some inexcusable reason was set in Comic Sans MS.

In Part 3, we’ll see the dozen or so HTML tags every writer should know.

Just as browsers will forgive out-of-order nesting, they will also try to make sense of your code if you accidentally leave out closing tags. Depending on various factors, an unclosed tag will apply to the rest of the section or the rest of the entire page. This is probably not what you intended to happen. So nest properly, and close your tags. ↩
The pattern opposite, found in certain programming languages, is FIFO: First In First Out. ↩
The line break tag creates one or more manual line breaks between blocks of text. Using multiple tags is a little like hitting ‘enter’ a bunch of times in Word. But does not come with any of the formatting benefits of the tag. It can cause ugly layout inconsistencies. Use it only as a last resort. ↩

Coding for Journalists, Part 1: Text Editing and First Steps with HTML

Tue, 06 May 2014 00:00:00 +0000

All code, no matter the language, is written in plain text. Plain text documents are those that don’t allow for any formatting, such as applying fonts, colours, and sizes. Documents that permit formatting are called rich text.

Rich text is what you produce in Microsoft Word or the visual editor in your CMS. Another name for it is WYSIWYG. But plain text is the only format web browsers truly understand. To start writing HTML, you’ll need to to write plain text with a text editor.

Plain and Rich— Even if we were to change the font in the right document to match that of the left, it still wouldn't be plain text. It's the underlying file format that counts.

Choose your editor

In the hands of a skilled coder, a text editor is like a Jedi’s lightsaber: not as clumsy or random as a word processor. An elegant weapon, for a more civilized age. Armed with her trusty text editor, a coder can whip up anything from a blog post to the next Facebook. The only limits are her imagination, her free time, and her venture capital.

Which text editor you decide to code with is a matter of personal taste. Like any tool, use the one you find most comfortable. Since plain text is a free and open format, you can always switch later.

Windows and OS X come with Notepad and TextEdit, respectively. They can both get the job done, but they’re missing some helpful quality-of-life features. Two fantastic and free alternatives are Notepad++ for PCs and TextWrangler for the Mac. For the rest of this series, we’ll assume you’re using one of these apps.

Text editors are for more than just code. They’re ideal for writing, too. There are many reasons to do your online writing in plain text, and I won’t cover them in this post. But the most important reason is quite simple: everything you publish on the web ends up as plain text. Specifically, it ends up as HTML.

Even if you write your articles in Google Drive or MS Word, they’re going to be converted to plain text and HTML at some point. (And if you’ve ever copied and pasted from Word into WordPress, you’ll know that plenty gets lost in translation.)

If you write online, you’ll find you just can’t avoid plain text and HTML—no matter how hard you try. So skip the middleman: practice coding and writing in your text editor. It will make your life much simpler.¹

Get your code on

Once you’ve downloaded and installed a text editor, open it up to a blank document. Since you’re a writer, the first thing you’ll want to do is turn on word wrap:²

Enabling word wrap—In TextWrangler, click the T in the top left corner and choose Soft Wrap Text. In Notepad++, go to the View menu and choose Word wrap.

Next, copy or type the following line of code into your editor:

Hello <strong>World</strong>

Save your document. Name it helloworld.html. (Make sure the extension is .html and not .txt or .html.txt.) Save it to the Desktop or a folder where you can easily find it.³ If you’ve named the file correctly, your editor will recognize that you’re writing HTML code and highlight the  tags in a distinctive colour.

MY FIRST HTML—I saved my document as helloworld.html and TextWrangler gave me purple code for my efforts. Your colours might be different.

Once you’ve saved your helloworld.html file, locate it in your file manager and double-click it. It should launch your computer’s default web browser. If that doesn’t happen, right click on the file and select Open With, then choose your browser. You should then see your new HTML page in its full glory:

A webpage— If you see something else (for instance, bits and pieces of the word ) or no formatting at all, go back and double-check the line of code above. Then save your file and try again. If you are using TextEdit on Mac, make sure you're in plain text mode (Format > Make Plain Text). If you're using MS Word... don't be.

At this point, you likely have a good of what it is that  does. Web browsers will bolden any text between  and its closing tag, . (All closing tags begin with a forward slash, ”/”.)

Let’s try a different tag. Go back to your file and change the opening  tag to . Do the same to its closing tag: . Your code should look now like this:

Hello <em>World</em>

Save your file, then go back to your web browser and refresh the page (⌘+R on a Mac, or F5 on Windows). You will need to refresh your browser whenever you make changes to an HTML file for those changes to show up. You should now see this in your browser:

Simple stuff. The  tag tells the browser to make text strong (bold), and the  tag tells the browser to emphasize (italicize) it.⁴ Tags, or elements, are all the words between triangle brackets. They’re visible in your text editor but not in your web browser. Closing tags begin with slashes. Any text between opening and closing tags is affected by those tags. If you grasp these points, you fundamentally understand HTML.

Of course, the rabbit hole goes much deeper—as we will soon see. For now, practice writing longer blocks of text and formatting them with  and . Try these exercises:

Combine multiple  tags.
Put an  tag right next to a  tag.
See what happens when you leave out a closing tag.
Go wild. Don’t worry. You can’t break anything. (At least, not until we get to JavaScript!)

Next time, we’ll go into more detail about the way tags behave and what happens when they shack up with other tags. Are you sick of the word “tag” yet? I hope not. See you soon.

If you’re already kinda familiar with HTML and want to start doing more of your writing in plain text, Markdown is for you. ↩
Web developers don’t typically use word wrap. Instead, they follow a convention of manually limiting each line of code to 80 characters long. But when you’re composing paragraphs, having to press enter once every 80 characters gets pretty ridiculous. So turn on word wrap, but try to respect the rule when writing lines that only contain code. ↩
For bonus nerd points, save all your code to a folder named src (short for “source [code]”). ↩
If you learned HTML several years ago, you may be wondering why I’m using  and  instead of  and . We’re already running into a major change in HTML5, which does away with tags that are strictly presentational in favour of tags that are semantic. We’ll learn more about this soon. ↩

Coding for Journalists, Part 0: Why Code?

Sat, 03 May 2014 00:00:00 +0000

Learn to code, they say.

It’s advice that most of us have heard at school or in a newsroom, but that few of us ever really act upon.

And no, it’s not because we aren’t wired that way. We’re smart, adaptable people. The trouble with coding is that it’s so detached from what we know and what we’re good at. We’re writers, researchers, and reporters. That’s our trade. We don’t have the time or motivation to futz around with arcane syntax, any more than we have the time to learn plumbing. We’re just not interested. We’d rather be writing.

Advocates for teaching code like to go on about “digital literacy” and how important it is. They’ll tell you that you need to start learning code right this second because otherwise no one will hire you, ever, and, hey, you’re missing out, so-get-with-the-program-already. They mean well, but I’m not a fan of this line of reasoning. Not only is it condescending to call educated people illiterate for not possessing a skill outside of their field, but you won’t encourage anyone to step out of their comfort zone and learn something new by guilting them into doing it.¹

Truth is, it isn’t necessary for the whole world to learn how to code. People in most professions can ignore programming entirely and not be any worse off for it. Not everyone needs to be make an app or be a badass hacker. There’s little point in code-for-code’s-sake, and less point in teaching programming to every single person in college or kindergarten, or whenever we’re supposed to have learned it.

That said, a certain kind of coding is useful for journalists who write on the web. And in 2014, that means pretty much all of us. That alone is a good enough reason to learn what practical coding is all about and how (and why) we should integrate it into our work.

Of course, that’s easier said than done. The online tutorials that exist are, for the most part, unhelpful and irrelevant. They’re out of date, teaching code and techniques that were current in the mid-00s or earlier. But even the good resources are geared toward developers and designers, not writers. They cover topics we don’t need to know about, and leave out others that we should. They don’t teach us how code can actually enrich our online writing and help us work more efficiently. (Most of us aren’t even aware that code can help us work more efficiently.)

Yes, it’s possible to code up flashy animations, interactive features, and data-stuffed bonanzas. But we can also use code on a smaller scale in our day-to-day writing. The goal of this series is to show you how.

Who is this for?

This series of posts is aimed at journalists and other kinds of writers. For that reason, it’s going to follow a different path from most “Intro to HTML” tutorials.² You won’t learn how to build a website or app from scratch (although you could certainly go on to do just that), but you will learn languages, techniques and best practices that you can apply whenever you make content for the web.

Apart from code itself, we’re going to cover tools that can make you happier and more productive as a digital creator, such as version control, secure backups, and writing in Markdown. These topics are outside the scope of a typical web development course, but they’re incredibly useful for anyone who writes online.

If you’ve put off learning HTML at least a dozen times before, this is the series for you. If you know some web programming but begrudge having to use it, I hope I can change your mind. Code isn’t just a last-ditch resort for when WordPress is screwing up your formatting; it’s something you can learn to appreciate on its terms. That’s because it’s the simplest and most direct way of manipulating the web.

The idea is to go from “knowing” HTML to using HTML in a way that’s precise and effective. Like Miyamoto Musashi.

It’s true that getting to that stage takes some practice and time investment. But being able to work in code is worth it—not just for your resume, but to add to your personal arsenal of skills as a writer.

And if you’re already an HTML pro, stick around. You might still learn a thing or two.

What we’re gonna learn

No one who works in media needs any convincing that the web matters. In a few short years, the conversation has shifted from ‘digital” to “digital first” to “digital only.” For many of us, web has completely replaced pen and paper as our tool of the trade.

So we should probably have some idea how it works. Just as print journalists should know what happens between the time when a draft leaves their desk and the newspaper hits a doorstop, web writers should have a general understanding of the technologies that power the modern Internet. That’s why one aim of this series is to provide context by explaining things like what goes on behind the scenes in your CMS when you write a post.

But before we get that far, we have to start with the basics. That includes learning about HTML, CSS, and JavaScript, the trifecta of languages that make up the modern web. Of the three, HTML is by far the most relevant to writers, so we are going to spend many of these posts learning how to write it in a way that’s stylistically modern and clean. Afterward, we’ll talk about tools that can make writing code easier and more enjoyable—and come up with a web production workflow that you can use from your first draft right up until you hit “publish.”

The first tutorials may seem simplistic if you’ve studied HTML before, but it may be worth your while to skim them—especially if you learned HTML more than a couple years ago. The web is always changing, and web culture and technology changes with it. This series covers HTML5—the newest version of the venerable standard. It’s much like the earlier versions, but makes some important syntax and philosophical changes that affect even the most basic code.

We’ll start later this week with Part 1: Text Editing — Reppin’ It Old School

Yes mum, I’ll get my driver’s license soon. Promise. I know it’s embarrassing that I’m 24 and I still don’t have it. OK, technically I had it but I let it expire. But that’s besides the point. I’ll get around to it. Next month. Maybe? ↩
For instance, I won’t bother explaining that HTML stands for “Hypertext Markup Language.” No one has called it that since 1993. Seriously. ↩