Newsrooms vs. Newspaper Companies

Mark Bernstein argues that newspapers aren’t overstaffed:

The heavy staffing of traditional newspapers was not the fault of management bureaucracy. It was the fault of technology and distribution.

But he’s talking about the newsrooms. The vast number of reporters and editors and support staff focusing on producing the actual content of the papers. And of course there are a lot of them, and the operation looks unnecessarily large compared to a web-only publication, because a newspaper is a hell of a thing to have to fill up with content 365 days a year.

I’m saying that for however many people there are working in a newspaper newsroom, there are several times more people working for the company in non-editorial positions. The size of the newsroom staff is the least of their problems.

NYT: In 2003, U.S. Withheld Data Showing Cellphone Driving Risks

The U.S. Department of Transportation withheld information showing just how dangerous it is to use a mobile phone while driving:

That letter said that hands-free headsets did not eliminate the serious accident risk. The reason: a cellphone conversation itself, not just holding the phone, takes drivers’ focus off the road, studies showed.

The research mirrors other studies about the dangers of multitasking behind the wheel. Research shows that motorists talking on a phone are four times as likely to crash as other drivers, and are as likely to cause an accident as someone with a .08 blood alcohol content.

And:

But “my advisers upstairs said we should not poke a finger in the eye of the appropriations committee,” he recalled. He said Mr. Flaherty asked him, “Do we have enough evidence right now to not create enemies among all the stakeholders?”

Those stakeholders, Dr. Runge said, were the House Appropriations Committee and groups that might influence it, notably voters who multitask while driving and, to a much smaller degree, the cellphone industry.

Rich Mogull on the Security Features of the iPhone 3GS

Rich Mogull:

The iPhone 3GS includes a hardware encryption chip that uses the industry-standard AES 256 protocol (that’s the Advanced Encryption Standard, with a key length of 256 bits). Hardware encryption enables a device - a phone, a hard drive, or what have you - to be nearly instantly wiped by erasing the encryption key stored on the device.

★ Charging for Access to News Sites

John Plunkett, reporting for the Guardian last week, in a story titled “Financial Times Editor Says Most News Websites Will Charge Within a Year”:

The Financial Times editor, Lionel Barber, has predicted that “almost all” news organisations will be charging for online content within a year.

Barber said building online platforms that could charge readers on an article-by-article or subscription basis was one of the key challenges facing news organisations.

I wish them good luck with this, and I mean that sincerely, but I believe this is a fundamentally flawed strategy. People bought (and continue to buy) real paper newspapers and magazines because it feels like you’re getting something worth the price. A real physical object. Yes, the true value was, is, and will be the content, but the evidence so far is that media consumers don’t see it that way. When you pay a dollar for a newspaper it feels like you’re paying for the actual stack of paper, and it feels like a fair price. That just isn’t the case with web pages. And pay walls prevent linking, and linking is how you gain traffic. And, even more importantly, they’re competing against online-only news sites that are still going to offer free access to readers.

To me this is glaringly obvious, and perhaps that is why I’m so inclined to dismiss Chris Anderson’s Free — the crux of his argument is so obvious to me that I’ve forgotten how many media industry executives still don’t believe it. I’ve argued that Daring Fireball is not “free”, it’s just that I don’t charge readers, I charge advertisers and sponsors. But this model, obvious as it seems to me, is apparently very much in dispute at existing news publications.

Undeniably, there is money to be made in digital publishing with free reader access, but whether that revenue leads to profits depends upon the scale and scope of the organization. The potential revenue does not appear to be of the magnitude that will support the massive operations of existing news organizations. What works in today’s web landscape are lean and mean organizations with little or no management bureaucracy — operations where nearly every employee is working on producing actual content. I’m an extreme example — a literal one-man show. A better example is Josh Marshall’s TPM Media, which is hiring political and news reporters. TPM is growing, not shrinking. But my understanding is that nearly everyone who works at TPM is working on editorial content.

