We're finally starting to get it. The capabilities of the Web aren't just in reprinting static content Online. Old media has been hard-pressed to embrace and to explore the true richness of interactivity possible in Web Apps and the use of Information Graphics. Meanwhile new media companies have innovated rich apps with great interfaces, but nowhere the depth of content available in the data stores of a publishing juggernaut like the New York Times. The result is a split between the world of rich applications that feel like toys lacking substance and substantial content sources lacking interfaces to make them easier to explore, to mine and to interact with.

New York Times Digital News Editor Jim Roberts talked about the future of NYT Online as Mediabistro Circus' keynote speaker on Wednesday the 21st of May. He noted that NYT still makes 80% of its revenue from the print version and has yet to make money on the web. "We haven't made money... It has helped revitalize the institution, it has helped revitalize the profession," Roberts said. The best thing to happen is "the harnessing of the Web, to enhance reporting, to provide data and give users the tools to use that data," he continued. They are hoping that data-driven interactive apps will change that.

Aron Pilhofer, editor of interactive news, has been charged with creating "news-focused, data-driven apps," such as the Election Guide 2008. The site had it's second- and third-highest traffic days during Super Tuesday and Wednesday, drawing 35.9 million and 37.5 million uniques, respectively, proving that people are equally, if not more, interested in analyzing data the day after the primaries. ("There were headlines to write but I was sitting around playing with maps," Roberts said of his use of these maps during Super Tuesday.) An NFL playoffs app the group threw together over "four or five days" during Christmas break earned $150,000. Recently, the group had all 17,000 pages of Hillary Clinton's schedule online and searchable hours after their release.

Source: http://www.mediabistro.com/fishbowlny/media_events/nyt_digital_news_editor_web_represents_golden_age_of_storytelling_85315.asp

Perhaps the NYT will consider opening up their data and content store so that third parties can create even more compelling and interactive apps... Taking a lesson from the social web, ala Facebook or OpenSocial. But, that's likely just a bit too Web 2.0.

Daily Lit. Get your fix of literature a little at a time, straight to your inbox or favorite RSS Reader. Its almost like the days of reading Charles Dickens in the Evening Post... Bite sized serializations. Or, a little like a mashup of a Podcast and an EBook. Either way, its an idea that just makes sense.

I poked around for a bit to see what they offer authors who want to make their books available... didn't see anything on first glance. Seems like a great way to self-promote as a writer... even by offering free books. I see they have free syndication of books in the public domain. Maybe I can catch up on my classics.

I want mine in twitters and text messages. If only SMS didn't have this damned 250 Character limit... and my phone's screen less readable than a mimeograph.

Maybe they should get together with Brijit.com for the SMS Subscription.

Brijit: A news aggregator service pays writers $5 for any 100 word summaries of news they publish. From their about page: "Brijit aggregates the world's best long-form content and abstracts it in 100 words or less, providing busy, omnivorous, and increasingly mobile readers with rich, qualitative summaries as well as better guideposts for what to read, watch or listen to now." True to all emergent news outlets, they also let users rate content so it is easier to filter even further.

100 words is enough to know whether I want to know more. Its great for mobile devices too. Its also a fascinating model for content collection and for content creation. I'm curious to know how many articles the average Brijit writer submits. I bet its a great way for journalists to hone their chops on the micro form. A medium that is likely to take hold in a myriad forms.

The information overload we're all faced with requires better filters and fewer sources. Innovations in news aggregation have heretofore offered us some great ways to get more news from fewer places. Some have also offered us user filtered and rated news. In fact, sites like slashdot and digg have defacto summaries already in place since the submitter includes a summary or headline when they post. But this site actually pays writers for quality summaries. Summaries that are more likely to accurately reflect the intent of the article - rather than a snide comment or personal injection in the summary. It also specifies the articles it wants summarized. So, there's a very interesting hybrid of top-down editorial discretion and bottom-up rating system in play here.

A well-written 100 word article is as much information as the average radio summary and often more than a television story. The truth is, this is not that different from what the media already does... slice and dice news from the wire into your own format and your own voice. But the scale of something like this is massive. I see that there are a variety of digests to select from - on specific topics or from specific publications but I wonder also, if this model would be even better if divided up and focused on more specific niches. This might make a great resource for a variety of industries where there is so much innovation and research being published and so little time to consume it all.

I just have to make a short and giddy post. First off: We have some incredible people making Enfuse grow across the board. In a post that now seems a lifetime ago, I had mentioned that we'd had some difficulty keeping the Culture section vibrant - and in that post I discussed some reasons why I thought that was. We made some changes to the organization of the section and the proof is in the pudding. The Culture section is now so vibrant that I just had to modify the home page and the Culture index to give readers better access to new stuff.

Articles were getting posted so fast that they were displacing one another from view and getting buried before they got due traction. So, take a quick look and if you like what you see, thank the editors:

Google is tiptoeing its way into the already crowded wireless market. The once just-a-search company announced that it is leading an industry alliance to transform mobile phones into mobile computers in a move that could accelerate the inevitability of ubiquitous computing.

