Alan Brandon

Via content strat doyenne Kristina Halvorson — check out Firehead’s page with “1001″ content strategy links. I just fell ‘way behind in my reading!

You can’t play Facebook games on the iPad.

The much anticipate Apple iPad everything-killer is coming, due to arrive in consumers’ hands this Saturday. Previews and reviews abound, and while there seems to be a lot to love about the iPad there are also a few complaints. One of the biggest gripes is the device’s lack of Flash support. Many, many websites run on flash, but Apple appears to be taking a firm stand against the ubiquitous technology. The reasons for their anti-Flash stance are plentiful, and alternatives seem scant.  Apple is taking a gamble here.

Apple’s intended iPad customer is the casual computer user who wants to check email, listen to music, watch a movie, read the paper, and surf the web. But when these customers visit Facebook on their iPad, they are in for a shock. The majority of the popular social games run on Flash.

Farmville (and the other ‘ville games), Cafe World, Lexulous, Bejeweled Blitz, and many other games depend on your browser having Flash installed to work. So the question is, will iPad customers (and potential iPad customers) be willing to give up their virtual horse stables and imaginary restaurants?

In a move reminiscent of the mid-90s browser compatibility wars, Apple has compiled a list of “iPad-ready websites”. Seriously? The list does include heavy hitters such as CNN, The New York Times, and The White House. But Facebook is the second most visited site on the Internet after Google. That’s a lot of online farmers to alienate.

Maybe a better question is “will Farmville kill the iPad?” — or at least change Apple’s stance on Flash?

In the last couple of months there has been some great discussion inspired by Michael Hiatt’s blog post about the “myth of single-source authoring”.  I love Michael’s summation of the nearly 20-year history of single sourcing:

Single-source publishing is a zombie idea that revives itself periodically and refuses to stay dead. Its zombie supporters chant its purported benefits as a “write once, publish to many” promise and ploddingly follow it as their ultimate goal for mechanized authoring and machine translation. As an object-oriented writing methodology, it is as human as present-day robot technology—good only for conveyor belt assembly or specialized tasks, and always very expensive to implement. Single-source publishing lacks purpose in today’s world of information turnover and the dynamic nature of the Web 2.0 moving to Web 3.0 landscape.

In my experience at companies large and small, I have never seen a successful implementation of a single-source process. Like so much else in writing (and life) one size does not fit all. Sure, single-sourcing has its place and can be a great tool for some types of information delivery. But different audiences need different communications channels, and different channels need their own approach to crafting information.

Also check out Tom Johnson’s podcast and interview with Michael at Tom’s blog, I’d rather Be Writing.

“Making the case for web content strategies – Common questions from the content creator” is the title of a great diagram created by Richard Ingram. (Click for a larger view.)

As Richard says:

Hiring an external contractor to help create useful, usable, and enjoyable web content without a comprehensive content strategy raises too many questions and stops them dead in their tracks.

Via @halvorson on Twitter.

Sure all the cool kids are doing it but is collaborative, social, conversational product documentation really the best way to meet your customers’ needs? Despite the buzz, Web 2.0-based documentation can act as a roadblock to getting your content to your readers.

Ellis Pratt at Cherryleaf has a good summary of some of the problems experienced by organizations that had made the move to wiki-based documentation:

Users were struggling to find information they wanted.

The wiki-based user community platform was incomplete, out-of-date and incorrect in places.

The content was the most viewed content of all the literature her company produced, but no-one wanted to take responsibility to manage the content.

The Documentation team did not “own” the community content, but whenever there was an issue, they were asked to fix it.

Users saw it as official information, but the organisation saw it as unofficial information.

[Management] didn’t want to spend the team’s precious time editing user content at the expense of writing new official content.

They had a continual battle with content spam.

It was hard to migrate content between the formal and informal documentation sets.

Some of these issues can be addressed organizationally, and others must be addresed by infrastructure. Many of the features of traditional publishing that we have come to take for granted (namely, predictable, repeatable navigation) have been crippled or lost in the movement to adopt “good enough” publishing tools and strategies.