Old-school news companies aren’t like that — the editorial staff makes up only a fraction of the total head count at major newspaper and magazine companies. The question these companies should be asking is, “How do we keep reporting and publishing good content?” Instead, though, they’re asking “How do we keep making enough money to support our existing management and advertising divisions?” It’s dinosaurs and mammals.

And it’s not really surprising that they’re failing to evolve. The decision-makers — the executives sitting atop large non-editorial management bureaucracies — are exactly the people who need to go if newspapers are going to remain profitable.

Upton Sinclair’s adage comes to mind: “It is difficult to get a man to understand something when his salary depends upon his not understanding it.”

[Sponsor] Numbrix for iPhone/iPod Touch

This new game from Parade and Threemagination is so fun you want to keep playing it. And since we keep adding new puzzles to the game automagically… you can! Numbrix was last week’s featured app, and it’s on sale right now for only $2.99.

★ Simplenote

Back in November, I held up Apple’s own Notes app as a great example of iPhone software design. I wrote:

I’ve looked at several note-editing apps available in the App Store, and most of them seem to have been designed without any recognition of just how clever and well-designed Apple’s Notes app is. Notes exposes its core functionality clearly and obviously, launches very quickly, requires very few taps to use, and uses just two simple levels of hierarchy (the flat list of notes, and the notes themselves).

But I noted three significant shortcomings:

  1. Syncing
  2. Search
  3. Rotation

All three shortcomings were addressed in iPhone OS 3.0. In short, the updated version of Notes is emblematic of Apple’s steady, iterative approach to improving the iPhone — start with the basics, then add the most-requested new features over time. However, the one area I’m not satisfied by is syncing. Notes only sync via iTunes over USB, rather than over-the-air via MobileMe like calendars, contacts, and bookmarks. On the Mac, they sync to Apple Mail; on Windows, Outlook (which is part of Office, and therefore not free — Windows-using iPhone owners who don’t have Office can’t sync notes).

For me at least, over-the-air Internet syncing is an order of magnitude more appealing than USB or Bonjour syncing. For one thing, iPhone-to-iTunes USB syncing can be time consuming, especially when performing a backup. I often go several days without syncing my iPhone to iTunes. That means that if I were to use the built-in Notes app, my notes would only be in sync between my Mac and iPhone once or twice per week.

So I don’t use Notes. Since November, shortly after posting the aforementioned article, I’ve been using a splendid iPhone app called Simplenote. I’ve tried a slew of iPhone note editing apps, and not only is Simplenote my favorite, it might be my favorite third-party iPhone app, period. It’s that good.

First, unlike most of the other iPhone note apps I’ve tried, Simplenote shows an appreciation for just how good the built-in Notes app is. Cloud Factory (Simplenote’s developers) clearly studied what is good about Notes and thought about how to make something that is good in the same ways, but improves upon its major shortcomings.

Anyone who’s used the built-in Notes app will feel right at home in Simplenote. There are no folders, just a single, simple date-sorted list of notes. There are no fields associated with a note — just like with Apple’s, a note’s “title” is simply taken from the first line of the note. Simplenote launches quickly, offers full-text search, and supports horizontal screen rotation.

The list of all notes:

Screenshot of Simplenote’s list of notes.

An individual note:

Screenshot of a Simplenote note.

In short, Simplenote improves upon Notes in two significant ways:

  1. Over-the-air syncing, which, in eight months of my use, works splendidly.
  2. Helvetica.1

What Simplenote syncs to is this simple web app, reminiscent in style and scope to the Mac app Notational Velocity, which I wrote about in a footnote to my “Untitled Document Syndrome” piece back in February. Several of the online-syncable iPhone note apps I’ve tried and discarded are designed to use existing web apps like Google Documents; but Google Documents offers all sorts of features and assumptions that don’t map well to a simple plain-text iPhone notes app. The Simplenote web and iPhone apps were designed to work with each other. They are of a piece.

