Deletion without confirmation followed by temporal 'undo' option

[LukeOwlclaw]

Expected behaviour

When I delete an image, I want to see a preview of the image I am deleting in the confirmation dialog.

Actual behaviour

No preview, just filename. Not helpful when using grid view.

Steps to reproduce

1. Delete photo.

Environment data

ownCloud app version: 1.9.1

[tobiasKaminsky]

I doubt that this is possible as it is the native confirmation dialog of android. (Moreover when multiselect is coming this is not possible).

Can you explain a bit more why it is not helpful when using grid view? Grid view has such a big "icon" that one should not need the icon in the confirmation dialog?

[LukeOwlclaw]

The filename in the dialog is not helpful as filenames are not shown in the grid view. So there is no way to know whether one really clicked the correct photo. This is in particular a problem if you delete multiple photos quickly in succession. Due to removing the old photo and refreshing, the view might change while you are tapping in order to delete the next.

With multi select it will be much better as you can already confirm while selecting whether you got the intended images.

It is a native dialog? I will try to have a look whether it's possible...

[AndyScherzinger]

We do use the standard AlertDialog for the confirmation but could like with other dialogs also write our own. So yes it would be possible to do that. In order to implement this can you @LukeOwncloud or anyone else provide a wireframe/mockup and also we should then have a discussion with @owncloud/designers beforehand so we implement it the right way.

[tobiasKaminsky]

@LukeOwncloud ok this makes sense. Thank you for clarification!

[LukeOwlclaw]

That wasn't difficult. Only 5 extra lines added to onCreateDialog() in ConfirmationDialogFragment.java (of course, one needs OCFile file but that should not be a problem. Let's talk about the looks first.):

    ImageView image = new ImageView(getActivity());
    String tagId = String.valueOf(file.getRemoteId());
    android.graphics.Bitmap thumbnail = ThumbnailsCacheManager.getBitmapFromDiskCache(tagId);
    image.setImageBitmap(thumbnail);
    builder.setView(image);

Looks like this:

@jancborchardt What do you think? It is still the same dialog, just the thumbnail (if available) added at the bottom.

EDIT: new screenshot (Note: The background is not grayed out. It was like this already before my changes. Could it be an Android 4 issue which I should report?)

[AndyScherzinger]

Seems like it. The background is grayed out on Android 6. Is this happening for all dialogs or just this one?

[LukeOwlclaw]

For all. But I just checked, on my emulator (also Android 4.2.2) it looks fine. I'll update the screenshot above.

[LukeOwlclaw]

@AndyScherzinger Found the reason: YAAB. (https://bitbucket.org/gyrussolutions/yaab/wiki/Home) Deinstalled and problem is gone.

[tobiasKaminsky]

Maybe the size of the thumbnail is a little bit too big?

[LukeOwlclaw]

I took it as is. It's the same size as in grid view, and that size was chosen for a reason, right? But let's see what the design experts say.

[AndyScherzinger]

@jancborchardt any input? :)

[jancborchardt]

Rather than confirmation dialogs we should strive to offer »Undo«. I encourage you to read »Never use a warning when you mean undo« by Aza Raskin (former Firefox design lead): http://alistapart.com/article/neveruseawarning

The only confirmation dialog we currently use anywhere in ownCloud is the one for delete on Android with the choice between removing from device or from server & device. And I’m not happy with that … just haven’t really come up with a better solution or had time to think about it.

Does anyone have a better idea, maybe from @owncloud/designers? Or @DeepDiver1975 you also mentioned you don’t like that dialog – any clue?

[AndyScherzinger]

The obvious choice like you already mentioned which is what I would also expect is the undo operation like GMail is offering it too. For GMail it is easy since it just has to move the mail back from trash to inbox. For owncloud that doesn't really work since at least locally a deletion is a deletion and you cannot undo that. Else we would have to implement something like an internal trashcan where we temporarily move the file to and if the undo doesn't get clicked then some seconds later finally delete the file..

[LukeOwlclaw]

As soon as the "on device" view is available, delete there could be a local delete only. The main view always deletes remote and local file. No confirmation dialog necessary then. Would that be intuitive?

@AndyScherzinger We do not really need a thrash. We could just pretend delete is immediately executed (remove from current view), show undo hint, and when hint times out perform the actual delete operation.

Another issue: Currently delete is blocking. That is not nice but error feedback is easy. How should user be informed that files could not be deleted when it is a background operation?

[AndyScherzinger]

@LukeOwncloud true, if we do not delete immediately we do not need a trash mechanism :)

[tobiasKaminsky]

@LukeOwncloud No, this is an assumption where I am unsure if this is intuitive for all. At least for me I want, regardless which view, have the possibility to delete the file either remote or locally or both.

[tobiasKaminsky]

The delay on delete is indeed very nice :+1:

[jancborchardt]

Undo always relies on lying for a few seconds. ;) Gmail has »undo send« which simply delays sending the email for 5 seconds. Same thing we should do.

[tobiasKaminsky]

Very cool and easy trick :+1:

[malkomich]

I agree with @jancborchardt , maybe we could keep the confirm dialog to remove only when the file is downloaded locally (in order to choose remove only locally or not), and implement the undo message at the bottom as Google do in his apps.

[malkomich]

Or maybe an extra option to remove locally, and don't show the dialog anymore

[tobiasKaminsky]

@jancborchardt what is your favourite solution? For me it would be like @malkomich said: Two option "delete file" -> delete file locally and remote "delete file only locally" (shows only if file is downloaded). Both with 3s delay "undo" described as above?

[jancborchardt]

I would just go for the simple flow:

1. Choose »delete«
2. Delete the file locally (if it exists locally) and remotely, both
3. Offer undo (for 5s I would say, 3 is a bit short. Or is that Android standard?)

The deleting locally stuff we should do separately via cache cleaning or whatnot. Also cc @DeepDiver1975 cause we talked about this in the past as an annoying point because it makes deletion quite cumbersome.

[davivel]

Renaming issue according to it's evolution.

[JuancaG05]

Part of this issue will be done in a new one:

• https://github.com/owncloud/android/issues/4342