November 2011

One of the themes — maybe the main theme — of the rebooted Battlestar Galactica was the question: does humanity deserve to survive? Twitter’s trending topics makes me think that the answer is no.

But if I manage not to look into the Twitter abyss — something I’ve gotten very good at — I can usually answer yes to that question.

You might generalize. You might say that any list of popular things is bound to depress you, vex your vigor, jinx your joie de vivre. But I’ve found, to my surprise, that there’s one that’s pretty good: Pinboard popular bookmarks.

(It even has an RSS feed.)

It has lots of fine things to read. When I go there, I like people.

Don’t listen to Merlin Mann — whether on Back to Work or Roderick on the Line — during the day. Don’t listen during your morning commute or at the gym.

It’s an old-fashioned nightclub act. Wait till after the sun goes down, when the sky is dark and the lights are bright.

Umberto Eco’s 1995 Eternal Fascism: Fourteen Ways of Looking at a Blackshirt is worth re-reading from time to time.

What made me think of it today was the report on Boing Boing that the Senate may redefine America as a battlefield.

Miguel de Icaza says goodbye to CodeSearch and explains why it was good and useful.

And he warns: “We are going to be entering the dark ages of software research in the next few months.”

A synopsis of Marco on The Article As A Slideshow would be this: there will always be shitheads. And being a shithead will be profitable.

Our job is not to become a shithead, whether by the slow drip of bad compromises or under the weight of the wheelbarrow of money. (The wheelbarrow of money is, by the way, almost non-existent compared to the slow drip, which drips everywhere.)

If you write for the web, you hope that people will see your words as something other than a pepper of random letters on an otherwise-unspoiled page.

You hope people will take your arguments seriously. You hope people won’t think you’re a dingbat.

So you’ve mastered it’s vs. its — and you try not to use dashes too much. You’ve learned that the passive voice has its uses; you’ve learned how to build sentences and paragraphs with parallel construction; you’ve learned to use the Oxford comma.

You’re aces in my book.

But there’s this one thing — you’re still using comma splices.

(If you’re not, you can stop reading right now. This post isn’t about you.)

Picture me, a gray-haired gentleman holding up my one lens to peer closely at your writing, with a sad warble in my voice as I mutter, “Dingbats. Foamheads. Simpleminds.” (Yes, that’s exactly how I talk to myself.)

“Oh woe,” I say.

What’s a comma splice?

Except under extraordinarily rare circumstances — unless you’re Charles Dickens, for instance — you can’t use a comma to separate two independent clauses.

Bad:

Comma splices are bad, you shouldn’t use them.

Good:

Comma splices are bad. You shouldn’t use them.

Also acceptable:

Comma splices are bad; you shouldn’t use them.
Comma splices are bad — you shouldn’t use them.
Comma splices are bad and you shouldn’t use them.
Comma splices are bad, my dear Mr. Chalmesworthy; hence it prevails upon us all to use Providence as our guide and eschew their use, as we heartily eschew all mortal sins.

Confession of an 11th-grader

I was the editorial editor of the high school newspaper and my favorite writer was Hemingway. I used comma splices all the time.

My English teacher — the newspaper advisor, Mrs. Susie — finally got fed up with it and said, “Two sentences are two sentences! Even Hemingway knew that!”

So he did. Vonnegut knew it too. And Carver and Woolf. And you too.

A List Apart: Getting Started with Sass: “Unlike regular CSS, Sass’ SCSS is a real scripting language, with expressions, functions, variables, conditional logic, and loops.”

It compiles to CSS. So sensible. Why work harder than you have to?

I’ve heard from a number of people that the text rendering for this site was messed up when using Chromium on Linux. It looked like this:

I did some research, including installing the latest Ubuntu and Chromium in VMWare. I saw the bug too.

Eventually I found this bug on the Chromium bug tracker. Though the bug is specific about bold fonts and Microsoft fonts, it sounds to me as if the issue was with a line in my CSS: text-rendering: optimizeLegibility.

