bite size tech has moved...

http://bitesizetech.wordpress.com

Publishing at the Speed of Real Time

Obsessed with Speed
We are obsessed with speed and the desire to make and do things faster. Simple examples abound: faster humans (~27mph Usain Bolt), faster machines (257 mph SSC Ultimate Aero), faster networks. Speed is a primary measure of success. Faster means better.

 In publishing speed can have many meanings. I use it to refer to three aspects of publishing. How quickly can I move content from author to consumer (e.g. a journal article X), how many authored content(e.g. 1000 copies of journal article X) can I distribute over a period of time, and how many different authors’ content can I move simultaneously (e.g. 1000 copies of journal articles X, Y, and Z).

If we look at the classic printing press someone who is not an expert in the field can see where we will run into problems. There are physical limits to how many times we can print the same page. If we need to print more copies we need more time. And we can forget about printing a different article at the same time, we would need to add another printing press. Even if we could print that paper faster, to really increase the speed of publishing we would need to speed up the entire process, we need to move the printed paper to the consumer. The physical limits are fairly obvious.

Now take a common example of digital publishing, the blog. Using technology that is easily available I can make those problems go away. When I publish a blog it is available within seconds to anyone that wants to read it. I can distribute my content to anyone with a network connection. I can reach millions of people with that single click of the publish button.  If I have multiple pieces I want to publish at the same time I am limited only by the number of times I can click the publish button.  As quickly as I can write I can publish. We are pushing against the ultimate speed of publishing: real-time. As fast as an author can produce content it can be available for consumers.

So what happens when we push ourselves towards real time publishing? What happens when consumers are pulling on us to publish in real-time? What happens when speed becomes the key measures of success?

What Happens When We Speed Things Up?
Things Break! 
The first thing that happens when we speed up is that things break! If I push my printing press faster than it can mechanically work it will physically break. A more subtle form of breaking can be seen on the consumer side. If I expect content like news, journals, magazines, and books to be available on all of my digital devices but I have to go to a bookstore to purchase a bound paper copy of a book I want the process looks broken to me.

The pressure created when we speed things up, whether coming from the producer or the consumer, creates opportunities for new mechanisms, processes, and participants. New participants have ushered in popular new models for publishing like Blogs, Twitter, and Facebook, all of which support real-time publishing. This is putting pressure on existing processes and mechanisms. It has changed what we need to do on the production side while also shifting the expectations of the consumer.

When old mechanisms break it doesn’t mean they go away. It just means they can’t support the demands of new ways of doing things. Printing presses are not going to disappear, but if we look at the volume of published material in the world they will play a smaller role as compared to PDFs, blogs, and Twitter.

And keep in mind the new models can and will break, it’s just a matter of time. Blogs are about 10 years old years old. Twitter is only 3 years old. The new tools that will break these models probably already exist. The question is not what to do if the model breaks again but what to do when it breaks again.

Everything is Closer
When we move faster, we are shrinking the distance between two points. A fundamental shift in distance changes our accessibility patterns which in turn impacts the world around us. In Japan the first high speed rail line was opened in 1964. An estimated 400 million hours are saved annually. One city, Kakegawa City, opened a station in 1988. Over a six year period industrial employment jumped from 88.8% to 106.9%. While less easily measured, it is believed that those in Kakegawa City enjoy a better life because they have access to broader cultural resources. And while not as widely discussed, one can imagine that other areas that were once prosperous due to proximity to a traditional rail line suffered as focus shifted to the high speed rail line.

When the speed of publishing increases, the distance between the producer and the consumer shrinks.  The obvious result is that there is less time between when content is created and when it can be consumed. When the folks at Engadget are following the latest Apple event they are publishing stories directly from the event. A more subtle aspect of this is that in order to publish in real-time we don’t just use new technology; we change our process.

In a simplified publishing model there are discrete steps and people involved in the publishing process: author, editorial, design, printing, distribution, retail. With real-time publishing it is not just the technology enabling real time distribution, it is a shift in the process. The emphasis is on creating the content and expedient delivery. The author is the editor, design is a pre-developed template, printing is simply sending bits, distribution, and retail are URLs. We gain immediacy but lose the attention to detail that individuals in the process provided.

Another effect of reducing the distance between author and consumer is that the original content is only half the story. The other half is provided by feedback from the consumer. The response from a reader might be more important than the original content. What once might have been a private exchange between author and reader over the course of weeks is now a public exchange that happens in minutes. Publishing is moving from a one way statement to an ongoing group conversation.

