+3
Answered

Anyone have any suggestions on how to best handle quickly-updating stories?

Kyle Whitfield 1 year ago in BLOX CMS • updated 4 weeks ago 10

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

Answer
Answered

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.

+2

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.

+2

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.

+1

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.

+1

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.


Answer
Answered

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.

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.