So I removed that line from the CSS for this site. I added a little JavaScript in the page header to check for Chromium — and, if not Chromium, then it does document.body.style.textRendering = "optimizeLegibility"; to set the style. (I still need to do a comparison to make sure it’s working correctly. I’m not even a novice when it comes to JavaScript.)

I have a few theories as to why the bug is not more widely-noticed:

1. It may be that few sites use optimizeLegibility so far.

2. The display would fix itself if you refreshed the page. My guess is that a redraw/reflow would fix the bug, and most sites have something — an image, script, iframe, something — that would trigger at least one redraw or reflow, and so the bug was largely hidden. But this site is simple enough that it wouldn’t hide the bug.

3. It may be that the bug appears only with certain fonts.

Obviously, some combination of the above is possible. (Or something else I haven’t thought of.)

My point: if you use optimizeLegibility on your site, it’s a good idea to test with Chromium on Linux.

Tim Bray reminds us of an old problem in scrolling that’s still around, that ought to get fixed.

I don’t know why I’m surprised that Consuela made it on the App Store, but I am. And glad.

Useful for developers and testers. From the hepcats at Zarra Studios.

I like native Mac text editors and use them all the time. I like that there are standard keystrokes that work the same in every editor.

But the hardest part of text editing remains text navigation. Moving around. Getting to the thing you want to edit.

What Vim gets right

Like Vim, hate Vim, or really hate Vim, you’d look silly if you didn’t admit that it’s the king of text navigation. (But, seriously, I’m not suggesting you use it. I use it, but I’m a total weirdo. Touched. With issues. I work alone in a padded room.)

Once you learn it, moving around in text becomes so intuitive-seeming and lightning-like that anything else is nearly unusable. You don’t even want to write email without it. (And you don’t have to, if you’re willing to use pine or Alpine or mutt.)

I do not need Mac text editors to emulate Vim. I’m not going to sell anyone on that, no way.

But there is one little thing they could do. And it wouldn’t hurt, and it wouldn’t change their Mac-like-ness at all.

Make Go to Line… fast and not-dumb

When you don’t have the rich (or insane, over-the-top) navigation control that Vim provides, you still usually have a Go to Line… command. That’s not a bad way to get around, not at all. I do it all the time.

Unfortunately, there’s no standard for Go to Line in Mac text editors. Each editor does it differently, and they usually screw up at least one part of it so that it’s not-particularly-usable. (Which causes me to curse through my nose, throw one of the plush toys they permit me to have, and then run back to Mama Terminal for solace.)

Here’s how Go to Line should work to make it usable for text navigation:

1. The small window that appears where you type the line number needs to be a window that opens without animation. It can’t be a sheet. It can’t be a big window. It can’t have it’s own custom animation. It has to be super-fast.

2. The insertion point must then be placed at the beginning of the gone-to line. The entire line must not be selected. (That’s a recipe for losing text if you’re an impatient and fast typist. Yes, there’s undo, but first there’s me saying ten hulk-smashes before I’m calm enough to continue.)

3. It should be obvious that it should also display line numbers (optionally, for people who want it).

It seems pretty simple.

How current editors handle it

Here are the mistakes made by various editors on my machine:

• Xcode: Big window. Selects entire line.

• BBEdit: Sheet.

• TextMate: All good.

• Espresso: Custom animation. Selects entire line.

• Mail: NO COMMAND AT ALL WHATSOEVER. MAIL, THIS IS WHY WE’RE NOT FRIENDS ON FACEBOOK.

• TextEdit: Selects entire line. Doesn’t display line numbers.

Only TextMate gets it right. BBEdit is very close — but I’d sure like to see that sheet change to a child window. (I’m a big BBEdit fan.)

I spend most of my time in Xcode, and that’s where, for me, this really should work properly. (I’ll file a radar! Yes! I will!)

Bonus: standardization