In a well-timed and related publishing industry announcement Houghton Mifflin has signed with Mobifusion to deliver electronic versions of its books to cell phones. Joining publishers such as Avalon and Simon & Schuster. Publisher's Weekly writes that Houghton will work with Mobifusion to deliver handheld versions of its books. According to a Houghton spokesperson some titles will include "added functionality." Initially the publisher will focus on generating mobile versions of its reference and children's titles.

Analysts have long speculated that Google would enter the wireless market with free or nearly free phone service supported by SMS Ads, possibly with phones that include a button that directs users to Google's WAP services.

According to The New York Times, "The 34-member Open Handset Alliance, as the group is called, also includes many of the leading makers of mobile phone chips, like Broadcom, Intel, Qualcomm and Texas Instruments, as well as SiRF Technology Holdings, Marvell Technology Group, Nvidia and Synaptics. EBay (which owns the Internet calling service Skype), Nuance Communications, NMS Communications and Wind River Systems are also members of the group."

The software is expected to provide cellular handset manufacturers and wireless operators with capabilities that match and potentially surpass those using smartphone software made by competitors including Apple, Microsoft, Research in Motion (Blackberry) and others. Unlike its competitors, Google plans to release the platform using an Open Source licensing model.

According to Google's director of mobile platforms, Andy Rubin, by releasing the platform as Open Source "We are not building a GPhone; we are enabling 1,000 people to build a GPhone."

With more publishers delivering books to cellphones and Google making a strong push to digitize books, it will be interesting to see what Google's mobile platform includes for making the reading experience more enjoyable.

An open mobile platform supported by a goliath such as Google could lead to other fascinating off-shoots in the realms of ubiquitous computing and in digital reading. Using the platform, developers and hardware engineers will inevitably invent non-cellphone related products that utilize the networks and / or other functions available in the platform. The potential offshoot technologies may very well become entirely new industries in their own right. The innovation potential makes my mind reel. Multimedia podcasts with full text pushed directly to cellphones are so yesterday. How about a handheld real-time self-publishing direct to subscriber matrix for writers and readers on the go?

It feels like we're getting closer and closer to experiencing the digital revolution for books that we saw in music. Let's just hope that the technologists, the artists and the copyright holders have learned some important lessons so that it can become more of a collaborative and supportive relationship. Played right, everyone can benefit - even the authors.

Publisher's Weekly reports that Hachette Book Group USA has announced that it is planning to adopt the International Digital Publishing Forum's new file format standard for e-books, making it the first trade publisher to adopt the standard. The IDPF announced the adoption of the Open Publication Structure 2.0 and its ".epub" file format standard in September. The new standard is expected to cut costs and increase the number of e-books because it allows publishers to create one digital book file instead of the six to 10 file formats previously required.

According to IDPF, ".epub" is the file extension of an XML format for reflowable digital books and publications. ".epub" is composed of three open standards, the Open Publication Structure (OPS), Open Packaging Format (OPF) and Open Container Format (OCF), produced by the IDPF.

What's so exciting about that? When industry leaders adopt open standards it is an indicator that there is a maturation process happening that will allow for interoperability between hardware and software for E-Book readers, browsers, etc... It will make it feasible for vendors to create viable products for the market which will have the capability to read content from a variety of publishers. As IDPF puts its: ".epub" allows publishers to produce and send a single digital publication file through distribution and offers consumers interoperability between software/hardware for unencrypted reflowable digital books and other publications.

Further, because it is an open standard, it can be used by small and large publishers alike without having to pay royalties for a restrictive patent. This will also better enable the development of open source publishing tools and E-Book readers.

For you techies, it should be enough to say - it's XML. You can write it and read it using any tool at your disposal. Its open. Its free! Free like free beer! All you need is content, good ideas and an implementation strategy. Stamp the penguin on it and build that POD E(x)presso Machine.

The last couple weeks I've taken a fairly wide detour out to the Facebook Platform. I was intrigued by the idea of a social network that lets other developers write applications to enhance it. It's a notion that we've bounced around ourselves - facilitating a platform that allows developers to distribute tools for photographers, bands, artists, and so on. So, I was interested to see how the facebook model worked. Of course, I'm also always interested in building modules that help spread Enfuse's reach through the "distributed" and "embedded" web.

Inevitably, building an app that is actually useful in a social context, that is viral and interesting - and that preserves the integrity with which we want to represent the content our users have entrusted us with takes time. Scope can tend to creep quickly. That, plus a few technical problems such as unpredictable session expiration, trouble with FBML (as compared to iFrame) based Canvas Pages, mediocre (at best) documentation and very few Cold Fusion - based implementations to learn from all swallowed a lot more time than I had anticipated.

Note: I did find a few Cold Fusion resources, notably Facebook Rest Client CFC v1.0 by Andrew Duckett and some sample get and setFBML functions by Cory Johnson did help. It turns out that Cory also had trouble with FBML based Canvas pages and I'm curious to know whether he ever worked that out, and if so, how. Cory, if you're listening...give me a holler.

