inessential by Brent Simmons

Pub Rules

I’d love to run, edit, and write for a publication bigger than just me and my blog. I don’t have time, so I won’t, at least not any time soon.

But if I were to run a publication, I’d have a few rules:

Design for reading

Obviously. See my previous post.

Design with little navigation

The way most people read is not to come to your home page and browse around. Instead, they get a link to an article via a feed, email, Twitter, Facebook, IM, and so on.

They’ll read that page and go. Close that browser tab. Putting up a whole bunch of navigation and call-outs to other sections of the site just makes the site junkier. There should be some navigation — particularly a way to get to the home page — but that’s about all that’s needed.

Forget any “social media strategy”

Publish things so good that people want to share them. That’s it.

No sharing buttons.

The site would have its own Twitter account and it would tweet a link to each new article. But that’s almost just like providing an RSS feed. (I’d probably automate this.)

Include full text in RSS feed (and no ads)

And no feedflare or any junk like that.

Design for performance

They’d most likely be static pages. If I decided to have comments — and I probably wouldn’t, because I think comments are usually just a cynical way to get more page-views — I’d use something like Disqus.

There would be few resources to load per page. CSS would be preferred to images.

I believe that people way underestimate the value of fast-loading pages. You never want someone to hesitate before following a link to your site because they remember that it’s slow. You don’t want people to give up before getting the chance to read the article. You don’t want to go dark the minute the site gets linked-to from a more-popular site.

Make URLs human-readable

Humane URLs — nothing like ?articleID=2348724&what-   the_heck   is&m=THIS

Use responsive design techniques

No separate mobile version; no separate tablet version.

Allow a single analytics system

I’d just call it stats, though.

Ideally stats would be completely unobtrusive — a system that reads the log every night and generates a report. Or it might be slightly obtrusive, like Mint, but no more than that.

Keep ads minimal

And no moving ads, or ads that appear above other things, or ads that need to be clicked to be closed, would be allowed. No interstitials. (It’s a sign of industry sickness that I even know the word interstitial.)

I’d want to use good networks like The Deck.

Allow no Flash anywhere

It might include video from time to time, but I think most people who like to read find video way too slow. And I want readers, not eyeballs. (The common use in our industry of the word eyeballs is dehumanizing. And idiotic.)

Make JavaScript optional and lightweight

The site would work without JavaScript, though it might use JavaScript.

It would not import a bunch of frameworks. The JavaScript would be non-sucky.

No constantly-running JavaScript would be allowed. I’d insist that a page, once-loaded, would use 0.0% of the CPU. No timers and no polling.

Never, ever, ever consider SEO

Do things right. I don’t care if the search engines rank it poorly, because I expect links to get passed around via other means.

When has a publication gone underlooked and then was saved by great SEO? Never. Just forget it — it’s beneath you.

No custom URL shortener

Sheesh. There’s enough of these things already.

URLs are hints, and they should be good hints. URL shorteners suck meaning out of URLs. They are not good things.

Consider a Newsstand app — eventually

Maybe, but not right at first. The priority would be to make a great website that people like to read and that works on phones, tablets, and computers.

The decision to do a Newsstand app would be based on one thing: could I provide an even better experience than I can via HTML and CSS in a browser? If so, then yes. (I’m a Mac and iOS developer with a long history of writing Newsstand-app-like code. I have a natural bent toward writing the app. But that decision would nevertheless be based only on user experience.)

And if I had an app, the website would never, ever put up an obtrusive prompt guiding you to the App Store.

Okay… what would all that get me?

Almost of the above stuff is easy. Most of it is just avoiding stuff that’s stupid, but that lots of publications do. (And that make their jobs harder, for no gain.)

The challenge belongs in one place: the quality of the writing. And that’s it.

If the articles were poorly-written or not interesting or both, the site would fail.

But I believe, though I can’t back it up with numbers, that such a site with good, interesting articles would succeed very well.