+1
Under review

Feature Request: Prevent the Start Date/Time from being changed after an asset publishes

Kevin M. Cox 8 years ago in BLOX Total CMS updated by OA Ben Adams 8 years ago 14

I'll start by saying this is a request I shouldn't even need to make, but I have users who simply cannot understand the impact of changing the Start Time of an article after it has already been published online (e.g. 404 errors for readers following links from social media).


• I'd like an option to have the Start Date/Time of an asset frozen in TotalCMS, once the article has a Site Tag and that time has passed (meaning it has published online).


This would function exactly like the Start Date does in Banner Ads:


Image 228


This would prevent the accidental removal of an article from the website by users who don't understand exactly how it works. However the Do Not Publish checkbox would still be available for emergency situations when something needs to be taken down, but would require a much more conscious effort to engage.


What do y'all think? I can't be the only one who has face this problem.

Under review

Hey Kevin, Can you give me some use cases of what they're trying to do? They just want to take it offline but don't know how?

No, they're taking it offline without realizing it by futzing around with the Start Time. They simply can't grasp the relationship between the Start Time, Site Tag and TCMS workflows that give it the Site Tag.


I'm looking for a way to keep something online after it gets there in almost all cases (with the DNP box being the big override).


For example just the other day we had a big story that had over 10K link clicks on Facebook of people coming to read the article. However they ended up pulling it offline in the evening while messing around with the Start Time.


I can think of very few cases that an article should be unpublished from the website once getting there, especially after it has been shared on social media for 12 hours. Directing readers to a 404 error is only going to lead to frustration and bounces.


Since the Banner Ads area already has this same functionality I was hoping it might be easy to implement inside Editorial as well.

From a technical UI coding perspective, it would probably be easy... but I am just trying to make sure that there are no unintended consequences from such a change. There may be people who have legitimate use cases for changing the start date.


So, to clarify, your users are not trying to do anything specific, they are just accidentally changing the start time?

This is definitely why I'd see it as a site configurable option. That said, I can't think of any legit reasons to change it after it has gone "reader visible" since in essence it is deceiving the readers about when something was first published.


My users are trying to "arrange" things on the site (because they want to treat the internet like a printed page that remains in a static state for 24 hours). But I digress...


I've given them legitimate ways to do what they want such as the Top Story Flag pinning an article to the top of the front page and email newsletters (what they accomplished in my above example by changing the Start Time into the future). But I'm loosing the battle on the technical comprehension side of the equation and they see it as easier to just change the start time with no understanding of the consequences.


And so as I said in my OP, I've come here seeking a technical solution for something that in reality should only require user training. But I figured there is a good chance it could help other newspapers with less tech-savvy users working in the system as well.

I don't think it's TownNews's job to regulate the ethics of how sites use the start time field. Some may want to change the start times to get readers thinking things are new, and that's their business.


That said, a lock feature on the start times would be useful, but it would need to be unlockable by a user with a high enough set of permissions.

Michael I agree, I see this as totally optional and controllable at each site.


That said, I'd throw a pile of money at this feature right now if it would help get it implemented because of how much headache it would save me.

Hey Kevin,


The reason I asked about the use case was because we're working on a few things related to how assets show up in blocks. These are still being defined a bit, and the ideas may change slightly depending on how it is implemented, but in general:


- You would be able to pin a story to any spot in the list of stories.

- You would be able to drag any naturally-appearing story in the grid and it would become pinned.

- And, you would be able to add things to a block while in the asset editor.


So, I would hope that those items may help alleviate the need for the start time changes, perhaps - since you could still have the start/date time order, but if you wanted to change something, you could.


Do you think that would work for you?


That being said, I think it is reasonable to have date changes possibly behind a permission that could be removed (a permission would make it an optional thing)... We do have "modify assets" as a permission now, but I assume these are your editors so it is their job to move things around, rather than reporters who shouldn't be doing it?


Anyway, since we're talking about throwing piles of money around ;), I'll ask our dev team to see what possibilities there may be.

That could work, if I can get the reports and editors to actually do it. I've already created a "Top Story" block that lets them float an article to the top of the homepage by simply selecting that flag. However they still would rather go in and mess with the Start Times each day.


Any sort of easy to use controls, available from the TCMS asset editor (not Design/Blocks), could help and are something worth adding to the system even if they don't fix the problems I have here.

Worth mentioning: I'm constantly fudging start times, not to fool readers (if only they were that easy...) but to fool our site - making sure our best stuff is in the best spot for the daypart. It's often easiest for me to cheat a start time and boost something back up into our lede elements rather than, say, pin it somewhere.

+1

I actually see it happening the opposite here of how you say it happens at your site. Typically people create an article, say March 22, but it doesn't actually publish until March 29. But they don't change the date. So by the time it is promoted to the web it's buried behind all the more current stories and I have to go in(when I catch these) and update the start date/time. I think restricting someone from changing the start date/time would create more problems that it would solve.

Oh we have that problem as well Nick, but at least in those cases the story is actually online and links pushed out via Social Broadcast work and don't result in a 404 page.


We're all got different use cases, so the ability to enable or disable this functionality would be required.

I don't think locking the start date and times is a good idea. Maybe there is a better way to do this, but we have always momentarily back-dated most advance stories by about a month or two in order to get a live link for scheduling on Facebook, then immediately change the date to the correct future publish time. Locking the date, or making changing it by permission would make this more of a hassle or next to impossible. Our workflow depends on this ability. If there is a better way for us to get live links please share, but even so I would not like to see start date and times locked this way.

Ben, any objection to this being an optional feature that you can simply leave unused at your site but I can have at mine?

If it were an optional feature that could be enabled or disabled by the admin, that would be fine.