+5
Started

Moving the "Save" and "Cancel" buttons in the asset creation window

Nick 9 years ago updated by Christine Masters 6 years ago 20
We've had several times when reporters are writing stories and they accidentally move the mouse a half an inch too far and click "Cancel" when they meant to click "Save." I know in this tech savvy world they should know to save, but at the same time auto-save exists in other programs and so they're used to the system saving for them. I think an easy fix(I changed it in the in-browser CSS code in about 15 seconds) to this would be to move the "Save" button and the "Cancel" button a few inches apart.

That's the easy way. I think another thing that would help this issue would be to add a "Are you sure you want to cancel?" prompt if the "Cancel" is clicked and the asset hasn't been saved in a while.

I know TownNews is proud of its in-browser asset creation, but I think the majority of the reporters here have been burned too many times and just write in a word processor, then copy and paste it in TCMS.
+1
I like the "Are you sure..." option Nick.

You're absolutely right on the copy/paste. Except in breaking news situations our staff doesn't write inside the BLOX window.
+1
one of our remote locations were writing in word/text editors and not in IQue (competing editorial web product) and would paste into IQue when the story was done. So the editor could keep up with works in progress, all of these were saved to a shared directory on one of the workstations ... When the hard drive on the workstation failed all current work in progress was lost... Data on servers is backed up but not data on workstations. Everything the location was working on (items for the next several days papers, and upcoming special publications) was lost.

Bypass your companies official workflow at your own risk.
+2
Not sure I like moving buttons that people are used to... But a "You have unsaved changes" warning with a "Save and close" "Close - lose changes" and cancel options is probably a good idea.
Under review
Actually, we have a feature on the roadmap that I think would solve this problem. We have been discussing a feature that saves the file every few minutes (or, maybe, seconds, I'm not sure). If you accidentally deleted your data, you would be able to go back to the page and "restore" the unsaved work.

Doesn't that sound like a good solution?

Have there been any updates with this? I ask because I heard someone cursing the BLOX gods from across the newsroom.

This is actually about the in-browser asset editor, not in InDesign. Would this auto-save work in the web browser asset editor?
+1
Yes, my understanding of the idea is that auto-save to work in the BLOX text editor for articles - which means it would eventually work on both Total CMS and BLOX hosted CMS. We're still speccing out the requirements though.
Awesome! If you do that you'll be a hero in our newsroom.
My only concern is if we are working on breaking news (which would have an immediate publish date/time) we wouldn't want it to go live while typing mid paragraph...
That's a good point. Do you use workflows with all of your stories? We have a workflow that doesn't give an asset a site tag until it is promoted to a certain workflow stage. So you could adopt that as a procedure. Only when you're ready for a story to go live do you promote it and it gets a site tag.
I think workflows are part of total cms and not just hosted cms...
I can envision ways it would still work,,, for example we don't use site tags but if the reporter or editor doing the entry doesn't assign a section tag then it wont show up on site...

Alternately the autosave function could create a "draft" asset which isn't live until a human hits "Save and Publish" or something similar...
In the breaking news example the reporter could enter Police Stand-Off at 9th and Walnut as a headline, add breaking news section... hit save and publish and the headline shows up in breaking news ticker... He leaves the asset open and types notes in as he's in contact with the field and with the police... During this time every 5 minutes the system saves a "draft." 15 minutes later he composes notes into an initial report and hits save and publish... and the website is updated.
The draft status could be a status flag on the asset... so you could look at the revision history and see the initial "live revision" where the asset was saved, several "draft revisions" where changes were saved but the changes aren't live and the the updated live revision...

The system would always publish the last "live" revision.
keep the last saved version in memory and check for modifications locally... if there are no changes there's no need to send data back and forth to the server...
What we had discussed at our brainstorming meeting is that it would do sort of a behind-the-scenes save that would allow you to "restore" the data in the event of an emergency, but would not be treated as a true revision. So, it is for recovery purposes but wouldn't be an official "save."
cool but a "restore" of the asset needs to be something doable from within the UI. If a reporter is going to have to contact IT or a webeditor who's going to have to submit a ticket and wait on a response... it's not going to happen... they'll go back to typing their articles in word.
Maybe a "there are unsaved edits to this asset. do you want to review them?" prompt when the asset is opened
Yep that's exactly what we were thinking! :)
+1

Has this moved any on the roadmap? I think the auto-save would be nice, but what if the asset has never been saved the first time. I realize saving early is something everyone should do, but for a lot of people this just doesn't happen. For whatever reason they don't save right after creating the asset. So would this update auto save all created assets regardless of whether they've been manually saved in the first place?

+1

I saw the update from August that adds an auto-save feature of sorts to BLOXCMS. This is a step in the right direction for preventing articles from being lost. I think a bigger concern of ours remains the cancel button. Can the cancel button not be given the same exact function and prompt of the close/X button?


screencapture.mp4

I agree, cancel should get the same warning as the X.