The author and consumer are so close that the line between them is blurred. Where does a publisher draw the content line?


Losing Control
As speed increases we lose control. I grew up with the Wide World of Sports every Sunday. I will never forget the image from their opening segment of a skier losing control and literally flying over a judging stand. Another example, although more fantastical, is Mickey Mouse as the sorcerer’s apprentice. Thinking he can speed his chores up a bit he loses control over the very brooms he created to help him. This always reminds me of the viral power of a network. The problem is we don’t have a master sorcerer to set things straight when they get out of control as they did in Fantasia.

There are two areas in particular that underscore and enable this loss of control. The first area is access to publishing tools. The tools that define real time publishing are available free of charge to anyone. An individual can be the writer, editor, and distributor in the time it takes to sign up for a web service. The second area is control over content. Individuals can share digital content with the click of a button. Although there are new efforts to control content once it is placed in the digital wild, there are no effective tools to control content once it is public. This is similar to the advent of desktop publishing but with a far greater magnitude.

Real-time publishing changes the nature of publishing content. How does a publisher manage control in a world where anyone can publish and sharing content is a matter of a few mouse clicks?

Now What?
Real time publishing is changing the nature of publishing. Our existing authoring and distribution models are cracking under the pressure, failing to meet the demands of publishers and consumers. The definition of content and publishing is changing from a statement to an ongoing conversation. The content that is published online is free for the taking.

What do we do when the publishing tools and processes we rely on are no longer effective? What do we do when the definition of content shifts under our feet? How do we control content in an environment where we inherently have no control?



While there is a lot of warranted fear and uncertainty, there are publishers that are embracing these changes and rolling along with the waves. Next I'll highlight examples that I believe are showing us how to survive these changes.

Is the Cloud Timeshares All Over Again?

I recently heard a much heralded analyst discussing the cloud. He described how we had seen it all before and that it would never amount to anything, a fad of sorts.

The primary argument was that the cloud is simply a rehash of timeshare systems from the sixties and is therefore not innovative, useful, or relevant. I wasn’t alive then but I was stuck with the legacy through college. It is not the same. There are surface level similarities to be sure. They both rely on a client server relationship. They both rely on shared resources. That’s like saying a Mustang from the sixties is the same as a Tesla from today because they both have four wheels and go fast. The engine may still power the wheels but the driving and maintenance experience is radically different. The cloud is different because it is low cost and seamlessly elastic. The cost of getting started with a cloud service? About the same as a cup of coffee. The steps to expand your cloud footprint? A few clicks, 5 minutes of your time, and another cup of coffee.

He also argued that people need to know where their data physically resides. Without that critical information he believes that public cloud computing is useless for real business.

To kickoff this second round of argument he stated that SaaS is not cloud because the users know where their data is. A significant exemption when arguing that the public facing cloud is not for real business. He went on to note that, in the case of Salesforce.com, it was in a building off of highway 101 in California. I’m not sure that knowing that my data exists in a particular building off a particular highway gives me any sense of comfort. Do they offer visiting hours so that I can take a walk around the data center with my data? Even the administrators would be hard pressed to find the exact disk drive that any particular customer data lives on. And they certainly aren’t going to let me do anything with it. God forbid anything happened while I was visiting my data. “Fire! Quick, grab your data!” Forget the data, I would be busy running and thinking, I hope they’ve replaced their Halon fire suppression systems that have the side effect of killing anything that requires oxygen. No, if I needed a local copy of my data I would probably just batch it from my SaaS vendor.

He furthers this argument with the notion that people really really really want to know where their data is. They want to see the server it is sitting on, they want to see the little green light that says it is on. This is a non-technical person mind you, looking at a green LED, feeling comforted. Quaint. I’m not sure my boss even knows what room to look in to find the server with his data. I don’t know what room to look in and I use some of those servers. I hope someone does. Oh, that’s right, our critical corporate sales and financial data is hosted by a SaaS vendor. What building on 101 is that again?

I do appreciate his perspective but I think his line of reasoning is flawed. I believe the desire to just have things work far outweighs the desire to be able to physically touch and feel the server that data is sitting on. For the hobbyist the transition from that sixties Mustang is going to be tough. They want to pop the hood, swap the spark plugs, change the oil, maybe adjust the throttle. The rest of us just want to drive fast, the less maintenance the better. That translates into less time and less money that I need to invest into my driving experience.

