give the user the feeling of control over his data -and possibility to also have it about uppy HOT 12 CLOSED

I see how these UI elements could aid the user feeling more in control.

giving/showing a possibility to cancel the upload during the uploading process

+1 a cancel/abort button is planned.

giving/showing a possibility to delete files chosen but not uploaded yet (if this is possible in uploading procedure)

+1 removing files from the selection, before uploading, is planned

giving/showing a possibility to delete uploaded files (of not already processed further e.g because of waiting for other uploads)

-1 We can use the tus termination extension to clean up files in progress, but once files are succesfully uploaded, it could be that encoding has started, etc. Allowing a delete an an arbitrary time after success, could cause all kinds of problems, as well as pose security issues, and limit the number of compatible uploading backends. If the website owner wants their users to delete files, that should be a separate feature in their app, vs handled by Uppy.

from uppy.

thanks for positive detailed answer/comment
Regarding last point you are absolutely right. Was only describing best usability from user's pov.
Of course this could and properly should not be done within uppy.
Tried to week it by the text in brakets "of not already processed further", but was not enough.

Just a fast idea on this:
What one could think of, is implementing some kind of "visible" setting for a uploaded files.
With this one could give the user a least the "feeling of deletion" but from technical site it's only hiden.

This feature could be also used for other things like showing only still uploading files and not the completed ones: If upload is finished setting of file is set from
"Visible" (icon, name, progressbar etc) to "invisible"
(this behaviour should not be default/ optional)

from uppy.

That might be interested but I'm a bit concerned about giving the user the feeling of deletion, where in fact the file is on the remote end's server. I know for instance Facebook has gotten into some serious trouble before for being 'vague' around this. It would seem this could lead to confusion in the best, and a lawsuit in the worst case ;) I would personally -1 spending development time on this feature. I do very much like your other contributions though and have put them on our roadmap in 7fc8544 💯

from uppy.

just to clarify: with this you are in general of course right again :-)

In reality it depends on details of usage/implementation by application dev.
If you think of this from procedure as a "simple delay":

1. the user express his wish to delete an uploaded file by clicking delete button
2. the file is marked as "wished to be deleted"
3. and with this mark it's directly hide
4. and it's excluded from further processing
5. at a point of time when its possible this file is completely deleted

And depending on conditions, this "delay" may only be e.g. 10 sec or 1min or so...
with this kind of implementation no problem occurs at all.

from technical side this may be done by adding a "_no" to file name
-> could be used to

• not show
• not process futher
• not keep

PS: great to hear you like some of the ideas and put them to roadmap :-)

from uppy.

hmmm.. putting it in the context,
this "_no" option is not that different from "cancel upload" function.

What happens with data if user clicks "cancel" after 80% of upload?

The data is on the server and it's in responsibility of dev./admin not to use it.

Many types of data could be used/looked in even if the file is not 100% completed.

This "_no" option just to move the border by 0,1%:
after 99,9% of upload a cancellation is possible but at 100% not.

only the technical hurdles to look in non complete files is tiny portion higher ;-)

from uppy.

I appreciate you putting the user first here! I also tend to agree us (me?) technical folks sometimes stare blindly on what technical possibilities/limitations without putting that user first. Please allow me step in my own bear traps though ;)

• what about users uploading a file already suffixed by _no? Or solutions that depend on unmodified filenames?
• if we don't opt for changing filename, but add this to the metadata, how will we transmit this to the backend in hindsight?
• what about backends that don't respect the additional payload and clean up the file? (Uppy could be deployed currently with Apache/Nginx or a tusd server, currently none of these would support deleting/marking files after the deed is done. Would we request implementers to run some script in their crontab? in what language? what about Windows servers?)
• what if processing has already started? now the marking will either need to return an error to the user, or it would lie that the file will not be processed, while in fact, it may have already been encoded/emailed/saved in some place that we can't revert in a standardized way

So while I want Uppy to optimize for user experience and am willing to take big technical hurdles to do so, I feel that hiding what is really happening (without being able to stop it from happening) may cause more confusion than it solves in the end.

from uppy.

true again :-)
What do think of simply not forgetting it, but give it a very low prio?

from uppy.

uups we were writing at same time...

from uppy.

btw: many thanks for that detailed discussions!

from uppy.

Welcome! You too for your input trying to get Uppy to a better place 👍
We'll leave this issue open for the two undisputed improvements you added, the third one I'll discuss with the team to see if I overlooked anything.

from uppy.

It's pleasure to contribute to interesting things like this :-)

just one last comment regarding discussing this topic further,

maybe it's easier to focus
on

• the topic of usability and
• the technical background

by having peace in mind regarding absolute transparency towards users (without any delay)
by catching this thought first #63 (comment)

from uppy.

wow many of the points addressed here are already there in current version (10.08.2016)
that's awesome!!

just to get back into talk regarding remaining points...

just opened a new issue for "working on already uploaded files" #112

from uppy.