Media Sprint file upload proposal

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
arthurf's picture

This is a first run at the UI from the file uploader from the media sprint in NYC. We are not sure if we want to replace file upload forms on the page or use a popup window for the interface similar to how asset does things. Regardless, this is a multi-tabed element which houses media that the user has created locally or externally, upload and embed forms. Additional tabs are possible but have not been discussed.

As files are uploading or being embeded, the user is presented with formatting options (determined by the admin) for their media. An example of this is the YouTube file uploader which provides pretty clean interface.

Comments are welcome- this is a work in process and we're still trying to nail down the backend pieces. Ideas for admin interface (please see asset for some of the needed functionality) and or mockups are very very welcome.

AttachmentSize
media_sprint.jpg931.1 KB

Comments

Basicly avoid adding

Bojhan's picture

Basicly avoid adding anything to the interface on node edit/add beyond just the upload form. Can you supply the images with annodations and zoomed in a bit more? It is hard to figure out what it all means.

Hijacking upload element

aaron's picture

Actually, we plan on doing just that. We're hijacking the upload elements of node edit/add forms, replacing it with inline tabs. See http://aaronwinborn.com/blogs/aaron/media-code-sprint-january-2008 and http://groups.drupal.org/node/18063 for some preliminary information about the ongoing media sprint.

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic

DM "in October"?!? It's on my shelf?

Cliff's picture

Hey, Aaron, you might want to update your signature line to indicate that your outstanding and easy-to-follow book, Drupal Multimedia, is available now! (But perhaps everyone here already knows that.)

Thanks for producing this volume, as well as for your great presentation at DIWD in New Orleans.

OK, booting inkscape...

Manuel Garcia's picture

I'm on it guys... creating a 1st draft mockup in inkscape... standby

Awesome! We definitely need

skilip's picture

Awesome! We definitely need improvements on file uploads / management in core. I'm a real big fan of Moxicode's Filemanager. Have you noted the UI of SWFUpload? There's a discussion going about its future here.

this will free them up from

aaron's picture

this will free them up from having to implement the filehandling part of it, and just focus on the ui. they'll simply use form_alters to turn the form into what they need for the swf file, and services to communicate. the file handling will happen through the stream wrappers.

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic

From

yoroy's picture

From http://groups.drupal.org/node/18063:

The end goal is a GUI for adding content to a site- including audio, images, video, embedded, and text based files (.ods, .doc, .pdf, etc). This GUI can present users with options for file conversions (for example, image resizing), previewing, and areas to insert the content into (CCK fields, attached to the node, etc). For end users, this process must be consistent, simple, and as intuitive as the highly complex process of media management can be.

I was going to ask what you are actually are trying to accomplish, but there it is!

From looking at the attachment here, one first thing I noticed immediately is that the 'hijack!' is connected to the media 'browser' view. Is that because I might want to add an existing file? If I clicked on 'Upload' in the node/add form I'd expect to get an upload ui immediately, without the browser view in between.

Oh well, we'll see :-) Thanks for posting to the usability group and excellent initiative.

great questions, yoroy!

aaron's picture

great questions, yoroy! after discussion, i think we'll simply add an admin-defined weight to the tabs, so one content type might have the 'upload/add' field element first, whereas another might have 'add existing from local' first, and another might have 'external embed url' for emfield weighted first.

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic

I'm thinking it would be

yoroy's picture

I'm thinking it would be good to have 1 (max. 3) most likely scenario(s) for 'adding media'. I understand you're basically trying to build something that 'does it all', and code-wise that's probably a great goal.

But we should try and cater the workflow and ui for the most likely task(s).

Not that I can authoratively say which ones those are but…

  1. Adding a file like you add an attachment to an email… differs from
  2. Differs from uploading a video that will probably be the main 'body' of your node.
  3. And then there's that whole 'advanced; route of adding images, generating thumbnails, managing metadata etc.

… just thinking out loud for now…

we're right with you! a

aaron's picture

we're right with you! a module would implement hook_media_user_files_select($node_type, $field, $uid), which returns:

<?php
array (
 
t('My files') => array(
   
t('YouTube') => array(
     
'files' => array(
       
'uri' => uri,
       
'filename' => filename,
       
'meta' => array('title' => title, 'author' => title, 'duration' => duration, //... ),
     
),
    ),
   
t('Flickr') => array( // .. ),
 
),
 
t('Embed') => array(
   
t('Remote') => array(
     
'form element' => $form, // FAPI element array
   
),
  ),
);
?>

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic

Haha thanks, but that

yoroy's picture

Haha thanks, but that doesn't tell me anything at all I trust we're talking about the same though :)

Ok here is the first draft mockup

Manuel Garcia's picture

I had to asume a lot, hope this is what you guys had in mind... let me know if anyone wants the svg also (used inkscape).

Wow! Great work, Manuel!

aaron's picture

Wow! Great work, Manuel! You're on the same wavelength as what we're talking about here in NYC!

Thanks for visualizing this concept so well. This will go a long way towards helping people understand where we're going with the media sprint.

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic

WOW²!!

skilip's picture

WOW²!!

Cool.

NikLP's picture

Impressive. Most impressive. (I'm your father, yadda yadda etc.) If this can get in core for D7 (or at lease something for asset management) I can stop swearing in my sleep about it.

Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP

Aaron's new concept

arthurf's picture

Here are some ideas from Aaron

http://24b6.net

Amazing!

gusaus's picture

Pretty amazing how much can get done when you get some Ninjas in the same room. Also great to have some collaboration with the Dojo. Manuel certainly will be earning some belts and we look forward to others getting involved.

A lot of recent inspiration has come from Kaltura -

This wiki contains a lot of (Drupal and third party) examples and meta discussions - http://groups.drupal.org/node/16846

More soon...

Gus Austin
PepperAlley Productions

Gus Austin

Prototyping

arthurf's picture

Here's some code based prototyping- obviously not done, but gives you an idea that we can move in this direction quickly:

http://24b6.net/2009/01/09/media-sprint-prototyping


http://24b6.net

woa that was quick

Manuel Garcia's picture

Good job guys!

FWIW, I ran into a problem

IceCreamYou's picture

FWIW, I ran into a problem recently where I wanted to use upload.module functions, but I couldn't because I was dealing with a form, not a node. It would be nice if the form items/upload code was abstracted so it wasn't dependent on nodes... at the least, it would make uploading to comments easier.

Yoroy, is pointing out a

Bojhan's picture

Yoroy, is pointing out a very critical issue in the UI. As you push for a generic interface, you lose sight of what is the most important upload functionality on the majority of drupal sites. Would scenario 1 be most important? As this module is probally mostly aimed at all the other scenarios.To build further on yoroy his thoughts. Can you give us 3 scenario's and rank them on importancy, then we can give a shot at making an interface that represents this.

"We're hijacking the upload elements of node edit/add forms, replacing it with inline tabs."

Will this mean that, we have another very heavy UI element on node/add? You should really concider a way to hide it (pop up/loading inline like hierachal select), untill someone needs to upload - this has a huge impact on the (non)usability of this node/add page.

To give some feedback on the mockups, looks good - think a bit out of the box of simple lists of files (think of various scale scenarios - which one do you want to optimize for?) and 2 tabs (vertical and horizontal) in the real estate you'r in is hard to achieve without making the tabs to small, with that losing visual balance.

Good point Bojhan

Manuel Garcia's picture

To give some feedback on the mockups, looks good - think a bit out of the box of simple lists of files (think of various scale scenarios - which one do you want to optimize for?) and 2 tabs (vertical and horizontal) in the real estate you'r in is hard to achieve without making the tabs to small, with that losing visual balance.

I went ahead and rethought the tabs placement, what do you guys think?

This looks great! In the

Flying Drupalist's picture

This looks great! In the previous images it wasn't clear what the relationship between primary and secondary level tabs are, but now it is. :)

Ribbon

SteveBayerIN's picture

The ribbon style UI really works great here.

Hm

NikLP's picture

I actually prefer the layout of the first mockup. Perhaps moving the left hand tabs into the main area of the UI would clarify the relationship? I have never been a big fan of multi level "navigation" like that myself.

Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP

Drupal can learn a lot about

zroger's picture

Drupal can learn a lot about admin interfaces from this video, http://binarybonsai.com/2008/08/30/interfacing-with-habari/

Specifically related to this topic check out the media handling starting at 2:50 in the video.

Some key points:
- There are "silos" of media. Each is a repository that knows how to handle its own media in a common manner. Files uploaded to the site are represented by a local site silo.
- The interface is clean and consistent for each silo.
- Simple integration with the textarea
- Configurable by the admin

Not saying we should duplicate this approach, but I think we can learn a lot.

Prototype take 2

arthurf's picture

I worked a bit more on the prototype- it doesn't reflect manuel's second revision, but gives a good idea where things are headed- http://www.24b6.net/2009/01/10/media-sprint-day-3


http://24b6.net

Scalability suggestion

Manuel Garcia's picture

I hope there's time for suggestions still, here it goes:

Think of a site with thousands of files already uploaded. Our current UI would FAIL miserably in this scenario, even if we allow sorting on the file lists. A way around this would be to add a "Search" tab within existing files. Perhaps I'm jumping ahead of the project, and this is something that other modules could plug in...

Either way I went ahead and created a mockup to illustrate the idea:

One step further?

Manuel Garcia's picture

Perhaps it'd be best if we could just have this as an ajax filter text-field on every tab also, like this:

Shouldn't the files list be

Flying Drupalist's picture

Shouldn't the files list be handled by views?

not to late

arthurf's picture

Yes, we're talking about:
* search box for filtering files
* search box which can filter by multiple file types
* saved searches per user which appear as drawers per user

Among other things. We will want to support views for this as well as implementing hooks so that modules can define their own searches/sorts


http://24b6.net

Ability to customize?

gusaus's picture

This probably is a bit further down the line, but it would be ideal to provide users with an easy way to customize the interface - to borrow from Kultura again -

The Kaltura Contributor Wizard (aka CW) is a customizable wizard enabling end users to upload media. The wizard supports multiple file uploads, webcam and microphone recording and importing media from external sources (e.g. YouTube, Flickr, etc.). The wizard lets developers add their own media provider flex modules.
http://corp.kaltura.com/wiki/index.php/Contributor_Wizard

The CW can be configured using an xml configuration file. The CW configuration file defines different customization aspects:

  1. List of media providers (e.g. file upload, webcam, import from different sources) available to the user.
  2. Graphical skinning and locale of the different parts of the wizard.
  3. Parameters defining the behavior of the wizard such as the default media provider.

Also posted a few screengrabs/notes of their UI - key features I really like is the ability to preview (listen, view), and select multiple files:
* Audio - http://www.flickr.com/photos/pepperalley/3131201999/
* Photos - http://www.flickr.com/photos/pepperalley/3132056984/
* Video - http://www.flickr.com/photos/pepperalley/3132051144/

Another great feature would be to have the ability to embed the uploader as a widget on other sites.

Gus Austin
PepperAlley Productions

Gus Austin

Rebumped mockup

Manuel Garcia's picture

I've taken in as much as I could, you monsters are amazing... I can barely keep up with all the great features you are able to pull off!!

Of course that is making participating in this that much more fun, so let's make it as useful as we can - if anyone has ideas ... now is the time!!

Different types of media will need different information being displayed to the user, and hence the layout may vary a bit to fit those needs. But step by step, let's first narrow down overall functionality and features, then worry about what information will we be displaying for each type of media.

OK, so here's what the GUI layout mockup is looking. I've added a red border on the things that I think could be what you meant, though I'm not sure about. This is only for a section of course, but you get the idea (I hope).

modal/lightbox

mfer's picture

I like the work that's gone on so far. It looks fantastic and I'm up for helping this effort.

One of the things I'm a fan of is a clean and simple interface. Have you considered using a modal window to place the browser in? This would keep it out of the way of the user until they decide to use it.

Also, have you considered adding the ability to place these files inline in text fields?

Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.superaveragepodcast.com
www.mattfarina.com

Matt, Aaron and the gang

smerrill's picture

Matt,

Aaron and the gang have definitely been thinking about using this both to provide a reference-type field and also to allow placement of media inline.

Steven Merrill

We should definetly consider modal/popup

Manuel Garcia's picture

The way this has been growing, we should definitely consider either modal window, or a popup window, otherwise we would be cluttering the node-edit form quite a bit.

Also, we've been discussing (on #drupal-dev) about going back to having tabs on the left stacked vertically, since we are having to go too far down the rabit hole with so much info. This would free some space up in the main area, and if we do go modal/popup, it wouldn't be an issue of space horizontally.

Degredation

smerrill's picture

Another thing that we've been talking about a decent amount around here is that while it looks like the UI will be heavily JS-based, we still want to provide a basic form that could become multistep when the user does not have JS enabled which would allow users to upload a file and select a formatter.

We'd love to eventually see some portion of this get into core, and having it function at least somewhat decently without JavaScript will be important to get that to happen.

What about a slidedown? Both

Flying Drupalist's picture

What about a slidedown? Both popup and modal interrupts the node edit process, while a slidedown should more clearly add to it.

Load the form upon request

Manuel Garcia's picture

Imho (not a developer), whatever we do, it'd be best if we only loaded the form when the user requests to access it. If possible of course...

.

IceCreamYou's picture

Some people really hate popups/modals. I like them, but merlinofchaos told me on IRC that he got too much negative feedback when he was considering them for the Views 2 API.

I want to also throw in that feature bloat should be avoided where possible. At the least, a lot of this should be made optional, as the admin decides. Personally I run a site that pretty much never needs more than one upload per node, if that; the proposed interface looks pretty complicated for something that users in my case would expect to be so simple. manual garcia's latest mockup, for example, has four main tabs, each of which has four subtabs, each of which has three subtabs. That's 48 screens the user has to look at where before there was only one; and with saved searches that number will grow.

Admittedly, the current design does look easy to understand.

How about something like this?

Manuel Garcia's picture

OK, new day, new start, I've rethought the whole layout, I think it is simpler now:

I've separated into two parts, one would show when you expand the fieldset of attachments, showing you what is currently attached to the node, with a button to add more files. Once you clicked it, ideally through an ajax call it would expand the rest of the GUI.

I have substituted the tabs by select boxes where all the listing and module inputs would show up, and these would (through ajax) affect what the list shows. This simplifies the layout and I think would fit in nicely right there in the page, without need to use small text-sizes.

I've also added the check-boxes so we can add several files at once, and the advanced help icon, which I would be nice to have :)

As always input is very welcome!

I think there should be room

Flying Drupalist's picture

I think there should be room for a thumbnail once you click on each file. Or perhaps a tooltip like thumbnail on hover over each file? But that interface looks fantastic.

Agreed

IceCreamYou's picture

Much better! I agree that there should be some way to see a preview of images though--a hover thumbnail sounds fine to me. I'm a little confused about where the upload field actually is though! I only see a field to filter existing files, not to upload new ones, and I think the actual upload field should have the emphasis. I would say have two buttons on the first part: Upload New File and Browse Existing Files. The Upload button can show an upload form and the Browse button can show the search form that you've presented here.

Browse title or tab

SteveBayerIN's picture

If the upload button leads to a new form window rather than appear in the same window, the window just needs a title of 'Browse' to the left of the advanced help icon so that the user immediately knows they are on the window for browsing files.

As IceCreamYou said, if clicking 'upload new' causes the upload form field sets to replace the browse form field sets in the same window, a new tab would be best.

This is a much better

joshmiller's picture

This is a much better design, and I think it is much more intuitive. Have you thought about how "embedded" media works? I bet there will be a simple tagging system much like token functions now. So what if there was a column that said "tag" and the "help" explained that you can place the tag in any text field and that media would be embedded there.

So for your theme-structure.pdf, the tag might be "[embed:3456]"?

Is this idea too far out there?

MJ

Embeds = file

arthurf's picture

The underlying changes that are happening in the resource module is that we are allowing for embeds to be files. For example, an embedded youtube video would be represented on the local filesystem as youtube://path/to/youtube/video. What this means is that we can manipulate local and non-local content in the same way- ftp, s3, youtube, etc.

The tagging piece is a good idea and is implemented in views already- would be good to have that as part of the interface site wide. I'm not quite sure how it will work here, but we'll get there


http://24b6.net

Some resources I found

joshmiller's picture

Some resources I found regarding inline (WYSIWYG) media placement:

Just for the record...

Josh

Multiple layouts will be possible, also formatters!

arthurf's picture

Please note- since the display of files is inside of a form which is determined by the module which is presenting the resources (aka files), each module can determine the display of the files- film strips, lists, thumbnails, etc. Basic layouts should be included in the Media module itself. Further, since these are forms, a form_alter() can change the theme of each drawer (the sub tab layer) display. So there should be flexibility.

Also, we need to take into account the formatter options- once a resource (file) is selected, there are formatter options which are displayed. Please see: http://24b6.net/2009/01/11/media-sprint-end-day-3 which gives a hint of how this works.

Note also that I did the current layout with the tabs/drawers setup- that is just how it is currently done, but it can change- I'm just focusing on other areas right now. What is interesting to note is that all the data that is driving the display there is based on data pulled in via hook. These are simple to write and fast to implement. Took me about three minutes to create a media mover file drawer pulling files out of my database.


http://24b6.net

Is this discussion still

scroogie's picture

Is this discussion still happening here, or is there another place for it now?
I think you should focus a bit more on filters / categories / tags. In my opinion everyday-users don't care about filenames. It will be CIMG109293 and DC198239 all around the place. I administer a site where the editor uploads hundreds of pictures per month and none of them has a sensible filename. Searching by filename is actually quite unimportant, if not even negligible. What is important is searching by terms/tags of the image, terms/tags of nodes that the image is related to (embedded, referenced, attached), Title, Date it was uploaded, etc. I dont see an opportunity to represent that in the UI.
I think thumbnails are an absolute must. The whole interface should be focussed on previews. It should probably look like Explorer on Windows, Dolphin on Linux or Finder on MacOSX. Some screenshots:

http://images.apple.com/euro/macosx/features/images/gallery/finder_galle...
http://4.bp.blogspot.com/_zDPqioLuxns/SQSLfnz_2CI/AAAAAAAAADs/qjRiv2A_Xp...
http://www.windowsvistauserguide.com/vista2/windows_explorer/Group_by_da...
http://images.apple.com/euro/ilife/iphoto/images/organize_img3_20090106.jpg

Perhaps you could introduce "View modes" like in the above filemanagers, but regarding the default view: My users don't give a *** about file size or dimensions of a picture. They know it's a picture or video, and they want it on the page, that's all.

Those are important points.

aaron's picture

Those are important points. It didn't translate so well from our discussions in the offices to the current mockups, but you can see a hint in the last couple of screenshots that say 'File information'. What's really intended for that area is metadata, which includes the information you're speaking of.

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic

Thank you so much for bringing this up!!!

justinlevi's picture

Scroogie,

After reading through this thread I was so glad to see someone bringing up the idea of thumbnail previews. I think the UI mockups done by manuel have some potential, but a filesystem grid view is a must. Filtering by extensible meta data would be a great feature as well. I work with a lot of photographers and most of the JPG images delivered have IPTC metadata embedded. Would be great if admins could utilize information like that in the filtering.

Also, what about sticking with the file system metaphor a bit further and actually give the user the ability to create folders to group a bunch of files together for organization purposes? Also, what about creating drag/drop ordering functionality? Think iphoto as a means to create an order to a slideshow or if anyone is familiar with slideshow pro director, this is what they do.

And another thing...

justinlevi's picture

I've also been thinking about suggesting to keep anything but the core organization and node integration features from the UI. Building a framework that allows for icon/menu/link feature additions, like the ability to crop images, would be great as long as they are optional. The TinyMCE approach to adding/removing icons for specific functionality is a very good UI approach.

I can see many users getting confused if too many options are presented to them and many users may not need to crop an image or upload a video, etc.

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week