This is what the cloud and SaaS offer, tools that just work. Without any installation, without any cables, without any front loaded expenses, without waiting. It is comparatively less expensive than hosting your own servers. It grows and shrinks with your need and it does it in minutes. Software that just works, is an elastic resource, and I only pay for what I need? That is a new concept.

The Agile Stack

I spent most of this week at the Mark Logic User Conference. One of their slogans is "Agile Content." It's an appropriate phrase. Mark Logic provides an XML repository with an XQuery interface and blazing fast indexes. The beauty of developing applications with Mark Logic is that you can load it up with any content, with or without a schema, and go. Add new types of content, modify existing structures and keep going. Easy to work with, easy to modify, agile.

This was a constant theme from presenters, people experienced building complex applications with Mark Logic. They raved about the flexibility, about iterating, about developing production applications rapidly. They were raving about a technology that naturally enables an agile development process.

Taking this a step further, Dan McCreary is promoting XRX, XForms - REST - XQuery. Dan explains how XRX removes the data impedance mismatch of classic architectures. Forget about OR mapping, in XRX everything is XML. I believe this type of data alignment creates an agile technology stack. But wait, there is more!

What if you had process, tools, and technology that were naturally supportive of an agile development process? Take one part eXtreme Programming, one part wiki documentation, and one part XRX. Blend into Agile Stack. Would there be noticeable benefits? I haven't seen this full stack in action but I have a hunch...

Fragmented Technology

I've been knee deep in my own world of fragmented technology: web servers, XML, iPhones, widgets, treos... the list just keeps growing. And these are just the technologies I use. If you take all of the core technologies used to develop networked applications and all of the applications and devices used to access *those* applications it gets complex really quickly.

In technology there is an idea related to growth and complexity that I consider somewhat classic: As any given layer of technology becomes overly complex to manage, a new layer will be created to manage that complexity. When the new layer is too complex, another layer emerges. Running a business with spreadsheets, then ERP systems, and then EAI is a great example. As our technology becomes saturated, we invent technology to manage or replace our existing technology.

We are seeing this same type of phenomenon on the consumer side with applications and devices. We have more services that we are trying to connect to with more devices. An individual case is not that complex but taken in the aggregate, across all users, devices, and services, we have a lot of technology that inter-operates barely sort of.

Three trends highlight what is happening. Network based service applications are competing to open their API's, internet connectivity from mobile devices has increased 25% annually over the last three years (PEW), and users are consuming streams of data rather than discrete documents updated daily. More applications, increased mobile connections, more data.

Users have more services that are open to access. They can be integrated with other applications and accessed from specialty UI's. Users are increasingly accessing their online services from mobile devices. PEW also noted that mobile access corresponded to a dramatic increase in overall time online. And there are more frequent informational updates to the services they are checking, creating a vicious 'always on' circle. Sounds complex.

In my own circle of technology I have medium access to services from my different devices. My corporate sponsored Treo can access my Outlook contacts, but not my personal contacts. Likewise with email and calendar. One of my personal email accounts has a great mobile interface, the other doesn't. The only way I can 'see' my wife's calendar is to call her on the phone or email her. SMS and IM isn't managed although increasingly I need it to be. I have no way of sharing or managing my Flickr photos or LinkedIn account from my phone unless I am willing to deal with a mobile browser. even on the iPhone, no thanks.

We have fragmented our technology. We use what we can wherever we can. But so far our technology does not appear to be 'Fragment Ready'. Sort of like 'Intel Inside' but externalized. Let me use my technology wherever I want to on whatever device I want to. Then I can stop wading through all of this technology and just use what I need when I need it... until the next wave of inventions.

Devices for Widgets for Devices

I spent the last two weeks on the Pacific coast of Mexico on a beach nestled alongside the jungle. The only "device" available where I was staying was an XM radio. Aside from the inherent fact that some folks consider radio and music the most important, most necessary, form of communication, I was intrigued by the XM radio itself.

It was about the size of a Palm Treo with a small black and white screen. It also had a remote control with even more buttons. The radio physically plugged into an amplifier. So there I was surfing radio stations on a small computer that was communicating with a satellite. The form factor, another device that fits widget sizing, was not lost on me amidst the relaxing environment. In fact, it seemed more pronounced as it fit seamlessly into that world. I didn't *feel* like I was communicating with satellites. I felt like I was using a radio widget on a "device" that was plugged into a stereo system.

