SNAG file disappears after using "Save As" feature

  • 3
  • Idea
  • Updated 2 years ago
  • (Edited)
I just lost a lot of work because I assumed "Save As" worked as UX always has in the industry over the last several decades: it saves a COPY of the original file, and you still have the original file intact, in its original format.

Snagit appears to be designed not to do that, nor to warn user that it's not doing that. I can't understand why this is so.

My SNAG file in the DataStore vanished after I clicked "Save As" to my image and saved it as a PNG somewhere else. The image is now flattened, ruining any chance of editing my elements. I have no clear way of recovering the SNAG file, which it stole from me. Not in the trash either.

That is not how "Save As" is supposed to work. If I had clicked "Save" then it would've been a fair UX. Save overwrites the original file. Moving that to a new location is fine in that process. But "Save As" should ALWAYS persist the original work in the original format in the original location.

I now have hours of re-work ahead of me. VERY, VERY ANNOYING!
Photo of business

business

  • 11 Posts
  • 5 Reply Likes

Posted 2 years ago

  • 3
Photo of Rick Grunwald

Rick Grunwald

  • 1249 Posts
  • 856 Reply Likes
I think the answer you will get is that the datastore is a temporary holding spot for unsaved files. Therefore save (or save as) is the first time it is being saved somewhere and the copy in the datastore is no longer needed
So go into your editor menu SHARE / SAVE AS PREFERENCES and choose a format to always save in (SNAG works for me) Then operate as normal then save it followed by a "save as" and you will be good to go
Also click the toolbar ; customize then add "Save as" to a handy spot where you can get at it quickly
I hope that helps some
Photo of Manny Carvalho

Manny Carvalho, Champion

  • 1171 Posts
  • 182 Reply Likes
The datastore is a special feature of Snagit that automatically saves captures so that you don't have to.  It is an enhancement to the normal UI which works exactly as expected.  Once you save a file yourself then it no longer needs that automatically saved file because the user saved it.  The datastore is not a backup feature but rather a way to make workflow faster until you are finished with a capture and decide to save it.  Rick has it right.

The datastore has worked this way for years.  When a user saves an edited capture they have to understand the capabilities of that format.  Most are incapable of storing individual edits [that is, vector objects] and so they are flattened.  The .SNAG format is special in that it saves those edits.

I know users sometimes get confused by the editor options but let me point out what the help file says and this is from version 11 in 2013.  It's still true today.

Save Captures or Files that Contain Vector Objects

You do not need to save captures in the Tray that have vector objects when Editor is closed. All vector objects remain in place and can be changed, moved, sized, and deleted when the capture is opened again. However, to use the captures as image files outside of the Editor environment, you must save the captures.

The Tray may also contain media files that have been opened by selecting Snagit Editor > File > Open option or from the Library. If you modify these files with vector objects, you must save or discard the changes before you can close Editor.

Modified files appear with a starburst on the thumbnail. Once the changes are saved, the starburst is removed.

Snagit Capture File Format (SNAG) The SNAG file format is an Editor-only format that retains vector-based objects. If captures or image files containing vector objects are saved as a format other than a SNAG file, the vector objects are flattened and made a permanent part of the image. Once flattened, the vector objects cannot be separated from the image."

(Edited)
Photo of business

business

  • 11 Posts
  • 5 Reply Likes
The issue is not the datastore and what services it provides. It's the naming convention chosen: "Save As" communicates something else to users due its widespread UX when manipulating files. ("Save" is also not at issue.) Simply call it something else and the issue goes away, or warn the user that the image will no longer be in the datastore. Seems an easy make Snagit UX less offensive without having to invest any effort in the datastore engineering.
Photo of Manny Carvalho

Manny Carvalho, Champion

  • 1171 Posts
  • 182 Reply Likes
Ok, but to understand why this happens the features of the datastore are important.  It's temporary storage for unsaved files.  When you save this temporary file then you are storing it permanently in whatever format you decide.  The temporary file then goes away.  It's how it works and really is in concert with the Windows UI.  For example, Word makes temporary files all the time which then disappear but uses the same File As method.  The temporary files in Snagit are just a bit more visible in the editor.

Want the issue to go away? Go into the Editor options and tell it not to automatically save files.  Then it will work exactly as you expect. But you better save your captures before exiting the editor.
Photo of business

business

  • 11 Posts
  • 5 Reply Likes
