Ideas
Way to change start date/time to now
We would like a way to quickly and easily change the start date/time to now to accurately reflect when a story is published. I guess that would look like some sort of button or maybe an extra option by the start date/time in the default article asset window.
We work in a competitive market, and when a story is published is often critical for us. Also, we have times when a reporter or editor will create a file in advance of an event and the start date/time does not get changed to more accurately reflect when a story is published. The difference between when an article asset is created and when an article is published is a big one for us and one we don't want to have to explain to readers.
Yes, we can manually change it to get really close, but it would be simpler if there was a one-click way to make that happen. If there is, I've missed it!
Customer support service by UserEcho
When an article is created, the start time is always "now" - within a couple minutes.
But it sounds like you're saying that a reporter creates an article at 9 am (and the start date/time would be 9 am today). During this time it is set to "no publish" status, I assume. Then they start writing it, check with their sources, crunch data, file reports, fact check, talk on the phone while typing and other things reporters do! Then, 3 hours later, they want to publish the article, so they go in and remove the "no publish" status (or, maybe an editor does). But, the publish time says it was published at 9 am, when really it was 12 pm.
Is this an accurate (with some exaggerations about the reporting process perhaps) representation of the user story you are describing?
So, your idea is that, when the story is published, you want the reporter, or an editor, to go back into the story and hit a button that would then change the time to "now" to more accurately reflect the real publish time. But, then that is still relying upon the reporter to go change something, which is part of the problem.
Does all of this sound accurate so far? I have a few ideas about this, but I need to talk to my dev team about it...
Christine, Your description is right on. In some cases, filed are created days ahead of time.
It is sure possible the editor could forget even with a simpler way to update the publish time to "now," but it seems we'd be more likely to do that with less thought and a one-click option. Thanks for the reply.
That sounds like a problem we experience as well from time to time. Usually the staff is good about "fixing" the Start Time but it doesn't always happen and then the story that just published is buried one week back on the website.
I like the idea of a "Now" button near Start Date/Time, but I'd also be interested in the pursuit of a feature that would adjust the start time once an article gets a Site Tag for the first time. Something along the lines of:
When an article is published (DND removed and a Site Tag applied):
• If the Start Date/Time is in the past it will automatically get changed to "Now" (but there obviously needs to be a way to override this for something that is purposefully back-dated).
• If the Start Date/Time is in the future, no changes will to it will be made (because the assumption is this is content being scheduled for the future).
Kevin, Hope all is well. Hey, thanks for the input and for your help before launch! For the process we're trying to make work, I think a better trigger would be when the article hits the step in the workflow process that makes it live on the site, which would be the actual publish date/time. Reporters are adding their own section tags earlier in the process. Of course, that might change!
It's easy to go button crazy. I think I like a button for this because of the deliberateness.
Okay, I spoke with our dev team, and it sounds like we agree with where you two ended up in the conversation... that this sounds like a great workflow step.
So, like Scott described, we would add a new workflow option that says something like, "Reset article start time to current time as part of this workflow transition." (Probably less wordy.) Then, when you hit the point in the workflow where you are putting the story live, you would have that feature trigger and it would then reset the start time.
The thing I like about this is that it does not rely upon editors or reporters to edit the asset to adjust it - rather, it just happens automatically with no extra work!
If you have a situation where you do not want something to be re-set to "now," you could create another workflow for that scenario and not include the "reset time to now" option. Or, in extreme cases, you could go back into the asset and back-date it.
What do you guys think?
Sounds good to me. The only time I might wish we'd gone about it differently would when we're working on something breaking where we might go without a workflow.
Can you make a "breaking news" workflow that basically just has one or two steps, that does a publish and a "reset to now" command?
I created a workflow called "Breaking News." It has two processes, "Ready to Edit" and "Publish." The "Publish" process goes to web. I'm not seeing any option to add a "reset to now" command.
Hi Scott! Sorry for the confusion... "reset to now" would be a feature request. So I was asking hypothetically if, assuming we built this "reset to now" command, it would work for you to create that workflow. I have already gone ahead and submitted this as a feature request, so at this point I'm just making sure it works in all of our user cases.
Gotcha. You were replying to my previous post. Sometimes, I'm a little slow! Yes, something like that would work. Thanks!
For us we use our standard news workflow and just skip ahead steps to get it online right now.
The process Christine described works great for TCMS, but less for Cloud clients. We don't have/use a site tag anymore, and publish stories before they're moved into the next workflow stage. (Reporter creates article. Reporter makes calls, verifies a cat really is stuck in a tree. Reporter publishes story, "Cat stuck in tree," and traffic surges. Editor (and likely a digital editor) hops into story (for different reasons). Reporter updates the story. Videographer adds a rescue video. Reporter updates the story. Editor goes into story one last time and moves it to the next workflow stage, which is where print production starts taking over versus web production.)
So I was really excited this feature came to fruition in the latest release of TotalCMS.
This addresses the situations where reporters start a story on TotalCMS in advance, and then three days later it is finished and published. Unless the reporter remembers to go back and change the start date, then it ends up the "publish date" is actually three days ago - when really that's when it was STARTED, but not when it was PUBLISHED. This new workflow option allows you to set the asset start date/time to the current time when the asset reaches that process stage. Please keep in mind that if you want an asset to start in the future, this option will affect those assets just as it will assets with a start date/time earlier than the current time.
Unfortunately we can't use it because as implemented it doesn't allow us to purposefully schedule articles in advance.
This was so close but then fell short. The behavior needs to only apply to assets with a Start Time in the past (not changing anything with a Start Time in the future). Exactly like I suggested here back on March 9, 2018:
This does a great job of fixing the issue discussed here but then breaks other workflows.
I agree with the other Kevin. We schedule stories in advance of online publishing to spread out our content. So, those future start dates should remain unchanged, but a date the is still in the past should be updated to now. Because of that, I don't use the "Reset Start Time" feature. It breaks our workflow. Our situation may be somewhat unique, since we are a smaller operation. But, I think others have similar situations. From what I'm reading, that weak could be made without bothering folks who are already using the feature.
Hallelujah!
Now I've just gotta wait for it to trickle down to TotalCMS.