When I got back a few days ago I saw a Widgify post that talks about physical widgets. Ricavision has announced a wireless device with a 3.5 inch screen that supports Windows SideShow (widgets). You can attach it to your refrigerator, take notes, and use widgets! Marketing silliness aside, this device makes a lot of sense. When there are devices that are portable, networked, and have applications that I use good things happen.

• the line between "desktop applications" and "widgets" blurs. Would I like a device that travels with me that works equally well as a touch point to my social networks, works with the latest communication mediums (phone, email, IM), a note taker on the road, a contact list manager, a calendar, remote control for my home media center?

• Would I like to be able to access these same applications and associated information in desktop appropriate versions from any computer using a full monitor and keyboard or other enhanced hardware available only on a desktop?

• Would I like to ignore calling plan minutes and have generic data access, using my IP telephony application of choice? Note to phone companies: drop packets not calls.

• Would I like to extend the physical functions of the device through plug-ins and then upgrade the entire device when the same functionality is built in? (satellite radio, cell, keyboard etc...)

There is an argument that there are some devices that are pretty close, and I agree. The iPhone is a great example, supporting a widget environment and smooth wireless capabilities. But it is the vision of one incredible company, still tethered to a closed cell infrastructure and other proprietary standards. Not to mention the fact that it is not seamlessly tied to my desktop applications.

What if we had wireless data connectivity, enough standards to make widgets platform and device compatible, and well thought out widgets and services that bridged that gap between quick portable device based interactions and longer desktop oriented interactions. Looking at the XM radios, Ricavision's device, and the iPhone I see the puzzle coming together albeit under proprietary silos. Here is one person's vote for open hardware and infrastructure, supportable software standards, and well thought out services.

Widget Standards

Over the last couple of weeks there has been a lot of news and blog discussion regarding widget standards. This was due to a requirements draft document being published on July 5th . After reading the blog posts I was a bit confused because I found references to two different but related documents . I found the source material, took a look, and am reporting back with top level information.

There are actually two documents that interested folks should take a look at.

• The first is the widget 1.0 standard. This is fairly slim document, with a lot of known gaps, and a lot of requests for comments. People should comment. I posted to the mailing list about using namespaces. The list is home to other standards discussions, widgets are not the prime focus, be forewarned. This document is from November 2006.
  
• The second document is more interesting because it is packed with the potential of the standard. It is the widget 1.0 standard requirements document. This is the document that was most recently released on July 5th, 2007. These are the requirements for the specification. While it is not close to complete, it is a robust outline identifying areas that need requirements. Reading through this document will get any widget developer thinking in a deeper way about widgets and widget engines, what they need to support, how they will evolve, as well as their current state. Post if you want to help shape your future!
  

A key take away from these documents is that they are focused on desktop widget platforms. This is a mistake. Desktop and webtop widgets share so much in common. In many cases they share the same technology infrastructure down to the scripting language. While desktop platforms can offer greater access to both local and remote functionality, webtop widgets appear to be a viable, and healthy, subset of desktop widgets. Why not make the convergence official and write a specification that will cover all of the widgets from the start?

Another important point is that the technology stack is headed towards web based technology. This appears to be a natural direction of all widget development. However, it does strike me as odd that a potential specification would reference requirements of other specifications that have not yet resulted in effective standardization. I don't have a great answer but it's not hard to foresee a point in time where a widget developer is creating a single widget with a lot of crufty code that is dedicated to allowing it to run in different 'standard' widget engines with differing 'standard' implementations of JavaScript ECMAScript. This is hard enough with the current browser situation, let alone widget platforms and application platforms. Not the fault of specification authors, but a major productivity problem no less.

Don't get me wrong. I am all for a widget specification and will continue to support it and provide comments. In the long run it will help. And I don't offer any specific answers (define a subset of ECMAScript that must be/is already supported?!?). But I am not holding my breath for write once run anywhere. I've seen that movie before, it didn't end so well... or rather it hasn't ended, it just keeps on playing and playing and playing, never quite delivering an ending. I hope the widget standard will bring the environments closer together, so developers can deliver more, and better, products to people who love to use widgets.

widget standard