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.
Attachment | Size |
---|---|
media_sprint.jpg | 931.1 KB |
Comments
Basicly avoid adding
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
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?
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...
I'm on it guys... creating a 1st draft mockup in inkscape... standby
Awesome! We definitely need
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
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
From http://groups.drupal.org/node/18063:
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!
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
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…
… just thinking out loud for now…
we're right with you! a
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
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
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!
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²!!
WOW²!!
Cool.
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
Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP
Aaron's new concept
Here are some ideas from Aaron
http://24b6.net
http://24b6.net
Amazing!
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
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
http://24b6.net
woa that was quick
Good job guys!
FWIW, I ran into a problem
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
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
I went ahead and rethought the tabs placement, what do you guys think?
This looks great! In the
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
The ribbon style UI really works great here.
Hm
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
Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP
Drupal can learn a lot about
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
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
http://24b6.net
Scalability suggestion
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?
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
Shouldn't the files list be handled by views?
not to late
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
http://24b6.net
Ability to customize?
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:
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
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
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
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
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
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
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
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...
.
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?
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
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
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
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
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
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
http://24b6.net
Some resources I found
Some resources I found regarding inline (WYSIWYG) media placement:
Just for the record...
Josh
Multiple layouts will be possible, also formatters!
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
http://24b6.net
Is this discussion still
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.
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!!!
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...
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.