The Simplenote web app is hosted on Google App Engine. In my eight months of using it, it has always been fast and syncing has been perfectly reliable. It just works.

Regarding Basic Syncing Strategies

There are two main strategies for an iPhone app to sync data to your Mac or PC.

The first is direct client-to-client sync. iTunes’s USB syncing is an example of that. A third-party example is Things, from Cultured Code, which syncs directly between the iPhone and Mac version of Things over Wi-Fi. An example of an iPhone notes app that does this is Polar Bear Farm’s Note Pad, which syncs to a native Mac and Windows desktop app named Sync, which Polar Bear Farm wrote specifically to serve as a syncing client for Note Pad.

The other strategy is to use a server on the Internet as a hub for syncing. That’s how MobileMe works, and that’s how Simplenote works.

There are several advantages to using a central web app/web service for syncing. One is that you can access your synced data from any computer with a web browser. Whereas with an app like Things, you can only access your data from your own Mac — and it must be a Mac, because there is no Windows client.

Another advantage for web-based syncing is that your data is always up to date everywhere, almost instantly. As with MobileMe, you don’t need to manually initiate a sync with Simplenote. When you launch it, Simplenote checks with the server for changes. When you make changes on the iPhone, they’re sent back to the server seconds later. The only way your data can get out of sync is if you make changes on the iPhone while there is no network available; in that case you simply need to relaunch Simplenote once network access is available.

With client-to-client syncing a la Things, you often need to initiate syncing manually. A scenario I’ve run into with Things is that I’ll jot a few shopping items using the Mac app, then, later on when I’m actually at the store, take out my iPhone and realize that I hadn’t synced. Every time you make changes, your data is out of sync until the next time you launch the iPhone and Mac clients together on the same Wi-Fi network.

The same goes for iTunes’s USB-based syncing for calendar events and contacts — if you don’t remember to manually initiate a sync (and wait for it to complete) before leaving the house, the data on your iPhone is out of date.

With Simplenote and MobileMe, so long as you have a network connection, your data is never out of sync.

To be clear, though, there are important trade-offs. The biggest downside to web-based syncing is the implicit lack of privacy. Your data resides on a server that someone else controls. I’m willing to accept this because the convenience is worth it, and the privacy issues with Simplenote are no different than with any web-based service. (It’s also worth pointing out that Simplenote uses HTTPS rather than regular HTTP, so network communication between the iPhone app and web site is encrypted. I would not use or recommend Simplenote if it didn’t use SSL to encrypt network traffic.)

With something like Things or Note Pad, your data exists only on your own machines. And with something like OmniFocus, you can sync to your own WebDAV server, if you have one. It’s a trade-off between (a) convenience and universal access and (b) the privacy advantages of your data residing only on your own devices. (And even so, keeping your data private to your own machines is no panacea. Computers and phones — especially phones — get lost and stolen.)

The Bottom Line

Amazingly, Simplenote costs just $2 — including ongoing access to the web app. On the one hand, yes, App Store prices tend to be very low, and Simplenote is very much competing against the free built-in Notes app from Apple. But when I bought Simplenote back in November, it cost $3, and I thought that price was crazy low.

What gives me pause about the low price is that I want Cloud Factory to thrive and for them to be able to maintain the web-based Simplenote component for the foreseeable future. The flawless syncing is central to Simplenote’s appeal. Yes, Google App Engine hosting is relatively inexpensive, and iPhone-sized text notes are by nature relatively tiny in terms of a service whose bandwidth quotas are measured in gigabytes, but Cloud Factory is only charging a one-time fee of $2. I’d feel better spending more — my thought back in November was that the low one-time fee was too good to be true.

On the other hand, though, the low price means there’s no reason not to try it. It’s hard for me to imagine how you could get more for $2 than you will by buying Simplenote.


  1. Yes, there are various workarounds to get the iPhone’s built-in Notes app to use Helvetica. No, none of them are as nice as having the app just default to Helvetica like it should. 

