Save button doesn't warn before overwriting existing file

[iGadget]

Usability bug: In a typical serial scanning workflow, one tends to scan a document, click on the 'Save' icon, navigate to the location where the document should be stored, enter the name of the document and finally click on the 'Save' button. So far so good.
After that, one typically moves on to the next document, which typically needs to be saved to a different file.
Currently however, when scanning a second document, it is displayed next to the first. Other than that, there is no indication whatsoever that Simple Scan will overwrite the previously saved document as soon as the user clicks the 'Save' icon.

So the user will typically remove the first page(s) which he/se presumes are safely stored in a file and hit 'Save' again...

Moreover, if the user isn't paying close attention, he/she could run into the situation that numerous scans have been made and presumably saved, only for the user to find out that only the *last* scan was actually saved and all previous scans were overwritten.

I've run into this 'bug' numerous times and so have other people in my environment who have been using the application in this manner.
IMHO there are numerous ways to 'fix' this:
1. Always warn before overwriting an existing document. In an application as simple as Simple Scan, I cannot imagine why anyone would want to have the 'Save' icon/button working the way it does now when scanning multiple documents.
2. Clearly show which saved document the user is currently working on (e.g. display the file name in the menu bar).
3. Find a way to make absolutely clear to the user (at the first use of the application?), that the workflow for serialized scanning of documents is using a 'CTRL+N' (for new document) after EACH scan.

A combination of the above would of course also be a solution.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: simple-scan 3.1.5-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-10.16-generic 3.0.4
Uname: Linux 3.0.0-10-generic x86_64
Architecture: amd64
Date: Mon Sep 5 20:33:53 2011
DriverPackageVersions:
 libsane 1.0.22-2ubuntu1
 libsane-extras N/A
 hplip 3.11.7-0ubuntu5
 hpoj N/A
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110803.1)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-10-generic root=UUID=24ee2295-58ad-4d06-a4eb-c0c7359e2bb6 ro quiet splash vt.handoff=7
SourcePackage: simple-scan
UpgradeStatus: Upgraded to oneiric on 2011-09-01 (3 days ago)
dmi.bios.date: 01/17/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.30
dmi.board.name: H67M-GE
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.30:bd01/17/2011:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnH67M-GE:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

[Michael Nagel (nailor)]

this will not be fixed in the packaging of the application

[iGadget (igadget)]

Michael, thanks for your comment. So... what does that mean - it will not be fixed in the *packaging* of the application? Perhaps it's developer slang which I'm unfamiliar with, but AFAIK this usability bug has nothing to do with the packaging. Just fix it in the application itself and you'll make simple-scan a whole lot more suitable for serious use.

In case you mean it's not going to be fixed in the application itself, I would appreciate a little bit more info on *why* such an obvious usability issue will not be fixed...

[Michael Nagel (nailor)]

Hi Matthijs ten, sorry for using developer slang. Someone programs an application (simple scan) and then someone (possibly different) integrates it into Ubuntu. That second step is called packaging. Bugs that are present in the program should be fixed "upstream" (by the first person), so that other people using the application, but not using Ubuntu, can profit from the fixes as well. Only problems with the integration into Ubuntu should be fixed in the packaging.

What I did was moving this bug from the simple-scan packaging to the upstream Simple Scan development; so basically we agree :)

One can discuss if it is better to keep a reference in the packaging bug list to the upstream bug and wait until the upstream fixes have been incorporated into the package, and only then close that reference bug, but in my personal opinion this is total overkill for such a small project as Simple Scan.

So rest assure, this bug is still relevant and at filed at a place where it gets maximum attention from the relevant developer(s) -- even though there is not actually happening that much currently.

[iGadget (igadget)]

Thanks Michael for your elaborate reply.

I wasn't aware of this situation where there's a difference between package names and that this particular difference in the naming scheme is used to define just the packaging process and not the application itself. Thanks for clearing that up :)

So I'm glad we agree on the relevancy of this issue and hopefully this gets fixed in time before 12.04...

[Michael Nagel (nailor)]

I am going to look into this, just setting some status to make it disappear from the incoming queue.

[bojo42 (bojo42)]

As of version 3.2.1-0ubuntu2 found in precise, this is still quite annoying usability wise.

Meaning you open Simple Scan, do your scans, save them, delete some or all of them (selection wise) because you want to scan some other things, then you press "Save" and you up to repeating all the scans you did before, at least when the number of new scans is equal or higher then the old ones.