Apple has not suggested a standard for Go to Line. Editors use different keystrokes (cmd-L, cmd-J) and different commands (Go to Line, Select Line, Jump in [filename]).

This is one of those things that ought to be the same in every app. I’m all for innovation, but only when it’s different for an actual good reason. For no-brainer things — things like Go to Line — it ought to be the same, and it ought to be good, in every editor.

Double-bonus: link

I like Seven habits of effective text editing by Vim author Bram Moolenaar. It talks a lot about Vim specifically, but the lessons are general. Habit #1 is “Move around quickly.” Good article for people like me (and probably you) who edit text for a living.

The ability to read uncluttered web pages is going mainstream.

I made the point recently that technical people can avoid, or at least cut down on, ads, sharing buttons, and clutter when reading web pages — they have RSS readers, Instapaper, Readability, Safari’s Reader button, AdBlock, Flipboard, Zite, and so on.

Not all of these technologies were made with the goal of uncluttering web pages, but they have that effect. No app built for reading starts with the premise that the publisher has done an acceptable job.

That premise is, unfortunately, generally correct, and those apps and technologies are becoming more and more popular, particularly with the rise of iPad as a great reading device. (But this isn’t only about iPads, or even mobile.)

Publications shouldn’t ignore this trend.

This trend means that their medley-of-madness designs will increasingly be routed-around, starting with presumably their most-favored readers, the more affluent and technical, but extending to the less-affluent and less-technical until it includes just about everybody.

The future is, one way or another, readable.

Because that’s what readers want, and because the technology is easier to find and use and learn than ever. That trend will continue because developers live to give people technologies that make life better.

This means that ads will go un-viewed. Analytics will be less and less accurate. (They’re already inaccurate.)

Part of me wants to appeal to publishers based on emotion. The idea that the HTML web becomes the poor version, the version that only poor Dickens urchins read, while the rest of us are comfortably reading in Flipboard and Instapaper and RSS readers, makes me so sad I can hardly stand it. I love the web, the web based on http and HTML and CSS, the web that appears in web browsers. The extent that I, and people I know and people like me, already avoid this web is shameful — but we do it because we like to read. The shame is not ours.

And part of me wants to appeal to publishers based on the Apple argument. That argument says: if you do what Apple does — pay extraordinary attention to user experience; make elegant and delightful things — then you will make money.

Though Apple continuously proves this argument true, I’m not sure most people will ever believe it. It requires a certain amount of faith, and it requires trusting intuition and taste more than analytics and received wisdom. It requires a belief in humanity — or, perhaps more accurately, respect for humanity — that is believed to be incompatible with business.

And people don’t get fired for measuring things. People don’t often get fired for continuing to do things the same way they’ve always been done. But people do get fired for taking risks that don’t pan out.

Instead I won’t appeal to publishers at all. I’ll just say again that the future is readable. This could include your site, as you’ve designed it, as it appears in a browser, where you can register some ad impressions — or not.

Readers are smart, and they love to read, and they’ll go where they can read, and they have more and more options.

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.

I made the mistake of going to a website today. It’s understandable, of course — everybody does it, from time to time — and I’m sure I’ll forgive myself, eventually.

I don’t mean just any website, of course, I mean a publication. A place where a business publishes interesting things that I like to read.

I couldn’t hit the Reader button in Safari fast enough. In fact, I couldn’t hit it at all, so stunned was I by the flickering colorful circus the page presented. It was like angry fruit salad on meth.

I was there because I just wanted to read something. Words. Black text on a white background, more-or-less. And what I saw — at a professional publication, a site with the purpose of giving people something good to read — was just about the farthest thing from readable.

The site has good writing. But the pages do everything possible to convince people not to try. “Don’t bother,” the pages say. “It’s hopeless. Oh — and good luck not having a seizure!”

They’re filled with ads and social-media sharing buttons — and more ads. And Google plus-onesies and Facebook likeys. And also more ads. Plus tweet-this-es. Plus ads. (And, under-the-hood, a whole cruise-ship-full of analytics. The page required well-more than 100 http calls.)

