create new tag
, view all tags

Feature Proposals » Attach should support drag and drop


Current State: Developer: Reason: Date: Concerns By: Bug Tracking: Proposed For:
ImplementedAsExtension HideyoImazu AcceptedBy7DayFeedbackPeriod 2014-05-01   TWikibug:Item7431 KampalaRelease

Edit Form

DateOfCommitment:   Format: YYYY-MM-DD


The current attach mechanism is clumsy and slow. One file at a time, several screens. Yuck. Various plugins have attempted to improve this, but it remains painful.

My users kept asking why they couldn't simply drag and drop files as attachments. After a while, I wondered too.

Description and Documentation

Drag and drop is now feasible for many browsers. When HTML5 is universal, it will be for all. At the moment, Google Gears can be made - with some pain - to work. I have a prototype based on TWiki 4.2.3 and Google Gears.

The core changes are minimal - and mostly mechanical.

But, since a prototype is worth more than a random request, simply click here for the current snapshot. I'm sure some css purists would do things a bit differently, and the skins folks will want to make corresponding changes in the other skins. Not being a skins person, I'm sure there's a more elegant approach.

Comments and improvements welcome. However, many of the limitations are due to Gears - which is not under active development (though Google supports it.)




WhatDoesItAffect: Documentation, Skins, UI, Usability
Upload.pm 1 small subroutine, some mechanical changes to upload()
a new topic Contains documentation and skin extension section
a new .js file Drag and drop mechanics, stored with the topic
2 lines in typical skin (attach.pattern.tmpl) add an id to form, include the GUI


-- Contributors: TimotheLitt - 2010-06-27


Excellent stuff Timothe! I am looking forward to use the full power of HTML5.

-- PeterThoeny - 2010-06-27

-- TimotheLitt - 2010-06-28

I added a comment, got the login prompt, then a "you're not allowed access" error. That needs to be fixed.

-- TimotheLitt - 2010-06-28

And this time, I'll use firefox - I recommend Lazarus ;-(

You'll be waiting a long time for HTML5 - 2012 - 2022 according the links pointed to by the topic above.

Meantime, I expect the usual mess - not-quite-standards, incompatible previews, ugly legacy.

The prototype is intended to stimulate thought and more immediate action - as well as solve a current problem.

