The current functionality provided by the crufty "upload.module" unfortunately beats the pants off our shiny, new Field-based implementation. A lot of this is to reduce duplicated code between File and Field module, since Field provides the nice re-ordering ability for us, plus the potential to to use multiple fields together.
However, moving "backwards" in any regard is unfornate, so it would be ideal if the File project could support both a "single-value" and "multi-value" widget, so that we could avoid a UX regression. My thinking is that we could continue using the current #type => 'managed_file' field, but add #multiple and #size properties to it, so that it would match the select type somewhat. Then CCK could potentially use the "single-value" widget as needed when doing multi-group functionality, but if the field is being displayed on it's own, then we'd handle drag and drop and our own table layout.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | photo.jpg | 76.19 KB | eojthebrave |
| #10 | photo-2.jpg | 110.31 KB | eojthebrave |
| #5 | widgetforuploading.jpg | 97.92 KB | Bojhan |
Comments
Comment #1
quicksketchSome requested screenshots:
"Simple" use-case, with just a file upload and no extra data.
The current File UI in a multiple value scenario:
The current Upload UI:
Comment #2
quicksketchSince we've been doing some braindumping in IRC, I wanted to go ahead and lay out what I think would be the ideal situation here.
Basically I'd like to see the #type => 'managed_file' element support the #multiple property. If #multiple == FALSE, then we'll get the widget like the first screenshot above. If #multiple == TRUE, then we'll have to tell CCK that we'll be handling our own multiple values, and rebuild our own drag and drop functionality. The ultimate outcome would probably be very similar to upload.module's current output, only we'd convert the "Remove" checkbox to a remove button, and do removals via AJAX the same way the single value widget does.
Comment #3
redndahead commentedLooking at the two screenshots here are my thoughts. A lot of people have said in IRC to move the Remove button to the bottom right hand corner. When having multiple values this would look fine, but with a single value I don't think this would look right and I think we need consistency in this. I think the remove button should be to the left of the filename. This would allow the name to be able to float in width without moving any other elements.
Otherwise I think it looks great.
Comment #4
Bojhan commentedTagging so it turns up in my queue, I will need to take a hard crack at this. What are the design requirements?
One thing I would do is create a clear distinction between the object, meta data and actions.
Comment #5
Bojhan commentedHere is my first try at the widget, I tried to make a diffrence between the object, the meta data, and the action.
Comment #6
redndahead commentedLooking good Bojhan. One thing is Description is not a required field so what does it look like when the description field is not there? Same for list.
Comment #7
Bojhan commentedWe can let a monkey dance in the white space? I am not sure, does that occur often?
Comment #8
eojthebraveWhat happens if you have a file with a really long name like "my-movie-about-cats-and-dogs-on-vacation.flv". I suppose one option would be to truncate it "my-mo...vacation.flv" and then show the full name in the tooltip when a user places their mouse over it.
One of the things that the upload module widget has that the file module does not is a fully qualified URL of the file. This can be really handy for people that are uploading images and embedding them in the body of their node. They can just copy and paste the URL or the appropriate portion of it.
Comment #9
Bojhan commentedeojthebrave: So can you design solutions to these problems?
Comment #10
eojthebraveHuh, certainly not my forte. But here's an idea that I had.
Photo 1 shows a regular file field, and photo 2 shows how that could then be extended for things like images.
Sorry for the crappy cell phone pictures of simple drawings, but you make do with what you've got. Hopefully it conveys the idea sufficiently.
Comment #11
quicksketchI've implemented the design suggested by eojthebrave, with the one exception that I've given the "List" option (now renamed to "Display") its own column separate from the other options. Here are the current screenshots.
Single value:
Multivalue:
I've already committed this code so it should be in CVS already. Though these screenshots are done with the Image field, which isn't yet in CVS anywhere.
Comment #12
Bojhan commentedYup, this is starting to look good. The checkbox is kind of floating around though.
Comment #13
redndahead commentedI agree it's looking good. I would like to see the single value look like the multi value just without the handle. I'd like to see consistency in the UI no matter if it's multi or single. It would also save the issue of file name length moving the remove button.
Comment #14
eojthebraveI agree with rednahead, don't really see the need for two different widgets.
Comment #15
quicksketchEssentially the screenshots from #11 are what got into core. #391330: File Field for Core