This was our initial question regarding a concept we call DOMcasting, a not-so-clever term used to describe an html two-way broadcasting technology. DOM, or Document Object Model, is meant to be an obvious reference to the display of the html/xml/xhtml within the browser. Broadcasting is a reference to the location of our data/content, as well as a temporal reference.
DOMcasting considers both space and time. Imagine this scenario for Live Television Broadcasting. Three individuals—Joe, Jane, and Mary—all want to watch the presidential inauguration LIVE. In order to do so, they must all tune in to the same channel at the same time. The effect is the same regardless of their physical location—they’re all watching the same broadcast at the same time.
How DOMcasting works:
So the concept was great. We just needed to figure out how to build it for the web. With television, you have a singular source of the content. Continuing with the Presidential Inauguration example there's a video camera physically present on site, pumping bits of data through a series of fancy machines, antennas and paths until the bits are displayed on a specific screen. This model doesn't work for web because you don't have a singular source of content. Sure, the server is where the data resides and where all good data must pass, but when you consider the geographical source of the data (or content) it is with the user—the server is simply a conduit.
This understanding led to our breakthrough. What if we swapped the traditional web roles of Client (think browser) and Server? So we tried it. It worked. And in a late night bout of low originality we named it FLOW.
How FLOW works:
With FLOW, our proprietary DOMcasting technology, the Client takes on the primary role of html document construction. In the past, this was the Servers job. The Server's primary role now becomes the proxy (we like to think of it as a repeater antenna) that supports the live broadcasting mechanism. The result is capability for an infinite number of users to be viewing the same html document at the same time, while also allowing the users to MODIFY the html document. Of course this is a bit over-simplified, but hopefully you get the point.
Client (Browser) = Content Engine
Server = Proxy (Broadcasting)
Our current product, Black Tonic, is a real-time, browser-based presentation management and broadcasting tool built with FLOW. Everything happens via html and nothing more. The “catch” with Black Tonic is—in order to allow for a controlled presentation—the user experiences a one-way broadcasting much like our television example above. Under the hood, however, all the 2-way mechanisms are in place allowing for some sophisticated feedback within the application to seamlessly connect the Presenter and the Audience via a browser.
A new Experience, coming soon to a Browser near you:
FLOW is not the only nascent example of DOMcasting. We're guessing you are somewhat aware of Google Wave and the broadcasting capabilities of html 5. We see DOMcasting arriving in full force soon, so we can't finish this article without asking an obvious question, "What does this mean for the future of the web and user experience?".
We see the short answer as this: Real-Time Conversation. We are witnessing the birth of the next stage of Web. For now we call it Experience Sharing (or XS). You can read more about our thoughts regarding XS here.