You might want to put the core change in (it's backward compatible); then the rest could be packaged as a contrib.

I encourage playing with it to get some feel for what works - and what doesn't. I can say that the first time I dragged 200 files onto the attach page and they appeared instantly (I was on the LAN), I decided my users were right!

On the other hand, the foswiki folks are promising an updated UploadPlugin that will be far more comprehensive.

If you want to try the prototype, cd to /twiki on a 4.2.3 system and unzip the file. Fix the usual permissions (ownership, selinux contexts) & it should just work. Or, there's a patch file (but you still need to copy the images). I haven't looked at later releases, but would expect the patch to apply smoothly.


-- TimotheLitt - 2010-06-28

Timothe - sounds interesting. Would you mind sharing your work here? we can get the best use of it smile

-- SopanShewale - 2010-06-29

As noted, I'd attached a .zip file with my work back in June.

I've just updated it (see DraggerV2.tar.gz , attached). This version has some fixes/work-arounds that make it more robust in the face of some Gears issues.

It's also much easier to use with an arbitrary form (besides the attach form) -- the javascript will now automagically scan the form and submit the appropriate controls. Although you can still explicitly specify what post URL, file control and formid you want, it can figure this out for itself.

I use this interface for other applications, so it's quite modular.

I didn't create a patch file, but you can untar this over a 4.2.3 image and it should work. You can create your own diffs if you need them.

Also, the javascript can be compiled with Google's closure compiler, which shrinks the code. This isn't necessary for correct operation, but I've attached the script to do this in another file. The filenames in the script differ (I use symlinks from the twiki area), but it should be obvious what's going on.


P.S. Note that I don't monitor all these pages - if you want quicker replies, you have my e-mail address.

-- TimotheLitt - 2010-09-29

Thank you Timothe for sharing the updated version!

-- PeterThoeny - 2010-09-30

Ping on this useful feature. Anybody stepping up to implement this?

Some time past, and more drag & drop libraries are around. Here are some popular ones:

-- Peter Thoeny - 2013-03-16

Here is how I envision the drag & drop (and regular file upload) could work. These are screenshots of the current attachment screen, modified with Fine Uploader drag & drop look.

Before dragging files:


While dragging files:


What do you think?

-- Peter Thoeny - 2013-03-16

Google gears (my prototype was based on it) has died. I haven't re-implemented the prototype; waiting for HTML5 to become available - with IE 10 just out, maybe it's worth looking at again. (My previous note of 'at least 2012' for HTML5 seems to have been accurate.)

The libraries I looked at in the past (including plupload) were far too heavy - they had queues, fancy progress bars, individual cancel, etc. My original version (you need an old version of Firefox to run it) was simple; you dragged files to the drop zone - one or a hundred, and they simply uploaded. No cancel, no queues, no fancy display. Simple progress. It simply used AJAX to submit the form once per file - sequentially (submit next on completion of current) to avoid overrunning server. It also handled filters - file types/extensions to reject (you just put them in hidden fields in the page). Note this approach meant that you had to set the comment and properties before dragging; you didn't click "upload". I looked at the fineupload site briefly - they are soliciting 'contributions' per download per version - so the licensing may be an issue, especialy re-distributing on the twiki scale.

The code should be pretty easy to convert from Gears to HTML5 - there was some initial conditional code for that, but HTML5 wasn't stable back then.

The main advantage of the libraries is that they try to provide fallback support for multiple methods - D&D, POST, iframes. But here we should have (a) user simplicity - drag, drop, done (b) consistency with/fallback to traditional twiki (so the built-in fallback isn't really useful) (c) code simplicity - the libraries tend to be big and buggy. And uploads can be tricky from a security point of view.

As noted previously, the Foswiki folks were working on a plugin approach to D&D, but I haven't investigated to see how it turned out. I think it was too heavy for the core.

I do not like the idea of a multi-step GUI (e.g. drag to select, then click upload). This is not intuitive for most users, and it encourages complexity (e.g. drag, thumbnail preview, edit list, etc.) Keep it simple.

I'd recommend updating the prototype (attached to this topic) to use HTML5 instead of Gears & actually using it before going the library route. I was pretty happy with it - the only thing I missed was Gears didn't allow dragging folders, only files. And completing a drop should have hidden the brows/upload/cancel buttons.

It's on my todo list - but has not been a high priority. If someone wants to take it on, I'll certainly answer any questions (the code is reasonably well commented). Or you can keep waiting to see if it moves up on my list..

-- Timothe Litt - 2013-03-18

I agree that the interface needs to be as simple and intuitive as possible. I do not think however that the extra upload button is confusing. It has to be shown for browsers that do not support drag & drop. Personally I prefer to see the list of files before I commit an upload. I have seen that people use the file comment feature. If we upload directly without confirmation there is no way to add a comment, e.g. after upload one has to select "manage" on the file, add a comment, and confirm the comment. Not so user friendly.

On module size, the Fine Uploader is just a few 10K. It support many browsers (IE7+, Firefox, Safari, Chrome, IOS6, Android). It does not require Flash, or any external libraries.

-- Peter Thoeny - 2013-03-18

If you want people to attach documents - and I do - , you want a desktop computing model, not a webform submission model. Your approach - and all the libraries - evolve the webform model. I'm going for the desktop.

You don't see a an extra list of files and require a 'commit' click when dragging from one directory to another in file explorers (windoze or linux). The drag shows the files, or you can select with click/shift/control-click, stare, then click on the selection and drag. That's your confirmation - with no extra click. And that's the user paradigm. If you insist, I suppose there could be a 'confirm' checkbox to require an extra click. But I advise against. It should look exactly like dragging a file (or a folder) from desktop to a USB drive.

File comment: My prototype applies the same comment to every file, as does the current multiple-file form-based upload. That works for 'architectural plans as of 1-Apr-11' when dragging one file, or a related group. Only when dragging multiple unrelated files does one have to add per-file comments with 'manage' after the files arrive. Or if you want a detailed description of each file. If it is important to handle this (I think corner) case, let's improve the 'manage' interface. One I use with a (non-wiki) photo gallery manager application is to display a form with every photo's thumbnail, filename and comment. Edit the comments - any keystroke sets a checkbox for that comment, submit the form, and all modified comments are updated. Quick, efficient, and not in the way of the common case. If you drag 10 files with this model, you then click 'manage' once, tab thru filling in the comments, and hit 'update' once. I'll attach a subset screen capture - it doesn't show the 'update' button, as it's at the bottom of the list. (If you click on each photo, you get the full size photo in a new window; for a twiki version, I'd open the attachment.) FYI, the 'operation' pulldown makes the comment field editable; other operations are there for things like rename, delete, move. Again, it will do 50 files with one submit as easily as one. That model might also work for managing attachments.


The bottom line is to think of this capability as a desktop explorer model, not a traditional web 'submit the form' one.


Timothe Litt - 2013-03-19

I have updated my prototype to support HTML V5 (and removed GEARS as that's been abandoned by Google.) Otherwise, the behavior is unchanged. You can still drag dozens of files to the attach dropzone, and they'll be uploaded serially. (This provides file-by-file feedback and reduces server load.)

It should be easy to merge into any current skin, as the Drag & Drop support is in an INCLUDEd section.

Basic testing on IE V11, Current Firefox and Chrome. Should disable itself on browsers without HTML5 File API. (IE < 10).

Code is attached - DraggerV5.zip Code size is about 350 lines (uncompressed). Google Closure compiler shrinks it dramatically.

I suggest taking this code into core - its a very simple addition that provides a modern UI with modern browsers. For people who want fancy uploads (managed queues, thumbnail previews, explicit submit, cancel, antique browser support), there are plugins that do this, as well as fallback to Flash and other methods.

Note that HTML V5 also supports the 'multiple' attribute on INPUT type FILE controls. This allows selecting multiple files from a single File Browse.

I suggest replacing the current multiple input FILE controls with one 'multiple' control. (I didn't do this, as I'm on an earlier version of TWiki.)


-- Timothe Litt - 2013-11-29

Thank you Timothe for contributing this updated drag&drop code! I'll have a look when I find time.

-- Peter Thoeny - 2013-12-02

I have updated this once again to include a FILE (browse) control that allows multiple file selection.

The advantage of this is that a user who wishes to browse can select multiple files from a single browser control.

This differs from the latest TWiki "multi-file attach" code, which uses multiple FILE controls and client javascript to provide the illusion of multiple file selection. The multiple FILE approach requires opening one control for each file to be uploaded, and (depending on the browser) may require navigation to the same folder once for each file to be uploaded. While this was an improvement over the classic one file at a time approach, it's still not very friendly. With HTML 5, the single control allows navigating once, selecting multiple files - exactly as users are used to with their filesystem and local application file selectors.

The TWiki multi-file attach code does allow the user to remove a file (the client code deletes the input element). With HTML 5 controls, one simply browses again and changes the selection.

The new HTML 5 javascript will POST each selected file individually (as the drop code has always done). This means that server file size limits apply per-file, not per-form. (The current TWiki attach code submits all selected files with the form in one POST; this means that size limits apply to the total size of all the files selected - which makes technical sense, but doesn't make life easy for the user as he is required to keep a running total to stay under the upload limit. Applying the limit to each file is consistent with the classic TWiki one-file approach, and eliminates the requirement for the user to keep the total selection under the quota. It also provides more immediate feedback, and reduces the server load since only one file at a time is buffered in memory.)

The client code also passes the file's last modification date, so that is preserved on attach. (This is also an HTML 5 feature.) There's a graphic progress indicator as well.

I've made some changes for accessibility (screen readers) - nothing dramatic.

See DraggerV5.1.zip, attached.

I've also attached the updated scripts ( compressor_v5.zip) that I use to compress the JS (Google's closure compiler) - but you can use any js compressor, or just use the uncompressed JS.

The code should work with Safari 6 (but I can't test it because I don't have a Mac, and Apple stopped supporting Safari on Windoze before implementing all of HTML 5.) It has been tested with current Firefox, IE 11, and Chrome. I haven't tested Opera (other issues with Opera on my sites), but it claims support for the APIs used.

I use this in several applications, which is why it's modularized the way it is. I keep the JS API compatible, so if you want to keep up with any updates, I recommend using the JS file as is.

But feel free to adjust the HTML/CSS side to taste. The interface to the JS is documented, and consists of some standard element IDs and some hidden controls.


-- Timothe Litt - 2014-01-02

Prototype ported to trunk, in svn under TWikibug:Item7431.


-- Timothe Litt - 2014-02-11

Thank you Timothe!

All: Please review and provide feedback. I'll have a look too.

-- Peter Thoeny - 2014-02-11

I just fixed a caching problem in the core that caused some flakey behavior with cryptotokens enabled; also improved the status.

Suggest a svn up.

-- Timothe Litt - 2014-02-11

My feedback in KampalaReleaseMeeting2014x02x20:

  • The feature is very cool.
  • A bit confusing to have file upload button and drag&drop on same screen.
  • The comments and properties are "below the fold", and the d&d upload is a direct action, so not clear that the comments and properties are taken into account.
    • So for comments and attributes it might be better to show them above the d&d area.
    • Or better yet, do the upload to a temp space, and user needs to confirm upload, at which point the upload is committed.
  • Issue with the old spec that the attach new file, update existing file,

-- Peter Thoeny - 2014-03-20

Additional feedback in KampalaReleaseMeeting2014x03x20:

  • It's a nice try but there is a room for improvement, both with UI design and feature
  • Recommended spec:
    • Drop and upload are two separate functions, e.g. no direct upload
    • From user point of view, dropping a file is filing a list to upload, then when you press the "Upload" button it does the attach
    • Behind the scene this should happen:
      • Whenever a file is dropped, it is uploaded immediately to a temp area, e.g. not attached to topic
      • Once user presses the "Upload" button, the dropped file(s) in the temp area are moved to the attachment area of the topic
      • So user perceives the attach on button press, but behind the scene work is done already ahead of time

-- Peter Thoeny - 2014-03-20

I hope to get back to this in a week or so. I've been occupied.

The main goal in the prototype was to keep the same user actions as the previous UI, and to make sure that with non-D&D browsers, the screens & behavior didn't change.

I think labeling and updating the Attach Help can help with the upload vs. D&D. Basically, upload is the select (in a browser), think, commit with upload model. D&D is just like the desktop/file explorer. You select, drag, drop - and they go.

Moving the comments and properties can be done - but it will impact all 3 types of attach:

  • Traditional (non-html5)
    • UI was designed for 1 file at a time * Extended (not by me) for multi-file attach, one file per file control
    • comments and properties apply to all files in multi-file attach
    • comments and properties are traditionally 'below the fold'
    • Attach size limit counts against total size of all files in multi-file attach
    • All files in multi-file attach sent to server in a single POST - can be huge, can hit server limts (e.g. mod_security, apache LimitRequestBody, memory limits)
    • No file sent until Upload button clicked
    • We need to keep this (for a while) for non-HTML5 browsers
  • HTML5 browser
    • Multiple file selection with a single File control - traditional UI (shift/select and/or control/select)
    • Attach size limit counts against each file individually in a multi-file attach (Consistent with original UI)
    • Comments and properties apply to all files in multi-file attach
    • Each file sent in an individual POST
    • No file sent until Upload button clicked. Can change selection by clicking File control.
    • Transfer can be aborted (file in progress stopped, no more sent, but files received are attached.)
  • HTML Drag and Drop
    • Multiple file selection at source (e.g. in a file browser window, from desktop, whatever)
    • Attach size limit counts against each file individually in a multi-file attach (Consistent with original UI)
    • Comments and properties apply to all files in multi-file attach
    • Each file sent in an individual POST
    • Files start transfer when dropped (just like file browser window). To abort drag, drop at starting point, someplace illegal, or press escape.
    • Transfer can be aborted (file in progress stopped, no more sent, but files received are attached.)
    • This UI model is exactly what you get on your desktop - I do not think that an intermediate stop in a temp space is sensible as it breaks the model. If you want that, two choices:
      • Create a temp folder on your desktop. Collect files there, then Control/a select them all and d&d. I sometimes do that.
      • Use the HTML5 browser to select multiple files. The Upload button gives you the pre-commit step
      • Of course, one can always delete attachments dropped in error.
    • The error reporting on drop is inadequate and will be fixed. (This is when an illegal file type - specified by admin preference - is dropped.)

There are other D&D options that are more suitable for plugins. (E.g. PupLoad) They queue items, give previews of images, have FLASH and JAVA fallback for pre-HTML5 and have all sorts of fancy options. I didn't need all that, and I don't think it belongs in the core product. Those need someone who is willing to document and maintain the complexity. My prototype (which can of course be rejected) was intentionally a balance: provide the key feature - easily move many files with the desktop direct manipulation model. But keep it simple enough to document and be culturally compatible with existing TWiki. And it's what I needed for my own use. Leave fancy stuff to a plugin - I know some have been proposed in the past.

With respect to issues with the existing Attach UI - I agree that there are issues, but they need a separate feature request - and developer. I didn't sign up for solving all attach issues, just for adding D&D consistent with the existing UI in Pattern Skin. If ti's to appear in the other skins, someone else will have to step up.

I don't mind making minor changes so long as it doesn't snowball into something bigger. Remember that changes to the existing UI will impact documentation, translations, and site docs. So that's not a small step.

-- Timothe Litt - 2014-03-21

Shouldn't this be implemented as a plugin rather than a core feature for the time being? Even though there are some rough edges and it's still in an experimental stage, there is no option to disable the drag and drop feature. At least while it's being experimented, the feature should be packaged in a plugin and easily detachable. This way, I (or somebody else) can work on an alternative easily and cleanly implemented as a plugin.

Let's call it DragAndDropPlugin. It would have:

  • data/TWiki/DragAndDropPlugin.txt, which the current TWikiAttach.txt
  • JavaScript files in pub/TWiki/DragAndDropPlugin/
  • templates/attach.dnd.tmpl, which is the current attach.pattern.tmpl
The drag and drop feature would be removed from the core and PatternSkin by
  • TWiki.TWikiAttach and its companion JavaScript files are removed from the core
  • templates/attach.pattern.tmpl is reverted back to pre-drag and drop
To use the drag and drop feature, a user would add dnd to SKIN. It's like adding tagme to SKIN to use TagMePlugin.

-- Hideyo Imazu - 2014-04-18

I am OK either way, as a plugin or in the core. If in the core or if the plugin ships with core, the usability issues need to be resolved.

-- Peter Thoeny - 2014-04-22

I've realized that you can implement a decent drag and drop capability only by a skin. I'm introducing DropzoneJSSkin as per TWikibug:Item7488.

-- Hideyo Imazu - 2014-05-01

And now, DropzoneJSSkin is there. Please give it a try.

-- Hideyo Imazu - 2014-05-01

I know the drag and drop capability implemented by DropzoneJSSkin has room for improvement -- e.g. it would be better if files are uploaded immediately to a temporary area on the server when they are dropped/selected, and then attached the topic after "Upload files" button is clicked. But DropzoneJSSkin is good enough to be made an enhancement to PatternSkin. The enhancement mentioned would be easier if DropzoneJSSkin is merged with Patternskin. What do you think?

-- Hideyo Imazu - 2014-05-01

Hideyo-san enhanced the PatternSkin with the DropzoneJSSkin, so drag & drop is now part of the core distribution. Thanks Hideyo-san!

-- Peter Thoeny - 2014-08-21

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng drag-drop-1.png r2 r1 manage 43.9 K 2013-03-16 - 07:12 PeterThoeny  
PNGpng drag-drop-2.png r1 manage 51.3 K 2013-03-16 - 06:46 PeterThoeny  
Edit | Attach | Watch | Print version | History: r26 < r25 < r24 < r23 < r22 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r26 - 2014-08-21 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.