I know. You’re shocked, right? Shocked that advertising is happening on these premises.

Obviously I’m not the first person to notice this. I’ve been reading RSS feeds since the late ’90s in part because I can use RSS to avoid the junk. And wonderful things like Instapaper, Readability, and Safari’s Reader button exist to deal with this problem.

Is this going to get worse?

I think it was in the Space Merchants (or maybe in The Merchants’ War) where this future was predicted: lower-class people would be subjected to a ton of advertising — accompanying every moment awake and asleep — while upper-class people would be insulated.

It seems obvious now, but in the ’50s I don’t think it was. And now we’d add that it’s not a class thing entirely — technical proficiency is part of the equation. If you’re technical enough to figure out how to install AdBlock (the most popular Safari extension, it appears), you’ll cut way down on ads. If you go even further and edit your hosts file and make your browser use an ad-blocking CSS file, you’ll cut down even further (and you’ll opt-out of a bunch of tracking too).

If enough people do this, publications will have to show more ads, just to make up for the ad revenue they’re missing from me and you.

I worry that this is already be happening.

Lesson from TapLynx

I worked on TapLynx for about two years, and this meant working closely with a variety of publishers. And most had these things in common:

1. No money.

2. No idea where the money’s going to come from.

3. An unswerving faith in the supreme value of analytics.

4. A willingness to try anything as long as it’s cheap or free and has analytics. Unless they’re paranoid and afraid for their jobs, which they almost always are, given #1 and #2.

Now, my entire career has been based on the simple problem that I personally can’t get enough good things to read. It almost broke my heart to learn what mad rapids the publications are plying — because I need good things to read, and I’m selfish. (I read a ton of bloggers. But some good writing comes from publications, too. And of course there is overlap between the categories.)

Lesson from The Loop

I don’t know how long I’ve been reading the RSS feed for The Loop. It always used to bug me, because the feed included ads and it lacked full-text and The Loop was so full of junk, even pop-up junk, that I didn’t like to go there, even though it had good and interesting articles.

Then Jim and Peter redesigned it, and now they have a very clean, easy-to-read website. I don’t mind at all that the RSS feed still lacks full text, because now I’m happy when I go to the actual website. (Note: you can get a full-text feed via an inexpensive membership.)

And now The Loop is number three on Technorati’s list of Top Rising Blogs of 2011. And it’s one of my personal favorites, and I recommend it to you. (But I bet you’re reading it already.)

Are they making more money? I hope so, because they’ve earned it, but also because I suggest it as a model for other publications. (It should be said that Daring Fireball has always been easy-to-read and presumably makes money too.)

Could this work for larger publications?

If slightly-larger publications adopted the same model, could it work? If actually going to the website went from painful to pleasant, would they get more traffic? Would that increase in traffic justify the humane presentation?

I’d like to think so. If you’re appealing to readers, remember that you’re appealing to people who like reading black-and-white words on a page, more-or-less.

Because for now it’s insane. Presenting good articles in the hope of attracting readers, and then making the site do everything it can to shoo away those readers, is plumb nuts.

Ballard, named for my awesome neighborhood in Seattle, is designed to be simple and easy-to-read. It uses Myriad for the title and headers if you have it, and Helvetica if you don’t. Body text is Palatino.

There are two versions:

1. For NetNewsWire 3.3

2. For NetNewsWire Lite 4

Many of the styles that come with NetNewsWire at the moment were designed when pixels were bigger, and so it would be a good idea to create some new styles.

Here’s a screen shot. Simple, yes? Yes.

I agree most strenuously with Tim Bray on the issue of curly quotes.

When you don’t use them, I think you’re an amateur. (I make an exception for email and chat, of course. And for Twitter, but only reluctantly.)

Where I differ is with the idea of remapping the keystrokes. While the standard keystrokes are slightly more painful, they’re surprisingly learnable and easy-to-use once learned. (I learned the keystrokes in 1989, back in my days laying out the college paper with QuarkXPress. City Collegian forever!)

