Questions
Anyone have any suggestions on how to best handle quickly-updating stories?
So let me pose this scenario:
We've got a story on our the site. Let's say the New Orleans Saints are making roster cuts on deadline day. Our guys are updating their story w/ new player names every couple of minutes. The story tells readers to 'check back frequently' or 'reload the page' for the latest info. How can we best display this info in BLOX so that people who visit a page frequently during a breaking story actually see the most up-to-date info?
Answer
I've found no elegant way of doing this. We just add content to the bottom of an asset and say something like ...
UPDATE 1:30 p.m.
The ideal approach would be a new type of asset completely(ie, not just an article). One that you input content for each update and the system marks the update time. It wouldn't be something we would use every day but boy would it be useful for those local emergency situations. Maybe a "Live Update" asset or something.
So we would definitely use something like this.
Right now BLOX basically says newsrooms can only update stories once every 5 minutes -- IF you want everyone who clicks the story to see the latest content, regardless of when they last loaded the article. In breaking news situations, that doesn't cut. I've seen us update a stories 5 times in 5 minutes. While I appreciate BLOX's caching system to keep sites up and running, I'd love a happy medium.
I dont think 5 minutes is accurate. I have been doing active updates on city council meetings and have moved onto topics three times before it shows up on the page.
Had to resort to Twitter instead of the CMS to get accurate, fast updates on the site.
I like the idea of a specific type of asset that forces the cache to refresh more frequently.
Alternatively maybe a flag like "Breaking" that doesn't do all the other things that particular one does for most sites.
We're in the midst of a hurricane and it would be great to have some form of live update asset to get info out there marking the time of each update.
My (usually limited, occasional just wrong) understanding is that anything flagged 'breaking' isn't cached, but TN put a warning in the docs saying 'don't push it or we'll make all your breaking news cache.
I've also gotten around the cache it via use of an HTML asset with dynamically generated content inside it.
Here is the doc which discusses how you can use flags to reduce caching times for important articles:
As the doc says, there are a few limitations, but in general you'll get updates about every minute or so.
However! Note that this does not affect the users' local browser cache. That is still subject to a 5-minute cache. (You could, if you could find the right words, tell users to force reload the page. It is different in different browsers though, so I'm not sure if there could be an elegant way to say this.)
So this doesn't really work for "live blogging" - but it should address the needs of corrections and story updates and breaking news that you want to push to the front page.
We did have a discussion internally today about some enhancements we can make to bring us closer to having some kind of live blogging environment... I will look into that as a possible future feature.
Bumping this discussion. I've seen other CMS allow editors to bust cache on an individual asset level. Would be cool to have a feature like that in BLOX. Scribble Live just jumped in price for us, but we can't get rid of that service as long as article pages are cached like this.
The system actually attempts to purge the server cache of an editorial asset page (not index or front pages) if it is saved and is recent (in the last 24 hours) - this happens every time it is saved and is independent of using any flags. The editorial page must be an article, collection, or video. There is still a throttle in play and browsers are still instructed to use the cache copy for 5 minutes. You should be able to manually force a refresh with shift-refresh.
A change we have considered is reducing the public cache TTL to a minute for assets less than 24 hours as well so that the browser will ask more often if the server copy has been updated rather than waiting a whole 5 minutes regardless of when it was fetched.
Thanks, Patrick. I think the idea is definitely a step in the right direction from a publisher standpoint. When the Saints cut their roster down in the offseason I have guys who need to update their story maybe 20 times in 15 minutes. Having the cache there necessitates the use of a tool like scribblelive.
We've been experiencing difficulties in publishing livestreams in a timely fashion. Often, a news conference is scheduled to begin at a particular time, but officials are typically late. When we publish the livestream 10 minutes early (so we can clear the cache), we might have an additional 15 minutes of an empty podium waiting for the officials to arrive... our users give up and drop the livestream.
We'd like the ability to break the cache on things like this so that we can publish the livestream quickly (when the news conference actually begins), send out a push notification, and keep our viewers engaged.
We've tried using the 'breaking news' flag idea, but apparently that has restrictions on when the asset is created. We typically use an unpublished template asset that we've previously created in the CMS - duplicate it, rename it, and we're ready to go. So the flag idea isn't working. If breaking the cache were dependent upon the asset 'modify' time or 'start' time, this would likely work for us.
Just make a live blog asset type and implement cometd from Apache and setup a streaming topic and let end viewers subscribe to the updates until the live stream is over. There will be size limits for the updates and if larger they will need to republish which could send a bit of JavaScript to tell the browser window to do so. Pass the event ID as a parameter to break the cache and tell the listener what event to pick up from. They can get the cached database version to start on initial load and then replay everything since the last refresh time. When it is all over the topic is discarded and the page moves to a static article type asset. No hard hits against the server just some little udp size packets streamed for a few minutes to a few hours as content is loaded. Numerous live blogging platforms can do this, so can you. It seems nearly all your customers want it.
Customer support service by UserEcho
Here is the doc which discusses how you can use flags to reduce caching times for important articles:
http://help.bloxcms.com/knowledge-base/applications/design/blocks/block-library/article_d2b122f4-f038-11e4-a844-ff7a130047bb.html
As the doc says, there are a few limitations, but in general you'll get updates about every minute or so.
However! Note that this does not affect the users' local browser cache. That is still subject to a 5-minute cache. (You could, if you could find the right words, tell users to force reload the page. It is different in different browsers though, so I'm not sure if there could be an elegant way to say this.)
So this doesn't really work for "live blogging" - but it should address the needs of corrections and story updates and breaking news that you want to push to the front page.
We did have a discussion internally today about some enhancements we can make to bring us closer to having some kind of live blogging environment... I will look into that as a possible future feature.