Thanks for the analogy. However, it has an obvious communication gap and therefore does not invalidate my request for stronger communication in the UX process. In fact the analogy strengthens my point. Users do not have an issue with "Save As" in Word. Microsoft Office products work as expected because they do not expose a temp file list to its users and collect them into a "library" along with true saved files, and set a false expectation during usage process as to how some of those library files will be treated.

Snagit is saving files (DataStore), including them into a library (which by name alone communicates permanent storage), and destroying those files classified as "temp" (not well communicated) if the user commits a "Save As" (with the wording "Save a COPY" in the file type window). It it is programmatically designed to destroy those files without being transparent enough about it to the user. There isn't even an "unsaved" asterisk next to the thumbnails unless they are previously saved - user has to pull up a contextual menu to see the word "unsaved" on a case by case basis. The user is being trained by UX process and labels to use the library as a *library* where all files are continually accessable, and so why shouldn't the user be frustrated if that training then conflicts with the "Save As" process?

Of course I personally have now learned several ways to avoid the landmine, but that is not the point of this thread. (I am not seeking user help.) The point is that TechSmith should not duck behind their value prop solution of the library to justify poor user communication about its "temp" files during the "Save As" process, nor try to excuse themselves by saying user should have been properly informed by any help file, user manual, etc (that "Save As" is acting against "temp" files not "permanent" files and will destroy the contents of the original in the library) prior to executing the function. The whole point of User Experience Standards is to rely on experience and process, not manuals and training, to perform tasks.

I can't linger on this thread any longer but in sum: Users are frustrated and lose time when this UX is encountered (fact), and since the abailabilty of the so-programmed temp files in the library reduces frequency of the Save As process (so that company is tempted to classify it as "edge case" and not justify much development time into it), TechSmith needs only to introduce a simple communication fix, such as into the "Save As" process (maybe warning the user when it's an "unsaved" file that if they use a different file type it will NOT be a copy, and some SNAG features will be lost... or else denying "Save As" until the SNAG is first saved as such - thereby then making "Save As" a true copy). For a stronger fix (a little more effort) they could ask the user if they want to save any "temp" files upon exit (thus I hope preserving them), or creating an auto-save feature to a default user-specified location so that there are NO "temp" files in the library. Otherwise another debeloper will build a solution with more concern for UX and Snagit will lose its user base.
Photo of Rick Stone

Rick Stone

  • 4481 Posts
  • 1997 Reply Likes
Hi there

Agree generally with the desired behavior. But it's actually a behavior that, if it existed, I would hope we could toggle off and on as desired.

For my own uses, this workflow suits me very well. When I have a need to make other edits to an image, it's usually pretty near the time I've edited. Not days or weeks or months later.

Once I realize I need to make another edit, I am generally able to return to SnagIt (as long as I haven't closed and restarted it) and just undo until I get back to the point where I want to change things.

Most often I do this when perhaps I've captured perhaps a row of icons. Then I need to pare away all the other icons but one. Repeat until each individual icon has been saved.

Not sure if you have ever considered that and I'm not suggesting that we sweep the issue under the rug, only trying to offer something that may not have been considered and will hopefully help.

Cheers... Rick :)
Photo of Manny Carvalho

Manny Carvalho, Champion

  • 1171 Posts
  • 182 Reply Likes
Good I'm glad you are now fully aware how the program works and that you can avoid the "landmine."

By the way, newer versions do allow the user to specify a location for the datastore but temporary files remain temporary files and only the SNAG proprietary filetype maintain vector objects.  Until TS decides to modify this behavior or somebody else comes up with something better, users need to understand the reality of how things work.
Photo of Joe Morgan

Joe Morgan

  • 5631 Posts
  • 2923 Reply Likes
Hello there business,
 
I can certainty understand where the confusion comes in. Maybe the temporary .snag files should actually be called "Unsaved File"  or something as definitive as that.
The time and date stamp affixed to the temp .snags doesn't indicate what that file type is at all.

I prefer Photoshop for most of my work, especially if it's complex in nature. But here's my point.

In Photoshop it's layer on top of countless layer at times, lot's of effects, various masks, distortions, color correction's and filters, blah , blah, blah.

You can save the image as a PNG,JPEG or any format you chose, at any time without flattening the image. You could resume editing it immediately.

Ultimately, you would need to save it as a PSD before closing Photoshop if you intend on editing it in the future.

However, you do need to make it a point to save it as a PSD.

So it's not entirely unlike SnagIt.

Regards,Joe
(Edited)