And, once learned, you don’t have to worry about your next machine, the computer you’re borrowing, and so on. It’s not bad. The keystrokes even start to feel natural. (Well, after a few years, okay, yes.)

I’m a few days late linking to this, but it’s important. Dave Winer writes:

Designers really need to hear the following, loud and clear: The iPad browser is fully capable. It doesn’t need you to treat it differently. You’re fighting with users when you get fancy. Just stick with what works on the desktop.

There are some cases where some small tweaks make an existing website work better on iPad. This site has a few such tweaks — but only so that what you see on iPad looks like what you see on a desktop. I’d make tweaks for small laptops (like my 13” MBP) if I needed to also.

But there’s a huge difference between that and a mobile experience. Please don’t make iPads display the mobile version. (Especially when the mobile versions are so terrible so much of the time. I can’t stand the way they so often try to look like native apps, but then don’t work like native apps. And then are slow and annoying. Blech. Let websites be websites.)

I don’t know a ton (yet) about responsive design, but what I’ve read I like. Instead of targeting devices or thinking about mobile vs. desktop, you design so that your design works in a continuum of screen sizes. A sidebar might move to the bottom on a small-enough screen, for instance. Sounds totally sensible, and avoids all these junky “mobile experiences” that are so detestable.

On Twitter, Maize Hughes asked about using IMAP. Just store the RSS articles as email on an IMAP server.

He elaborated: “Imagine a desktop Thunderbird install as a mailserver I could get to from my iPhone.”

It’s a creative idea — I like the idea of re-using existing technology — but there are some problems with it. The first obvious one is that you won’t be able to get to your desktop from your iPhone when you’re not at home. (This is true for most people. I’m aware of DynDNS, yes.)

So the IMAP server would have to be on a publicly-accessible server somewhere. And then there are additional problems:

• RSS articles can change. Emails don’t change, once sent.

• You get a lot more RSS articles than email. (Obviously not true for everybody, but generally true.)

• How will the IMAP server get the RSS feeds? Will it fetch and parse them on behalf of all its users? If so, that’s very expensive. If, instead, the clients will send the parsed articles to the IMAP server for storage, that means a lot more work on the part of the clients and a lot more bandwidth used.

• An efficient RSS syncing system would take advantage of the fact that you don’t have to store a given article separately for each different user. If 100 or 100,000 users subscribe to Daring Fireball, it should store Daring Fireball just once, not 100 or 100,000 times. I’m not sure IMAP servers are designed that way.

• RSS articles don’t have reliable unique identifiers. Good feeds do. Bad feeds have unreliable identifiers, and some feeds don’t have identifiers at all.

You could, I think, with a bunch of coding and fitting-things-together, cobble up a syncing system that uses IMAP. But it wouldn’t be very efficient, and it’s not something that would work for general use.

In early 2010 I wrote up an idea for a fairly simple RSS syncing server. I think it’s a solvable problem as long as you recognize the limits. But I don’t have time to work on it (and I no longer write a client app that would use it). Nevertheless, I still think the best bet is an open source system that is simple and easy-to-install.

How do I prevent files from being backed up to iCloud and iTunes?

Your app — like mine — may have files you want to be permanent on the device but that shouldn’t be backed up. This Q&A explains how to make it work.

Tonight’s Xcoders meeting is on “Bridging the Gap: Hybrid iOS Apps.” It’s at the Facebook offices, and the after-meeting will be at the Cyclops.

(This is one of my favorite topics, but unfortunately I’ll have to miss it tonight.)

Matt Alexander on The Loop: The purported death of RSS.

Dave Winer: What I mean by RSS.

(My latest post on RSS was in June: What we talk about when we talk about RSS.)

RSS has not died, has not been resurrected, is not dying, will not need resurrection. RSS is — very quietly, behind the scenes — doing its job.

