The new iPaper interface for documents hosted on Scribd is pretty awesome. Their FAQ describes what's different about iPaper:

Unlike traditional document formats, iPaper is viewed inside a Web browser and doesn't require additional software to view it. At 100 KB the iPaper application is about 1/1000th the size of Adobe’s Acrobat Reader software, making it an incredibly fast way to view documents. Despite the tiny size, iPaper integrates Scribd’s social features, like emailing and embedding. iPaper' security system allows content owners to protect their work without clumsy DRM solutions. iPaper also builds on the rich features of PDF, including full text search, copy/paste functionality, view modes, and zoom.

I moved all of the presentations found in my Publications section over to Scribd. There's an example below. Click the square icon in the upper right corner to expand iPaper to full browser size. From there you'll get access to all of the following features in the top control bar:

• link to the original document on Scribd
• email a link to the document
• copy the embed code or permalink
• view document info
• print
• view document in list, book or slide mode
• zoom
• previous/next navigation
• switch from thumbnail view to full page view
• search the text in the document
• select text

Scribd also allows document owners to share the revenue from Adsense clicks that it places between slides/pages of your document. This works better when the slides are embedded at large sizes or when viewed in full screen, where the Adsense text is legible.

Scribd's Flash player is really turning out to be a versatile application, with the ability to serve up most document formats and with an excellent set of user controllable features in the embedded player. Slideshare has some catching up to do.

I've been absorbing little bits on storytelling over the years to learn to communicate design more effectively. I was taking a comic book class and started reading Manga comics as part of this pursuit, which you might have read about here. And while that helps me in terms of finding new ways of visualizing the effectiveness of documents, it doesn't help with communicating messages face to face or with spoken words.

Tina pointed to this entry in Presentation Zen featuring Ira Glass giving Tips on Storytelling. Fans of Glass' public radio show, This American Life (now also a TV show) know how the experience of hearing a story can be as immersive and engaging as anything you can watch or read. Audio, in many ways, may be even more immersive than TV. Like literature, it demands that a good deal of the experience is stitched together or imagined in the mind rather than having everything explicitly depicted with visuals. Adam Curry often calls the experience "The Cinema of the Mind," referring to some of the immersive aural experiences in walking tour podcasts. But what we as designers can take away from Glass' interview in the video below is the pattern or recipe for telling the story.

Here's the recipe with bits paraphrased from Presentation Zen:

1. Find the anecdote or sequence of actions or events that tell a story rather than provide disjointed "facts".

2. Raise questions. Provide the "bait" with the implication that you will be answering them.

3. Insert moments of reflection at points during the story—a good way to do this is by reflecting on key points between anecdotes.

That's not all there is to it, obviously. He riffs a little on the problem of finding the right or most interesting stories. Sometimes the anecdote can be wonderful, but there may be no reason to care. Experience, and the ability to be ruthless, choose the right stories, and abandon the crap makes the difference here.

The crap, in Glass' case might be a boring story, or even an interesting one perhaps that just doesn't have any importance. But when it comes to telling the stories for our projects we don't have the option of abandoning the story because it seems boring on the surface. For example, communicating design concepts viewed from the standpoint of our personas might not seem very exciting on the surface. So the question becomes, how do we make it interesting. How do we communicate the story so that the rest of the team is interested enough to mentally engage with the characters and hold them in memory long enough to use them as a motivating factor in design.

Deciding to use storytelling as the vehicle is the first step in engaging the team, I would think. The analogy I would make here is that the document delivered rich with facts and data is akin to that high school essay that Glass speaks of, where a presentation or set of documents that immerse the team in the experience of the characters is more like the engaging and well told story.

The obvious next step is figuring out how you are going to use the pattern above to make telling the story, or communicating the experience effective and engaging. I'm not prescribing a formula for that because I'm always learning how to do it better myself. I've done some things in documents that use storytelling a bit, but the real deal for me is approaching each delivery as a pitch or presentation and taking the time to work on the delivery. While Glass' recipe above is general enough to be universal, the delivery is often very different depending on the story being told, but it's worth it every time to invest some time in tailoring it to fit.