★ Putting What Little We Actually Know About Chrome OS Into Context

It has seemed obvious for some time that Google would someday release a PC OS. I became convinced after they released Android: if they’re creating and giving away a free OS for phones, why not PCs, too? But I expected that Google’s eventual PC OS was going to be an expanded meant-for-a-bigger-screen version of Android — sort of the inverse of what Apple did for the iPhone. Apple took a PC OS and whittled it down to a fundamental core, then built new handheld-specific UI libraries and APIs on top. The hypothetical PC version of Android I’m imagining would have entailed1 taking the core of the mobile Android OS and creating new meant-for-a-PC libraries and APIs on top.

So it’s not weird that Chrome was announced. But what is weird is how it was announced. And, despite the title of the weblog post in which the announcement was made — “Introducing the Google Chrome OS” — nothing has actually been introduced. There aren’t even any screenshots, let alone a demo or any specific technical information. With an expected ship date of “the second half of 2010”, it’s a textbook example of vaporware.

I don’t get the timing. Why announce it now, when it clearly isn’t close to ready? Why not at I/O, Google’s developer conference six weeks ago? Or why not wait until it’s ready to release to developers? I like facts, demos, and best of all, shipping products. I don’t like vague promises.

Web Apps as Native Apps

It’s certainly interesting and ambitious to state that the entire application platform will consist of web apps. If anyone was going to build such an OS, it’d be Google. Much of the initial commentary regarding Chrome OS has been wholly positive, but one common note of skepticism has been with regard to the “web apps are the only apps” aspect, with the frequent point of comparison being to the 1.0 release of the iPhone OS. E.g., Nick Mediati at PC World:

Both users and app developers are still hungry for so-called “native” applications — that is, software designed for a particular operating system. A prime example? The iPhone. At the 2007 Worldwide Developers Conference, Apple discussed a “pretty sweet” way of developing apps for the iPhone: Web apps. While the Apple executives onstage spoke of the potential and power of Web apps, many developers and users groaned. They didn’t just want Web apps, they wanted real apps—apps that could take full advantage of the technology the iPhone offered.

(As an aside, in the 2007 WWDC keynote, Steve Jobs didn’t describe writing web apps as a “pretty sweet” solution for developers who wanted to write software for the iPhone; he described it as a “very sweet solution”. I described it as a “shit sandwich”.)

Mediati was right that not just developers but users wanted native third party apps for the iPhone. The difference from what Google is promising with Chrome, however, is that web apps will be the native apps on the system. Presumably all of the default applications from Google itself will themselves be the Google web apps we already know. It’s an eating-your-own-dog-food issue. What irked about Apple’s endorsement of iPhone-optimized web apps as a “really sweet solution” was that, of course, none of the iPhone’s built-in apps were web apps. They were all written in Objective-C with Cocoa Touch. Apple’s own iPhone apps set a high bar for user experience — a height that could not (and still can’t) be reached with web apps running in MobileSafari.

Chrome OS sounds a lot more like Palm’s WebOS than it does the iPhone. Palm isn’t just telling third-party developers to write apps using HTML, CSS, and JavaScript, they’re doing it themselves with the WebOS’s built-in apps. In fact, considering how web-app centric Google is and always has been, Palm’s WebOS is fundamentally more Google-y than Android, a platform where native apps are written in Java.

One thing to note regarding WebOS, too, is that while a WebOS app is written with HTML, CSS, and JavaScript and runs within a WebKit frame, it can do more than a regular “web app” running in a browser. The runtime exposes additional JavaScript APIs specific to the WebOS environment. Regular web apps — ones you “run” by telling a regular web browser to load via a URL — can’t do things like access the hardware camera or post one of those cool WebOS system-wide notifications at the bottom of the screen. Or, taking the flip side, you couldn’t just take a WebOS app and run it in a web browser on any other platform. There’s a big potential difference between “web apps” and “apps written using web technologies”. If you’re a programmer, I’m sure you understand that; if you’re not, I worry that it sounds like semantic hair-splitting. The best example I can think of are Mac OS X Dashboard widgets: they too are written using HTML, CSS, and JavaScipt, but they don’t work anywhere other than Mac OS X.

