[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-bugs] Bug deleting parts from Attach Documents

From: Jim Busser
Subject: [Gnumed-bugs] Bug deleting parts from Attach Documents
Date: Sun, 30 Aug 2009 17:24:34 -0700

Upon clicking the "delete parts" button, the part disappears immediately, and the user who did not notice can be confused by being presented immediately with a dialog that appears to be confirmatory, except it is not confirming the deletion of the part (which was already a done deed) but whether to delete the *source* file for the part that has been removed from the list.

I concede that technically it is not a bug, but it can be prone to human misinterpretation and therefore error and problems. Suggest:

1. existing users be asked whether they would object to the addition of confirmation to parts deletion. It is possible they will have gotten used to it and therefore object as not needing to confirm saves time if they often add parts by mistake, but IMHO it is not usual to do this. On the Mac, you hold down the Option key while selecting a menu item, or drag-and-dropping, or button-clicking, if you wish for example to force the emptying of Trash without confirmation, or otherwise knowledgeably modify a usual action. If they do not object, great, if they object, well... can it be further discussed? I am thinking we should probably be aiming to be consistent.

2. while it can benefit workflow to be able to delete redundant source files, the action should likely be applied to all parts, and might be better relocated into the Save subroutine. I would suggest -- to the right of [Save][Discard]) -- a checkbox that says

"Permanently delete the source file(s) after a copy has been imported as Part(s)?"
        "on Save, delete the source files for all parts".

In the attached screenshot I moved the "deletion" dialog to capture it in a small png. My proposal would be:

i. checkbox always defaults "off" upon opening the "Attach documents" plugin, yet holding in memory any value altered while this patient remains in focus (or at least while the plug-in remains in the foreground)

ii. at "Save", if unchecked, the option to delete source files is bypassed

iii. if checked, the user is presented with a confirmation dialog that, in its most simple form, asks:

Permanently delete the source file(s) after a copy has been imported as Part(s)?

… while a more complex dialog could offer all of the source names, and could even allow individual tagging (checkboxing) for deletion or preservation, the source file names could be arranged to still be visible in the Parts area and referenced with

iv. suggest that for the confirmation dialog, change"No" "Yes" to "Cancel" "OK" as this pairing is IMO less prone to human error "Cancel" is more easily (mentally) associated with erring on the side of caution, whereas this is not always true (or at least requires more mental attention) with "No".

v. suggest that the source deletion (even if requested) not proceed until it is possible for the GNUmed client to receive back (from postgres) confirmation of the successful "save" of the newly-attached document. If it was unsuccessful, the offer to delete the source should not even proceed and, instead, the user should be informed. Maybe they should try again? Can the parts area continue to hold its list of parts? Or would it be better (in case one was the source of an error, maybe a corrupt source) what way of handling a failed save would you suggest?

PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]