To get it right you are forced to open a new scan, then it won't just overwrite, but after delete scans in Simple Scan there is no visual indication that would distinguish those modes. So it just too easy to miss and this is really an usability nightmare, as users probably can get quite angry about that behavior, as you will loose too easily already done work.

The easiest fix would probably to always prompt when overwriting. Maybe that would also be the best in terms of interaction with other programs, just think about scanning, editing some files with GIMP without changing filenames and continue with other scans.

[theghost (theghost)]

Please fix this. It's really annoying. To have anything overwritten without prompt. You already have the prompt at "Save as", just reuse it.

[iGadget (igadget)]

bojo42, TheGhost, please mark this bug as 'this bug affects me' to increase the heat points. Thanks!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Paul Backus (lifeenemy)]

I put this here on accident and can't find how to remove it. My mistake!

[qu9542 (quhaiyan-rs)]

Please fix this issue, it is still in Ubuntu 12.04 LTS. Thanks a lot

[Deevad (deevad)]

This kind of bug are production disaster. I just lost a full scanning session here.
30 min of document to redo ...

== What happened :
1. I scanned 10 documents on a slow scanner
2. I press 'Save As' and entered the name My-Scan.png'
3. I get My-Scan-1.png, My-Scan-2.png, My-Scan-3.png ... [...] My-Scan-10.png saved.
4. I delete on the screen all the scanned document ( Simple Scan was getting slower displaying all those document ). One by one, delete key. Slow process, but ok.
5. I scanned another raw of 10 documents.
6. Then I pressed the 'Save' button on toolbar assuming my scanner will be saved starting My-Scan-11.png, My-Scan-12.png etc...
7. I check file on disk ... DRAMA : My-Scan-1.png, My-Scan-2.png, My-Scan-3.png ... [...] My-Scan-10.png are overwritten by the new scanned series. No trash, no undo , no warning modal dialog, just pure data-lost.

Sadly, I'll uninstall and reinstall another solution for my scanning workflow for now. But I prefer to report here before. Even if I see it's a 2 years old bug. Sad

[mikewhatever (mikewhatever)]

Just stumbled over this bug by scanning a few photos. Confirmed in 12.04.4, and very annoying.

[mikewhatever (mikewhatever)]

The bug is also present in the latest version, 3.11.4. Just tested it from the 14.04 daily ISO.

[mikewhatever (mikewhatever)]

Bug confirmed in version 3.12.0.

[iGadget (igadget)]

And here we are, halfway past 2015, using version 3.12.1 on Ubuntu 14.04 and STILL no solution. And oh, I AGAIN lost work when I incidentally used this app again and presumed that MAYBE after almost FOUR BLOODY YEARS this bug would have been solved. But nooooo...
Major fail IMHO.

Continuing to use gscan2pdf which is also far from perfect, but AT LEAST is being maintained.

[Mattias Andrée (maandree)]

Please consider removing the ‘save’ button altogether, and just offer ‘save as’.
It is a quite a bummer to lose a 100 scans just because you accentially press
the wrong menu option. This, and hotkeys (which do not work anymore) is an
important part of my workflow.

[Luis Alvarado (luisalvarado)]

This needs to be address. Just lost 3 times, 54 pages from 3, 55 pages work. All 3 had 55 pages, ended up with 3 pages (one for each). Ubuntu 16.04 and 15.10.

[Ian (superian)]

TL;DR; Still present in 16.04

