Saturday, January 31, 2009
Real-time updating at KUAM
As we at KUAM make a big push to support and move towards delivering real-time online experiences (web, mobile, desktop, e-mail, RSS, SMS, widget, RIA, IM, etc.) one thing I'm having to reassess is our publishing philosophy. We've evolved from putting news online after-the-fact a decade ago to mirroring our on-air/online content at the same time (synchronous publishing) 5 years back, to now running stories hours before our 6pm newscasts air.
So as we embrace platforms that deliver our items immediately via XMPP, SUP and intelligent AJAX polling as they're published, I'm rethinking how we batch-process stories. At the moment we usually run non-breaking items in groups of 2-5 stories per batch, making the most significant piece the cover story on our site for that cycle. This appeases our followers on Twitter, whose clients repeatedly poll for new updates. But as we inch closer to true real-time, such a load becomes intrusive to impose on the instant messaging/text messaging crowds.
So as we embrace platforms that deliver our items immediately via XMPP, SUP and intelligent AJAX polling as they're published, I'm rethinking how we batch-process stories. At the moment we usually run non-breaking items in groups of 2-5 stories per batch, making the most significant piece the cover story on our site for that cycle. This appeases our followers on Twitter, whose clients repeatedly poll for new updates. But as we inch closer to true real-time, such a load becomes intrusive to impose on the instant messaging/text messaging crowds.
For example, yesterday my team and I published a total of 27 articles to KUAM.com over a 10-hour period, all completely staggered and not all batched - some were 2 at a time but most went live the moment we wrote them. Today being a weekend, we consolidated our publishing function and ran 11 stories for the day...all were published in a single operation at the same time. With asynchronous RSS aggregators, either format would be fine...but the latter would be a painful batch to push to an IM user - 11 items all at once.
So, we're now adopting a mindset of running items with the former approach: if a news item is good to go, we get it online right away and push it to whatever devices and services are online and listening. Administratively this means a lot more publishing operations, but a lot more IM/SMS updates with smaller payloads and no news queueing (all positive things), and a better overall user experience.
So, we're now adopting a mindset of running items with the former approach: if a news item is good to go, we get it online right away and push it to whatever devices and services are online and listening. Administratively this means a lot more publishing operations, but a lot more IM/SMS updates with smaller payloads and no news queueing (all positive things), and a better overall user experience.
Subscribe to Posts [Atom]
Post a Comment