One such 'aha' moment came when I understood the difference between coding for the canvas vs. the profile page. In truth, the profile page mostly houses FBML which is set in place using the API. Most of the work is done on the Canvas page which can be more or less independent. Of course, any activity on the Canvas can be used to generate FBML to the profile - but once set, the profile FBML the requires an application setFBML call to be updated. The markup on the profile can also be changed independently of user action by using an infinite session and a Chron Job on your application's server. Meanwhile, the Canvas can be as dynamic as you can build it - especially in an iFrame - within the limitations of the Framework.

A few key lessons I learned were to limit the necessary trips between the two servers - to limit what I needed to get from Facebook to as little as possible and to get as much as I could up front rather than to make numerous requests throughout the flow of the application. This meant doing a lot more client side by storing data in JSON objects, using more JQuery, Flash and Javascript interface elements and tuning the interface to as few pages (requests) as possible. Additionally, it is very useful to know which API calls allow "Infinite Sessions" - keys which can be stored at the application level as compared to request based session keys with unpredictable and sometimes very short lived authorizations. Assuming you want to build it taking into account the few users who may not want to allow the application to stay logged in (a default option).

A site that offered some other tips on Facebook "Gotchas" was a resource I read more than once. In fact, the quality of the documentation had me reading just about everything over and over again, trying things several times before it would click.

We're now in Beta on ArtFusion - an application that lets users rate, keyword, comment on a different piece of art a day and provides reports and search capabilities on previous artwork and a new interface to other featured art by the rated artists. At its core it is based on the "Art of the Day" Google Gadget we built a while back - but as a social utility. Contact me if you're interested in trying it out before its released to the Facebook base.

Over the long run, my hope is that a well-tagged, user-rated art database will really help potential buyers browse and purchase. Only a few changes will be required to roll all the functionality of ArtFusion back in Enfuse and integrate it into the Google Gadget as well.

WTF? ADHD is the future of the web. It is, after all the hallmark of our generation. But, the decentralized web is just as much a sign of our times. Short form articles, short videos, notes, microcontent of all types is quickly displacing the 7" - 12" article of yester-year.

On a side note: this all reminds me of my interview years ago for a job working on the web team at the Rocky Mountain News and how my radio experience would help in converting print content for Web... we've been heading towards micro-content for a long time...I just wonder how tiny our attention will become before we start craving long form media again.

This article by Steve Rubel is a bite size look at the future of web content for the ubiquitous computing, embedded widget, web - service generation of web applications.

Its an important reminder that as we look to build new functionality into Enfuse, and continue to generate content and content presentation vehicles, we need to look at making it embeddable, modular, and port[let]able. We can be sure that more and more users will be embedding their Enfuse slide show onto their own site, reading our articles on some desktop widget rather than at our site, and will be innovating other clever ways to interact with us, whether that be through Web Services, third party gadgets, or something entirely different.

This distributed future will also inevitably impact advertising opportunities. Either content providers will embed advertising into their syndications, or they will need to come up with another option for monetizing their feeds, APIs and Web Services.

If anything, Rubel's article only strengthens my resolve that we're on the right track with our concept of branded sites, content distribution services, etc... It does make me want to keep each service, and our content as a whole, well modularized.

We've had trouble over the years with the Culture section. It was a section that burned editors up. Somebody would step in and crank out a ton of work, but there was just too much to stay on top of. We have always known that the content model for the culture section was challenging in comparison to Features - because features are a vehicle of promotion for the artist while reviews, columns, etc... are more of a writing exercise. So, good content is difficult to get for free. Thus, we're still looking at payment models for our culture content contributors including gift certificates from retailers (in exchange for advertising) and payment for syndication to branded sites...

But, there has been a larger issue that we just hadn't identified. Culture is a broad subject. An editor might have a strong sense of the music scene, or literature, or film... but trying to stay on top of all those areas of interest, that's just not realistic.

So, a couple months ago... as a result of a comment made by an outgoing editor - we decided to rework it. We broke the section up into "Topics" managed by (you guessed it) "Topic Managers" who focused on specific areas. We threw away the concept of an overarching culture editor all together, and instead focused on building strong topics and integrating the topics with their corresponding feature sections. So - Music Reviews worked closely with Music Features, Books with Literature. The result has been incredibly positive. We've gone from struggling to get a single new review per month to publishing 3 - 5 reviews per topic per month. We've even added topics that we didn't have before - such as Restaurant Reviews, Fashion and Design and have true "Columns".

Who do we have to thank for this:

• Laura Olson - Books
• Nathan Olson - Music
• Shawn Stufflebeam - Columns
• Mark Flanagan - Design
• Jessica Cox - Fashion

Why? The reason, I think, can be attributed to a few things.

1. People get overwhelmed when there's too much choice and too much to do.
2. Focusing on what you care about is fulfilling, everything else is work.
3. Poorly defined expectations and open-ended forums don't offer direction. Clear definitions help people focus.

All that said, we are now considering bringing on a new editor to bring the topic managers together. Hopefully, the role of Culture Editor will seem more manageable under the new model. Stay tuned for details on who our new Culture Editor will be...