I presume that there will be similar Chrome OS-specific APIs for web apps optimized to run on Chrome. But who knows? From the description in the announcement, it sounds like Chrome OS “apps” really could just be web pages. Will it support things like importing photos and videos from a camera? Again, I presume so. But then what gets stored locally and what gets stored remotely, on Google-managed servers in the quote-unquote “cloud”? Something would have to be stored locally, because uploading video (and even just full-size photos) over the Internet can be slow and expensive.

The Driver Issue

Microsoft has to deal with a veritable mountain of device drivers because Windows has to run on every “Windows PC”. But Microsoft made this problem for themselves. It is Microsoft that decided Windows would run everywhere on everything. No one says Chrome OS is going to run on all, or even most PCs. I wouldn’t be surprised if it’s only supported for use on new PCs that are specifically certified to work with it. Hence the hardware partner list in the otherwise almost information-less “Chrome OS FAQ” Google posted tonight.

Chrome Will Not Be a ‘Linux Distribution’

Renai LeMay’s “No Thanks Google, We’ve Got Ubuntu” captures another common reaction to Chrome:

In this context, Google’s decision to create its own Linux distribution and splinter the Linux community decisively once again can only be seen as foolhardy and self-obsessive.

Instead of treading its own path, Google should have sought to leverage the stellar work already carried out by Mark Shuttleworth and his band of merry coders and tied its horse to the Ubuntu cart.

“Linux” means different things to different people. At a precise technical level, Linux is not an operating system. It is a kernel that can serve as the core for an operating system. What most people mean by “Linux”, though, is an operating system built around the Linux kernel. For use as a desktop PC operating system, all the various “Linux distributions” are basically the same thing: variations of Gnome or KDE sitting atop the ancient X Window System.

Ubuntu is almost certainly the pinnacle of these distributions, but they’re all conceptually the same thing, and the only significant difference is the choice between Gnome and KDE, and even there you’re just choosing between two different environments that are conceptually modeled after Microsoft Windows. The entire X Windows/Gnome/KDE “desktop Linux” racket has never caught any traction with real people. Almost no one wanted it, wants it, or will want it.

My theory on this is rather simple. Early versions of Gnome and KDE were pretty much just clones of the Microsoft Windows UI. They’ve diverged since then, and I’d say Ubuntu’s default Gnome desktop is in most ways better from a design and usability standpoint than Windows Vista. But it’s still fundamentally a clone of Windows — menu bars within the window, minimize/maximize/close buttons at the top right of the window, the ugly single-character underlines in menu and button names. At a glance it looks like Windows with a different theme. The idea being that if you want Windows users to switch to Gnome or KDE, you’ve got to make it feel familiar. But that’s not how you get people to switch to a new product. People won’t switch to something that’s just a little bit better than what they’re used to. People switch when they see something that is way better, holy shit better, wow, this is like ten times better.2

So I think Gnome and KDE are stuck with a problem similar to the uncanny valley. By establishing a conceptual framework that mimicks Windows, they can never really be that much different than Windows, and if they’re not that much different, they can never be that much better. If you want to make something a lot better, you’ve got to make something a lot different.

Whatever Chrome OS turns out to be, it isn’t going to be that kind of “Linux”. They’re using the Linux kernel, yes, but they’re building something new and original on top of that. Linux is to Chrome OS what BSD is to Apple’s iPhone OS — which is to say something that users will never see, smell, or notice.

Everything from TiVo to Palm’s WebOS uses Linux as the kernel for its operating system — using the commodity underlying operating system (in the comp-sci sense of the term) and ignoring the commodity user interface systems. Here’s the telling line from Google’s announcement:

The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel.

From a user-level perspective, Chrome isn’t going to look, act, or work anything like Windows. And that’s why Google has a chance to make something that might actually prove popular in a way that Ubuntu hasn’t.

An Odd Name

I’m sure what I’m about to suggest is anathema to Google employees, but in addition to the sky high vapor-to-bits ratio, there’s another aspect of the Chrome OS announcement that reminds me of Microsoft: the name. In the same way that Microsoft has used “Windows” to describe very different things — both a computer operating system and an online suite of web apps — Google is now using “Chrome” to describe two very different things.

A web browser is very different from an OS, even if the OS only runs the browser. Google themselves recently conducted a survey that suggests that most regular people do not understand at all what a “web browser” is. If regular people are confused about what a browser is, it’s a good bet they’re even more confused about what an “OS” is. Calling them both “Chrome” isn’t going to help clarify the matter. Install Chrome the browser on your PC and if you don’t like it, you can delete it and you’re right back where you were. Install Chrome the OS on your PC and if you don’t like it, you can delete it and you have a blank hard drive. I’m not predicting that people will mistakenly install one when they meant to install the other; I’m just saying that significantly different things should have significantly different names.

Client-Services, Not Client-Server

There have been numerous client-server systems throughout the history of the computer industry. Some popular; some not. The basic idea behind all of them is that you have many cheap client machines that users actually sit in front of, connected to a few expensive server machines that do most of the actual computing. The complexity is almost entirely on the server side, managed, presumably, by professional experts. A single client machine, unconnected to the network, is pretty much useless.

Chrome OS is in many ways a return to that model. Web apps largely consist of server-side code, with a relatively thin layer of JavaScript that runs on the client. Data, too, mostly resides on the network, not the client machine.

But there’s a big difference. The Chrome OS model isn’t about thin clients connecting to a server. It’s about thin clients connecting to many and any servers. One of the few sure things about Chrome OS is that it’s going to work well with Google’s own web apps, but the web is open, and Google is a strong proponent of open web standards. Everyone will have the opportunity to write web apps that run just as well in Chrome OS as Google’s own.

At an abstract level, there is much appeal to this concept. With all of your data and all of the software you use online, you have nothing to back up. Nothing to migrate when you buy a new computer — just log in from a different Chrome OS machine and there’s all your stuff.

But at a practical level, how well will this actually work? Is it feasible to use Chrome OS as your sole computer? If not, how big is the market for “secondary” computers, especially as (a) more and more people buy laptops to serve as their primary machines, and (b) more and more people buy iPhones and Pres and Android-based mobile phones? I say: not very big. In short, will Chrome OS pass the dog food test: is it something Google’s own engineers will want to use?

I’m skeptical about the prospects of any new system or product that isn’t intended for use by the people creating it. Gmail, for example, is the best web mail system because it was designed to be used not just by “typical” users but by expert users, including the engineers at Google who made it. The iPhone is simple enough to appeal to almost anyone, but guess which phone the people who created it use?

Make something intended not for your own use, but for use by dummies, and you’ll usually wind up creating something dumb. The future of computing probably is in the direction of thin clients connecting to network services for storage and software, but my hunch is that Chrome OS is too thin.


  1. Or, perhaps, it will entail rather than would have entailed, as I’m not convinced that the existence of Chrome OS precludes Google from also releasing a PC version of Android. It sure would be odd for Google to produce two competing netbook-optimized OSes, but what little we do know about Chrome OS so far is, well, a little odd. And because they’re both open source, it could be that Android continues evolving into a credible PC OS through community effort alone. 

  2. The group that’s the most enthusiastic about Gnome and KDE desktop Linux systems consists of those who care the most about the political and licensing aspects. With regard to the freedoms that stem from the software being open source, something like Ubuntu isn’t just, say, ten times better than Windows or Mac OS X, it is infinitely better.