(Starts saving a series of 44 pages. Looks at the directory I've saved the previous lot of 12 pages in, and am saving the current one in.)

'Hmm, that's odd, I'm sure I kept more than pages 8-12 of those previous scans. I wonder if it's overwriting them? Let's see...'

(Copies Scanned Document-01.png to Scanned Document-16.png. Watches it being overwritten with a new one.)

'Who thought that was a good idea?'

Fortunately, I'd extracted the bits I wanted from the older files, but a 'consumer' program overwriting existing files without asking is almost always a really, really, really bad idea.

[Robert Doering (rdoering-info)]

Problem Description:
Simple Scan works document based but most people seams to not expecting this.

If you edit an text document, you expect that is will be stored in one file. It makes sense to enter a name for that file while storing it the first time. Further it is clear that these stored file will be replace by all incoming changes.

I believe that was starting point for the application "Simple Scan". That is not wrong but it is not what people seems think about an application for scanning pictures and documents.

A scanning application is not an editor. You want scan pages, arrange them and store them into a file. Most of the time you do not want to place that file and if you want to explicitly say that.

Problem Steps:
- scan page A
- press save
- enter name of file and store
- delete scanned page
- scan new page B
- press save
- (oops previous stored page A is replaced by page B)

Solution:
- remove document binding
- replace the button "new document" by "clear all pages"
- replace the button "save" by "save as"
- remove menu-entry "save"

I uploaded the code to fix the problem as described with the commit 916. Unfortunately I am not familiar with the launch-pad workflow and do not see a way to send an pull request. May anyone help me with this. Currently the code is at lp:~rdoering-info/simple-scan/simple-scan .

Thanks,
Robert

[Robert Ancell (robert-ancell)]

I've removed "Save As". "Save" now always exports the current document to a file.

The issue about overwriting multi png/jpg images is in bug 1672019.

[iGadget (igadget)]

Thanks Robert for looking into this.
However, I'm not sure how removing the 'Save As' functionality fixes the issue. Can you elaborate on this?
Furthermore, bug 1672019 is just a small part of the issue described here.

Interestingly, the "save-behaviour" of Simple Scan seems to vary between output formats:

PDF - behaves as in this bug report
PNG & JPG - behaves as reported in bug 1672019

I never noticed this before since I rarely save to PNG or JPG.

It would be great to have both bugs fixed after having been present for over 6 years...

[Robert Doering (rdoering-info)]

Hi Matthijs ten Kate

I am glad to see a response on this issue.

My intention is that "Simple Scan" implies to simply scan a document.
Nobody expects that "Simple Scan" is an document based application like
libre office, audacity or sublime text. Instead you expect that it scans a
document, shows it to you and than you can press save and it will be saved
to disk.

For this I replaced the 'save' functionality by the 'save as'
functionality, because a document saved as file could be replaced by a new
scanned image and 'saved' as the same file, which the user does not expect
as explained. Save as is a better choice. This opens a dialog, asking you
for a file name with a pretty good preset and in most cases you simply
press enter to acknowledge it to save a new file.

In my mind it actually fix both bugs.

Robert

2017-03-29 13:24 GMT+02:00 Matthijs ten Kate <email address hidden>:

> Thanks Robert for looking into this.
> However, I'm not sure how removing the 'Save As' functionality fixes the
> issue. Can you elaborate on this?
> Furthermore, bug 1672019 is just a small part of the issue described here.
>
> Interestingly, the "save-behaviour" of Simple Scan seems to vary between
> output formats:
>
> PDF - behaves as in this bug report
> PNG & JPG - behaves as reported in bug 1672019
>
> I never noticed this before since I rarely save to PNG or JPG.
>
> It would be great to have both bugs fixed after having been present for
> over 6 years...
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/842076
>
> Title:
> Save button doesn't warn before overwriting existing file
>
> Status in Simple Scan:
> Fix Committed
>
> Bug description:
> Usability bug: In a typical serial scanning workflow, one tends to scan
> a document, click on the 'Save' icon, navigate to the location where the
> document should be stored, enter the name of the document and finally click
> on the 'Save' button. So far so good.
> After that, one typically moves on to the next document, which typically
> needs to be saved to a different file.
> Currently however, when scanning a second document, it is displayed next
> to the first. Other than that, there is no indication whatsoever that
> Simple Scan will overwrite the previously saved document as soon as the
> user clicks the 'Save' icon.
>
> So the user will typically remove the first page(s) which he/se
> presumes are safely stored in a file and hit 'Save' again...
>
> Moreover, if the user isn't paying close attention, he/she could run
> into the situation that numerous scans have been made and presumably
> saved, only for the user to find out that only the *last* scan was
> actually saved and all previous scans were overwritten.
>
> I've run into this 'bug' numerous times and so have other people in my
> environment who have been using the application in this manner.
> IMHO there are numerous ways to 'fix' this:
> 1. Always warn before overwriting an existing document. In an
> application as simple as Simple Scan, I cannot imagine why anyone would
> want to have the 'Save' icon/button working the way it does now when
> scann...

[Robert Ancell (robert-ancell)]

@Matthijs - I made two changes:
1. Removed the "Save As" option, and made "Save" always prompt for a location. This should fix your proposed solution one (it always prompts for a location and always warns before overwriting).
2. Made the save dialog aware that saving in PNG/JPEG will create multiple files and check that those files exist before overwriting them (this is the solution in bug 1672019).