I’m looking forward to Voices that Matter in Boston this weekend. I’ve been to a couple in Seattle: I learned a lot, met people, and had a great time.

I’m doing two things at the conference: giving the closing address (“Beyond the Gold Rush”) and emceeing the UI Master Crit. (Here’s the full schedule. Lots of good speakers.)

The UI Master Crit thing should be super-fun — people who have UI issues with their shipping apps get advice from masters of the craft Bill Van Hecke, Graeme Devine, and Jason Festa. (Awesome panel, right? So cool.)

If you haven’t registered, but you’d like to go, you should use the (case-sensitive) priority code BSTSPR7 to save $150.

Peter Hosey suggests writing a test app. Great advice.

I just bought Prompt by Panic. I was inspired by that guy who replaced his Macbook with an iPad. It occurred to me that I could ssh into my dev machine from anywhere in the house and write code using vim. And I’m just weird enough to want to do that. (By “anywhere in the house” I really mean “three feet away on my other desk.”)

Prompt is cool. Simple, good.

I also got my friend (and fellow resident of sunny, lovely Ballard) Hal Mueller’s app HistoryPointer. (App store link.) (It’s a universal iPhone and iPad app.) It detects where you are and shows you, on a map, historical locations nearby. It uses the National Register of Historic Places. Totally handy. I love apps that reveal the coolness of the world around you.

I totally love this email by Linus Torvalds from 2007.

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

You might agree or disagree. Me, I’ve managed to avoid C++ entirely, so I can’t say much about it, other than that it looks crazier than Perl. (People have said the same about Objective-C, of course.)

But I will admit to an enduring love of C. I still think of C not as C but as the language.

(Via Matt Drance on Twitter.)

CodeKit looks pretty cool and useful for web developers. I haven’t watched the videos — who has time for video? — but I was tempted enough to download it anyway. (It’s a beta.)

(Via TThor, which is just about the only thing to read on a Sunday. I wish it came out earlier in the day.)

Wil Shipley: “The good news is Apple already has the tools. The bad news is they are forcing developers to use the wrong ones.”

In a post on Google+, Chris (Google Reader co-founder) writes:

I suppose sacrificing pet projects, public responsibility, and transparency could be worth it if the end is a remarkable dream fulfilled. But what if the thing you’re driving everyone toward isn’t the iPod but is instead the Zune? So just make sure it’s not that.

(Italics are from the original.)

Another good paragraph:

However, saying “no” to projects doesn’t make you Steve Jobs if you say no to inspiring things. It’s the discernment that’s meaningful, not the refusal. Anyone can point their thumb to the ground.

And:

Reader is (was?) for information junkies; not just tech nerds. This market totally exists and is weirdly under-served (and is possibly affluent).

(Via Hacker News.)

My co-worker Nick Bradbury makes some good points about how web APIs tend to change faster than desktop APIs: “The expiration date of software we create has been shortened due to the whims of those who create the web APIs we rely on.”

Zach Holman, Don’t Give your Users Shit Work: “The last thing I want to have to worry about is continually micromanaging another facet of life.”

Ten old songs I still love:

1. Ceremony, New Order

2. The Wait, The Pretenders

3. (White Man) In Hammersmith Palais, The Clash

4. Love Will Tear Us Apart, Joy Division

5. Strangers When We Meet (Buddha of Suburbia version), David Bowie

6. Cuyahoga, R.E.M.

7. In My Room, Yaz

8. Pressure Drop, Toots & the Maytals (also see Clash and Robert Palmer covers)

9. Ever Fallen in Love, Buzzcocks

10. Dollar Bill, Screaming Trees

Nick Bradbury: >But I’m surprised that the Reader team didn’t make the transition to Google+ an easy one. I realize that Reader users are a dwindling bunch, and most of them never used the sharing features. But many of those who relied on sharing were influencers, including well-known tech journalists and developers. It strikes me as a bad idea to leave these people with a bad impression of Google+, yet that will be the result of the painful transition from Reader sharing to Google+ sharing.