SoylentNews is people
SoylentNews
Our office recently updated to a new version of the Office Suite, and it still has an icon in the upper-left corner to perform the 'Save' function. Floppy drives have not been in use for years, and many children would not recognize a 3.5 inch floppy disk on sight. Programs have used this icon for years, because we have yet to find a suitable replacement. The CD/DVD can no longer represent saving, because they have come and gone. Even moving to the more abstract Piggy Bank icon would not work, because they are seldom used in the modern age. A USB Key icon may represent saving in some form, but the may not be around much longer if another medium gains favor. Does this mean that the venerable 3.5 inch Floppy will represent saving information to future generations, or should it be replaced by a different symbol?
(Score: 4, Interesting) by FatPhil on Tuesday December 20 2016, @09:55AM
And before you accuse me of speaking from a position of ignorance, I have used VMS, and the fact that it was unable to distinguish (because it didn't even try) between an old version that was worth archiving, and an old version that should be binned, convinced me once and for all that it was an anti-feature, more than a feature.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by theluggage on Tuesday December 20 2016, @10:22AM
I have used VMS, and the fact that it was unable to distinguish (because it didn't even try) between an old version that was worth archiving, and an old version that should be binned, convinced me once and for all that it was an anti-feature, more than a feature.
For me it was using VAX C and discovering that the regular files created by the standard i/o library were incompatible with the "record-based" files created by every other VMS application... The VMS devs never did get the message that a file system wasn't meant to be a DBMS (probably the same folk who later tried to replace the Windows file system with a relational database).
(Score: 4, Insightful) by pTamok on Tuesday December 20 2016, @10:40AM
Well, I did use CMS* on VAX/VMS. Horses for courses.
I would continue to contend that the function implemented in most Office software is not 'Save', but 'Overwrite'. I take your point about being unable to distinguish between an old version worth archiving and an old version that should be binned, but I would suggest that perhaps you are looking for a function labelled 'Archive'?
Given the cheapness of disk storage, I would suggest, from a human interface point of view, that keeping a copy of all old versions is a viable, if not sensible insurance strategy, and if you are at all bothered by disk-space considerations, do a purge at a sensible time interval and with a sensible selectivity - which might possibly be set by the user, or a system administrator. You could explicitly set an automatic purge with keep=1 if you wished, and have the functionality you describe.
Currently, people operating office applications are able to completely trash their work by an inopportune 'Save' - this is not good. In a world where it is considered good practice to protect people from their mistakes, I would argue that creating a new copy each time 'Save' is invoked would be good practice, so rollback is possible (other methods of rollback could be used), and having both a 'Save As' function and an 'Archive' function would add belt and braces.
I haven't polled users to see if 'Save' operates in the fashion they desire, but the number of times I have had to restore old versions of critical documents for people who have saved changes that they didn't intend suggests something isn't working. NTFS does now allow you to restore previous versions of files, if you have that capability enabled, and know how to use it - however, many people operate on important documents held on USB sticks with FAT filesystems - including students writing theses.
The use cases: for a developer, who knows how to use a code management system; and and end-user, who probably doesn't know, and doesn't have access; are different. Developers are generally very computer literate, and are usually given access to the tools to do their job: end users often have to struggle with whatever they are given. Relabelling 'Save' as 'Overwrite' would help to prevent a number of occasions where people have shot themselves in the foot.
Thanks for your feedback. I agree, sometimes it was a chore finding which file version was the one that I wanted: but it was better than having to rewrite something because an accidental deletion had been made permanent.
*DEC's Code Management System.
(Score: 2) by DutchUncle on Tuesday December 20 2016, @07:32PM
Had to respond to "given the cheapness of disk storage". Back in the days we're all talking about, it wasn't. While being able to recover old versions of files is handy sometimes, it's not what you want most of the time. OTOH since in real life NO system actually overwrites the old copy - it really writes a new copy and then switches names, unless you work really hard at doing in-place operations (which only worked on certain hard drives) - keeping the old copy is not hard. OTOOH, leaving unlimited old copies around isn't such a good plan either. The solution might be simpler: we already tend to have a distinction between "save" and "save as"; if we just standardize as "save as" with an additional click to select "same name" (not just having it pre-filled-in) then it's as easy as it is now, and with the clarity you want.
(Score: 0) by Anonymous Coward on Wednesday December 21 2016, @12:45AM
The "write new data stream, drop old data and swap names" is not what seems to be done by many coders. How do I know? Any fucked program that tries to save, fails for whatever reason (disk quota, process crash, hw powerdown)... and now you have no valid data at all, new or old. The filesystem may not overwrite, but from user space the data is gone/damaged and will require some luck and special tools to recover.
So no, too many coders don't even know how to properly replace file contents, even if the method was in computing litetature at least since early 80s. Every 5-10 years all the data dance with fseek, fsync, etc will hit the news but coders will quickly forget again, or even go silly like hitting fsync over and over ("I heard this keeps the data, DO IT!") instead of plan correctly how to balance integrity and speed.