Rethinking Hollywood OS (Lame Depictions of Computers in Movies may not be so Lame)

Poking fun at hollywood depictions of computing is an old favourite on the net – compilations of dumb computing scenes outshadow even mentions of anomalies in the star trek universe. Meet The Hollywood Operating System (AKA the Movie Operating System, Movie OS). You know it well:

The Hollywood operating system, or Hollywood OS, refers to any fictional computer operating system clichéd in movies and television … These systems usually share common functions with real operating systems, but tend to be able to perform these functions at faster speeds with a more aesthetic graphical user interface (GUI), and are exceptionally more functional than today’s software. For instance, a Hollywood OS may have be able to download extremely large files in mere seconds, display error messages in large, flashing red text … They also tend to have sound effects unnecessarily accompanying every event, no matter how trivial. Some versions do not make use of a computer mouse, with virtually everything being done by keyboard or alternative input device.

I’ve often joked that it would be fun to have a job producing those systems, but recently I’ve been wondering: What’s so funny about Hollywood OS? This is not April 1 and I am serious when I say Hollywood OS has things to teach us (though I do find most of these depictions funny as well!), much as “serious” applications can be informed by video games as well (see Brenda Laurel’s The Art of HCI). In fact, Hollywood OS has two key virtues:

  • It’s an idealisation of how computing should be, and maybe one day will be. The Hollywood OS is not only easy to use due to its natural language and clear UI, but it’s also more aesthetically pleasing than the 2007 junk you’re looking at right now (even if you’re on a mac).
  • It’s a powerful abstract representation of what’s going on inside the computer and network
  • Many times, modern OSs and apps are too detailed. In contrast, Hollywood OS provides a presentation that’s not entirely accurate or precise, but conveys, at a level the user cares about, what’s going on. Just like the revolutionary London Tube Map, which foregoes precise locations in favour of a simpler view of the network and connections. Helpful Distortion principle. I could even imagine using these styles of animations in a tutorial on a given computing topic.

Let’s revisit the wikipedia definiton above – do you really think Hollywood OS sucks?

“tend to be able to perform these functions at faster speeds”

Good – it’s an idealisation of what should happen and also a compressed representation of what’s going on

“with a more aesthetic graphical user interface (GUI)”

Macs and Linux are prettier than Windows, but they Hollywood OS owns them all, and eye candy is nothing to sneeze at.

“exceptionally more functional than today’s software.”


“download extremely large files in mere seconds”


“display error messages in large, flashing red text”

How many times have you missed an error message because it was buried in 12pt times roman on a boring blue dialog, the same dialog that asked you 5 minutes ago if you feel like checking your mail. If it’s critical, large, flashing, red text would seem to be exactly what’s required.

“interface with any computer, whether terrestrial or alien (as in Independence Day)”

Actually this is pretty much possible anyway nowadays.

“They also tend to have sound effects unnecessarily accompanying every event, no matter how trivial.”

As with the visual effects, some of these sounds are actually pretty neat and help build the user’s mental model of what’s happening.

“Some versions do not make use of a computer mouse, with virtually everything being done by keyboard or alternative input device.”

Right, like the way DOS or Unix or ATMs work?

More Links What code doesn’t do in real life

Documentation As Conversation

I’m busy preparing a list of desirables for Web 2.0 APIs. One of them is good documentation, and I came up with this term – “Documentation As Conversation” – to articulate much of what is needed in modern software docs – documentation which belongs to the community of users/end-developers as it does to the people who created the product. The counter-pattern is “Documentation As 1995esque blob of HTML that you apparently haven’t updated since 2004″.

Examples of “Documentation As Conversation”:

  • The official PHP docs allow for comments on every single page. Each page represents a function (strlen() etc), meaning you get a great conversation about the intricacies of every single function, and there *are* plenty of intricacies.
  • The offiicial Scriptaculous wiki is a great description of the ins and outs of the API. Likewise Rails Wiki.
  • Javalobby had an effort to effectively wikify the official Java documentation – it still exists, but only for third-party libraries. See, Sun didn’t let it go ahead with the official API and did nothing with the idea themselves. Come on Sun, it’s not too late to help your users grok the doc!
  • Through his aptly named Loud Thinking blog as well as the official Rails blog, Rails creator DHH (+others in the latter case) offers an ongoing insight into the evolution of Rails that is at once colourful and extremely useful to the community. Unlike a number of clueless “official” blogs, comments are wide open.
  • Jon Udell uploads a video explaining how his lawnmower is operated. Manufacturers should be building a gallery of videos, images, and docs submitted by users to themselves or other sites.
  • The oldest online form of Documentation As Conversation – mailing lists, usenet, forums. Developers listen and take art in the conversation.
  • Those who practice “Documentation As Conversation” not only write themselves, but they shepherd the community and keep their ear to the ground. That is, they curate wikis; they respond to blog articles by commenting or blogging back; and they make themselves available for inteviews and appearances.

Documentation As Conversation is the way software should be documented in the world of Web 2.0.

(“Documentation As Conversation” is a play on “Markets As Conversation”, AKA the Cluetrain Manifesto.)

Weborandom Has a Practical Use!!!

Paint me Melbourne Blue and call me a serial straw clutcher, but I just discovered a practical use for Weborandom, the Web Bling-Point-Oh app that shows random websites in an Ajax carousel and has accrued no less than eight, yes that’s a superb EIGHT-point-oh Diggs :/.

Have you ever found your net connection a little slow? You start typing in web addresses that pop into your head – “” “”, etc. You want to ensure the content isn’t cached, so you keep switching web addresses or type random queries into the Google. After a while, this gets pretty tired. You’d rather concentrate on the content and stop coming up with random things to tell Google. So, no more randomising…let Weborandom choose random websites all day. Funny that this actually ties into Weborandom’s sister website timer.

Anyway, one even better step would be to just send random queries to Google, which as we all know comes back insanely fast. Maybe I’ll do that sometime. I could extend WebWait to do that, so you get the load time displayed for each random query.

So I never knew Weborandom had a practical use. I feel like the 17th century mathematicians who delighted in the purely theoreticalism of their prime number research, only to discover it would dictate every credit card transaction 200 years later. Although I don’t feel Weborandom is quite as important as PKI. Not yet…


The New Timers: The Power of Blink Tags and HTML Whitespace

It seems that Ajax people have been profoundly touched by my April 1 Ajaxian post on the new Ajax timing mechanisms. Hopefully it will lead to a new age of enlightenment for humanity and finally a cool acceptance of the fearsome blink tag.

On blink:

…And so it was that <blink>’s true purpose became known. Reborn as much out of frustration with setTimeout as it was with the promise of a more robust solution. No longer eye candy, but a super-precise timing mechanism. The thinking geek of 2007 embeds a single <blink> tag on the page, hides it with CSS, and arranges all application scheduling against the swift oscillations of this postmodern crystal timer.

On HTML whitespace:

… With the trend towards parallel computation, whitespace promises a way out of the concurrency and synchronization headaches that Ajax developers often endure.

Get the full picture @ Ajaxian. And no, no-one has yet updated AjaxPatterns to incorporate these important advances in the state of Ajax.