Create issues for UI decisions reached, but not yet implemented

Hi everybody

The upcoming days I’ll do as much research on this project as I can to prevent myself from reinventing any wheels. I also found a list of features that should be covered out of the box, that’ll certainly come in handy.

I’ll keep you updated!

Great! Thanks for jumping on board!

The Media module is also the focus for a GSOC project, with jmstacey leading up that effort.

I'll take a look at this issue in the next day or two to make sure we get you the information and resources you need to be helpful. Meanwhile, there are some GUI mockups at http://groups.drupal.org/node/18085 and some early prototype demos floating around:

http://24b6.net/2009/01/09/media-sprint-prototyping
http://groups.drupal.org/node/20506

Thanks for the links! I’m watching the March Madness session video at the moment (last link).

The video from the second link doesn’t seem to load, unfortunately.

http://recordings.dimdim.com/view/dimdim/9b9b9120-6b8e-102c-81fe-0030489... seems to load

But isn’t that the video from your third link? (It’s the second I have trouble with.)

ah, that's a shame. yes, i see what you mean now. looks like none of his videos work right now. i'll ping arthur about that.

Alright. Based on everything I’ve read an seen (videos and interface sketches) from this project the past days, I’ve come up with some first mockups.

I’ve uploaded them on Flickr:

• Media library — empty folder
• Media library — thumbnail view
• Media library — list view

Obviously, these screens aren’t all that need to be done. The ones currently on my todo list:

• Bin
• Add files from computer
• Add files from an external source
  (Question: what sources do we need to support? Is there a complete list somewhere?)
• Enlarged image
  (I’m thinking about tabs for extra options in this screen. For images, e.g. Crop image. Other modules could then add extra tabs as well.)

What are your thoughts on the mockups I posted?
Also: are there any features/pages I overlooked?

these are great mockups! we're oohing and ahhing over them at #drupal-openmedia right now!

some initial thoughts:

we need to deal with metadata on there somehow. original ideas were to have another pane at the bottom that could expand to display metadata, such as title/description/youtube-username/duration/etc. also perhaps formatters, so the editor could determine the imagecache setting (if allowed for that field).

external sources: this gets confusing when we consider a user might add a file existing from the local server, s3, or even another youtube video they've selected in the past. in my mind, they would be presented with a file listing as your thumbnails at http://www.flickr.com/photos/mverbaar/3632702590/in/set-72157619245872526/ in this case, but how do they get there from the first selector screen (upload/external)?

i love the trashbin idea! we're talking about how to implement that as a 'trash://' stream (storing old location for eventual restoration, manually emptying the trash or optional periodic flush on cron, etc).

just some thoughts. jmstacey has more; he might chime in as well.

looking closer, i missed that the first shot was for an empty folder. makes sense now.

to answer: "Add files from an external source
(Question: what sources do we need to support? Is there a complete list somewhere?)"

there's no complete list, and never will be. the api is flexible, allowing new stream wrappers to be created as needed, such as for youtube, flickr, amazon s3, a cdn, whatever.

things get twisty in some ways too -- i'd love to hear if you have thoughts on how this might be approached from a UX perspective:

using youtube as an example:
do we show just youtube videos added by a user? all youtube videos that have been added to the site? all youtube videos available? (obviously we'll need a pager for these as well).

same w/ files stored on a CDN.

and how to handle deletes? do we always allow a file to be deleted/trashed? (assuming the stream allows in the first place). but how do we designate for files not owned by the user and/or server? they would probably need to be marked read-only maybe somehow. (user might have 'delete own files' but not 'administer files', and youtube stream might allow files only owned by the 'drupalmedia' drupal user to be deleted/added as well, so the perms would sometimes inherit from the 'folder', using a filebrowser analogy)

@mverbaar, the mockups look fantastic!

I've attached the conversation that Aaron and I had in #drupal-openmedia. As you can tell there are some consistency issues that we're struggling with, so your input will be extremely helpful.

Intresting, I think you are on the right track with the left tabs. What would be the blank state? When nothing is in the libary yet? I saw your no content, but what if there are no folders either?

subscribing

And I need some code to review (where?). My primary intentions should be clear, but anyway: Client-side editor integration, UX, administrative UX, flexibility, scalability, etc.

Thanks for all the excellent feedback everyone! I’ll try to answer your questions here.

What would be the blank state? When nothing is in the libary yet? I saw your no content, but what if there are no folders either?

See this mockup: empty library. Basically the same as the empty folder state. Might be a good idea to include an introduction screencast on that page as well.

While reading the IRC conversation jmstacy posted (thanks for that btw, it was very helpful), I noticed Aaron thinking the folders were generated based on meta data. I actually intended them as folders you create manually. Finding files by tags or meta data could be done with the search box. Tagging would happen in the file settings, a tab on the screen you get when you enlarge the image ... maybe I need to change that icon to something like this as well, that way it would apply better to other file types where a user would be taken to the settings directly instead of an enlarged image. Although, a "listen to this sound" and "watch this video" option might be handy too. (Working on a mockup for this.)

I’ve made some quick mockups for adding Flickr (an external source) photos to the library:

• Viewing files from a person on Flickr
• Viewing files from a person on Flickr (results)
• Media library — thumnail view with an example file from an external source

The same principle would apply to viewing files from groups. The search box would find all photos by tag or full text, like on flickr.com itself.

About the deletion of files. I thought of it like this: files from external sources are like bookmarks/shortcuts. Like you could create a bookmark in a web browser, you could add a bookmark in the media library for e.g. a photo on Flickr. So if you delete the bookmark, the photo gets deleted from the library but not from Flickr.

The same for editing a title; you can edit the bookmark’s title but the title on Flickr stays the way it is.

The way I see it, people just want to add photos from Flickr to their site. Not manage their complete Flickr account and everything with it through their Drupal installation. On the other hand it would be kind of cool to manage all your media related accounts in one place, though; world domination ;) What are other people’s thoughts on this?

Just posted: pager

Wow! Great work!
Few questions/suggestions:

Will nested/subfolders be supported?

What about moving files between folders?

Does editing the title change the file name?

Regarding the folders metadata vs real file structure question:
I sort of like the idea of dumping all files into a single directory and handing structure with metadata. This way, references are much less of a problem when moving/renaming/managing files (almost a non-issue).
BUT, the way I understand it, hook_file might handle references anyway. In that case, I think I would prefer a REAL folder structure.

Will nested/subfolders be supported?

I think they should be, yes.

What about moving files between folders?

Drag ’n drop files to the folder tab on the left or via the file settings (select box) is what I had in mind.

Does editing the title change the file name? [...] I think I would prefer a REAL folder structure.

That would probably be the best way to go. That way the files would be well-organized on the file system too.

The following mockup shows how the media library could integrate with the node submission form. Behold!

Does editing the title change the file name? [...] I think I would prefer a REAL folder structure

From a coding perspective it will depend on the integrating wrappers. The core (public, private, temp) wrappers would implement a "real" rename, but some integrating modules such as YouTube might not have this functionality. While you might be able to give the resource a new name, it's true URI might not change (unless the wrapper had access to YouTube's API). In cases like that, one possible behavior could be similar to shortcuts.

About the deletion of files. I thought of it like this: files from external sources are like bookmarks/shortcuts. Like you could create a bookmark in a web browser, you could add a bookmark in the media library for e.g. a photo on Flickr. So if you delete the bookmark, the photo gets deleted from the library but not from Flickr.

Behavior will be different depending on the kind of resources being dealt with and the way in which they are implemented. For example, with the core wrappers (public, private) I would expect file deletion and trash to work just like on Windows/Mac/Linux. I would also expect file uploads to work. Other wrappers such as flickr might have two modes of operation, again depending on implementation. I would expect Bookmark/shortcut type behavior for flickr photos that aren't mine, but if I've entered API information I would expect changes, deletions, and uploads to actually affect my flickr account. So the specific behavior will really be determined by the integrating module.

The key is that we can provide this wide range of flexibility and behavior built on a common base (wrappers+file API) with a common interface (Media).

As much as I detest confirmation dialogs, we may need one when deleting items from trash or emptying the trash when a resource will be physically removed. We might also need a mechanism allowing the various modules to display a brief 2-3 second fading notification overlay for notes on special behavior, errors, and other messages. For example, trying to move a YouTube video to an S3 container will not work.

Re: Paging. I'd really love to do some lazy loading goodness, but it may not be the most feasible implementation especially with webkit bug #6656. Perhaps an optional Google Gears requirement down the road... drag n' drop images from desktop would be really nice too.

Big update.

• Empty library
• Start adding files
• Introduction screencast
• Folders, nested folders and files
• Create a live folder. This is something new I came up with, it behaves a bit like an RSS feed. Can be anything; YouTube channel, Flickr user, etc.
• Viewing a live folder
• Delete icon which appears when you hover on a folder’s name/tab
• If you hover on an active folder, the name gets a blue background which you can click to edit it.
• Edit a folder’s name
• Hovered and selected state of a file
• Hovered and clicked state of a file name
• Deleted file
• Add more files
• Choose files from computer
• Upload queue
• Choose external files
• Files added
• File options
• Edit metadata of a file
• Edit filename on file system (can be different from name in library)

As always, I’m very interested to hear what you think! There will probably still be things I overlooked and I’m still thinking about certain features/implementations mentioned in earlier comments.

These mockups are amazing. I really hope to see them implemented somewhen! Great work.

subscribing...

We're creating a library for Acquia Gardens, but so far it's not nearly as robust. How far is the development of this?

Let's talk about this some more at the sprint.

Just because this hasn't been linked here: #322287: Add file.module to provide UI for managing files. Just something to keep an eye on.

And, yes, great mockups!!!

I thought some more about uploading and adding from external sources.
http://www.flickr.com/photos/mverbaar/3674490525/in/set-72157619245872526

Feedback please :)

I like the screenshots, removing that level of complexity makes sense, I think in most situations.
I just thought of one where it doesn't: If you as an admin want to let your users select an image out of a predefined (by you!) selection. Then you (=admin) would have to add the files to the library (from the library!) and then let the users choose for instance on content creation. This use-case could be handled though, by treating existing files and folders on the webserver (in sites/default/files) as an "external source" (in which case that would probably have to be renamed). Then I could just upload an entire folder of images to my webserver (via FTP), and then add that folder as a folder in the library just like I add a Flickr album.
Just some thoughts...

@tstoeckler Good one. I think you’re right, we’ll have to come up with a better name for external sources.

I dont think you should remove the ability to upload from inside the media libary, its only adding an extra layer of complexity if you can only do it outside of the libary.

But why would you go inside the library to upload files, when there’s already an upload option at the node submission form itself?

It’s a bit like going to a library IRL while you already know they haven’t got the book you’re looking for.

At the same time it feels natural to me to upload stuff from inside the library too, but I’m having a little trouble thinking of more specific use cases.

The one tstoeckler mentioned is one, and I definitely think an upload option should be available in the library *somewhere*. I’m just thinking *where*, now.

I think this is tagged wrong, as its not showing up with other microprojects

"But why would you go inside the library to upload files, when there’s already an upload option at the node submission form itself?"

We've had similar discussions, which have discussed both possibilities. I *think* that a workflow might sometimes go like this: the editor wants a specific shot of a kid jumping on a trampoline. Goes to the library to find it, can't find it, so then wants to upload the desired image. I'd rather have the editor be able to do this here without having to figure out how to back up (which might end up with accidental and incorrect back button pressing, etc).

"I think this is tagged wrong, as its not showing up with other microprojects."

Changed the tag to #d7ux-microprojects. You can do this yourself by opening the Tags field set at the bottom of this page.

added #d7ux as well. what's the big idea using a hash for the tag? this is really confusing when adding the tag to an issue, as it's not the standard at d.o. oh, well.

oh wait, that's my bad. the hash is not any good; reverting. please change to the correct issue tags.

appears to be showing up now: http://drupal.org/project/issues/search?text=&projects=&assigned=&submit...

Changing Project to Drupal, so that it shows up in the regular Drupal issue queue. "Media handling" definitely qualifies as an "other" component.

At the moment I'm inclined to think that there should be a single point of entry. For example, a single button like "Attach Media" or "Insert Media" depending on the context. What about a top tab approach similar to Wordpress? Rather than dumping the browser on the user right off the bat, we could make it secondary. When the browser opens initially the user is put on a launch page with the available sources listed, such as

"{action} From: Computer, Flickr, S3, YouTube, Vimeo, Media Library"

{action} = Attach, embed, etc.

Some cursory workflow thoughts:
User wants to attach a PDF file to this node: clicks Attach Media which opens the browser launch screen. User clicks "Computer" and is presented with the typical upload form. PDF gets uploaded, and user fills in optional metadata if desired. Done.

User wants to embed a YouTube video via a wysiwyg editor. Clicks the appropriate button in the editor opening the Media browser. Clicks "YouTube." There are a few ways to go at this point. For example, simply ask for the YouTube URL, or present a browser to YouTube videos for selection with search, or both. That specific implementation would be left up to the module. User selects video and attaches it, filling in any metadata/attributes if desired. Done.

All Media, once it's been uploaded, attached, what have you, will end up in the Media Library. So, if you want to use an item that already exists, you would click on "Media Library" which would present a culmination of all resources currently in the system (i.e. all URIs in {file}) be it YouTube, flicker, and everything else.

The URI must be unique, so this method would lead to a higher probability of a conflict arising (i.e. user tries to embed a video that has previously been embedded, and thus already in Media Library). We could probably just handle this silently for the user. If there's nonstandard metadata already attached to the existing resource, perhaps a non-actionable note to the user that the existing resource and metadata will be used.

This is a very interesting discussion - I was wondering if any of you going to be at the Paris Drupalcon? It would be great to hear more about how/where this project is going. There's already a proposal for a 'drupal media' BOF:

http://paris2009.drupalcon.org/forum/drupal-media

Thanks so much for that link matkeane!

Meanwhile I’ve posted some updates on Flickr again. I added them to the set for iteration 3.

I’m working on a protype as well, btw. Is there a JS skilled developer in the house who can point me in the right direction on how to achieve this "sticky footer" effect? (Nope, it cannot be done with pure CSS. It’s practically like the sticky table headers, except at the bottom.)

Did a quick search for any fancy jQuery plugins for this but haven’t found anything so far.

Looked through some of the mockups in Flickr. Very nice. Note that it's common in Drupal to have forms that support an unlimited number of files per field. Some forms can easily have more than five file fields.

Come on Drupal community! We want this, let's get it!

Josh

That might be a good survey; What’s the highest amount of file fields you’ve ever used in a single content type and what’s the average? I personally have never used more than 2 file fields per content type. (How many files per field is a different story though.)

The current setup is not able to display tabs for 10 file fields, unless you have a really wide screen resolution. I’m going to do some thinking about that.

How about a selection element for file fields? It definitely cleans up the clutter.

#43: I wrote an article once (which sadly, I never published since I didn't have time to finish it before it got hopelessly out of date) that compared/contrasted the installations of 10 or 12 different CMSes, screen by screen. I used Paging module to go back and forth between the different CMSes, so all images were attached to a single node. This node had 47 images attached to it.

So I do think it's conceivable to have > 10 files here, although definitely not the common case.

Doh! You said file *fields*, not file *uploads*. In that case, I don't have an extreme example. :)

Excellent mverbaar! The selection widget looks great and allows for as many fields as is reasonable.

Josh

@mverbaar: so according to #40 mockups, you are NOT planning to allow uploads from the media widget?
I think that is a mistake... I agree with aaron in #33. What if the user wants a picture, goes to the media library to find it, but can't. So, the user should be able to upload it to the media library right there, without having to back out and start again. This way, the use can also better specify where to upload the file to (what folder).

I know it is not easy to fit this feature in, but from a usability standpoint, I think it is essential.
Otherwise, GREAT work. I can't wait to be able to use this stuff!

I disagree with arlinsandbulte.

-1 on making the media manager handle uploads.

@joshmiller could you give an explanation?

I first of all don't see the trouble in doing it. And as aaron said, its a common task to want to do - by not handling it, we are ruling out a pretty large use case - for no convincing argument.

I think it's a question of consistency. If you allow adding files from remote sources in the media library, you should also allow uploading files from there. However, it's not very logical either, because then you have two different places (the media library and the form field) for the same thing. Have you thought about replacing the input element completely? E.g. having the media library in a tab on the node page? Or perhaps you could display three buttons that open different views on the form, so you don't clutter the ui.

@ #48, #51:
Have look at the mockups from iteration 3 if you haven't yet. The upload functionality is back but only for files from computer, not for external files. I think, for external files, the "synchronizing folder" approach is more logical.

As you can also see in the mockups, I indeed started thinking about displaying the library as a tab next to "content" and "meta". It would be a lot cleaner, especially for situations with multiple file fields.

Sub

Some more small updates:

• moved the upload link to the top of the screen
• what the user will see when certain file types have been hidden because they are not allowed by the file field (thanks Aaron for pointing this one out)
• there should probably be an option to show the unallowed files
• when viewing files of an external source, perhaps a link to the source itself is handy/needed? (if applicable. so, not for Amazon S3 but for Flickr accounts, for example, a link to flickr.com/photos/[user].)

Looks great!

@mverbaar I am a bit concerned with the general direction of this interface, you seem to be adding more and more - where the essence of the interactions seem to be pushed back.

@Bojhan I haven't really added anything since iteration 2, actually. I’m am merely re-ordering at the moment.

Interactions I’ve been trying to improve in iteration 3 include:

• Flow between node submission form, file fields and media library (largest task, been mostly busy with this one)
• Dealing with file restrictions
• Displaying certain errors and notices (only a mockup for one of these at the moment, working on more)
• Upload progress from inside the library (needs to be simplified/shortened. no mockups for this yet in iteration 3, except for the position of the upload link itself)

If you see things that you think are completely heading the wrong way — please go into greater detail. Don’t just post “I’m worried”, because that’s not really helpful to me.

So with that I mean that you are bringing information space, action space to closely together. Remember my presentation, wher I layed out the conceptual model on Views2? If you do the same to the current interface, you will see that uploading is now spread between seeing the content and viewing actions.

You need to design a framework, where actions such as uploading have a definitive place, and looking at the content has its place to including its actions.

I dont neccairly see, why the allowed, selected and types should be so prominent in the media libary?

I dont neccairly see, why the allowed, selected and types should be so prominent in the media libary?

After you selected a certain file field, I think you need to know how many and what kind of files it allows/supports before you actually start browsing for files. The selected files counter would then be used to see if you’re exceeding any limit while selecting multiple files.

I totally agree about spreading the content and actions though. I’ll keep on experimenting with that.

This is exactly why I asked to put a post on d7ux.org btw, the media library definitely needs more feedback from UX people but unfortunately it doesn't seem to get much. Big loads of feedback from developers (and I’m grateful to them), but those are from a completely different point of view. I need both in order to be able to create the 'perfect' interface.

mverbaar - any new iterations to share or news to share?

I’m working on iteration 4 but the past few days I haven’t had much time for it. I have reserved some hours for it this week though, so expect new mockups soon.

I’ve added the first few mockups for iteration 4 to the Flickr pool. Nothing revolutionary at the moment, just a quick update on what’s happening. Some of the mockups are still very experimental, see notes on Flickr for details.

Drupal Media Library — iteration 4 (set)

Todo:
- Adding/editing folders/external sources
- Viewing files (e.g. enlarge an image or play a video)
- Uploading files
- Dealing with file restrictions
- Interaction with content tab/form

Wow, I am looking forward to see this! amazing work!

I came up with an idea for the file editing part this weekend. We had list view and thumbnail view already, now I’m thinking we might need a "single file view" too. This is where you view one file at a time, switching between files with "previous" and "next" buttons. (Still thinking on what's previous, what's next.)

The file editing form is located in this single file view. So whether you’re viewing files in list view, thumbnail view or single file view; clicking the "edit" link will always take you to the single file view for that particular file (with, in that case, the "edit" tab already open).

I’ve also tried to make the "list files" and "add file" actions (tabs) look more like the existing "list [menus/taxonomy/content/etc.]" and "add [menu/vocabulary/content/etc.]" parts of Drupal.

Have a look at the mockups:

• List view
• Thumbnail view
• Single file view

Clicking "edit" in either one of these views takes you to this screen.

Your thoughts?

I posted some comments and notes on Flickr.

Biggest confusion for me was the fact the buttons on the right (save, preview, publish) were node-related, and not (as I expected) file-related. I understand you are working in de media tab of a current node, but still doesn't one expect do be in a media library and the context should be the media you are browsing?

I’m working on another idea at the moment; having "media" as a tab in /admin/content (next to "content" and "comments") instead of above the content creation form. It could be a solution the the confusion askibinski mentioned.

This is what I’m thinking of right now: http://www.flickr.com/photos/mverbaar/3781978754/

Main difficulty with this is how to let it interact with the content creation form.

What do the developers think about this? I’m thinking, the way we have nodes and comments now, we could have files; with paths like file/fid, file/fid/edit. The add/edit file form would be pretty much the same as the content creation form; having a title, the file itself (instead of e.g. a node's body), taxonomy, revision information ...

I’ve started working on the prototype and put up a first snapshot. (Note: tested in Safari and Firefox only.)

At the moment the prototype doesn’t really do anything, so don’t expect too much of it yet. You can play around with the thumbnail resizer though :P

I’ll try to work some more on it this week, I’m hoping to post another snapshot somewhere this weekend.

Subscribing. Would love to help out with this if there is a good place for someone jump in and help out. Let me know what (if anything) you need help with.

I have put up a second snapshot.

I was hoping to finish this prototype before DrupalCon Paris but I’m afraid that’s going to be difficult.

Perhaps anyone is interested in a small prototype sprint at DrupalCon? If so, please contact me.

I was thinking; The folder panel takes a lot of space. (About 25% of the screen on a 1024 px wide resolution.) Perhaps we should eliminate the panel and display the folders inline.

The breadcrumb would then display parent folders when you’re in a sub folder. (The media library beeing the parent folder of folders created by users.)

Mockup

I like the "inline" folders idea, but I think the folder panel provides a better structure overview...
How about this:
Collapsible or resizeable folder panel while STILL keeping the inline folders?
This essentially emulates Windows explorer, providing familiarity for less savy users familiar with navigating folders in windows. (I am a PC guy, but I think Mac folder navigation is similar, No?)

Great work, mverbaar!

I also like the collapsible idea.

But I'm also wondering about all that white space under "Attach files" is that by design or will the images expand under it?

Subscribe. Anything we can do to get this in before freeze?

I didn’t get any responses about my proposed sprint at DrupalCon. Don’t know for sure if there are any other media library related gatherings in the near future either.

So still working on the UI by myself at the moment, which ought to be “ready” to implement very soon.

I’ve mailed Aaron with some similar questions but didn’t get a reply so far.

@mverbaar: i don't know if i got any e-mails from you, sorry. when would that have been? what specific questions do you have?

fyi, we are planning a media sprint in nyc, probably in late october. this work will be highlighted there, and i hope to get a good chunk of the ui in place by then.

thanks for all the great work!

fyi, we are planning a media sprint in nyc, probably in late october. this work will be highlighted there, and i hope to get a good chunk of the ui in place by then.

Ah ok. I’ll do my best to finish the current iteration somewhere this month then :)

Subscribe

The second snapshot looks great. How does the Attach files button in the top right differ from the add files link at the bottom?

Is this a code-freeze exception, or is this turning into a separate module... or... is this getting shoved out to D8?

We could user-test paper mock-ups if it helps?

Speaking to catch on #drupal-usability in IRC. He said it's unlikely this is going to get into 7, he said, "Unless someone magically comes up with a fully functioning patch and it gets in as a late exception."

There are as yet no patches for this. The code "slush" has started but only allows usability improvements and no new features. I don't know what this means for the Media Library, as it would be a significant usability improvement, however it is a new feature- and not part of Dries's exceptions list.

Could this be a module? I'd hate to see it pushed into Drupal8... when this would be a great addition to 7.

I just wanted to bring some big-picture context to this thread (and catch didn't want to bring bad news). I had seen the comps in Flickr (through yoroy's yahoo pipes http://pipes.yahoo.com/drupal/d7ux ) and wondered about it. This needs a champion, it needs the involvement of a developer. ASAP.

Else... it needs re-thinking. (module?)

This is all going into the Media module, which has been in development with this usability in mind since last October. It will provide an API for creating a robust GUI for editors uploading media and other files onto their server. The intention of the original roadmap was to get Stream Wrappers in core for d7 (which happened!), and to get this as-to-yet-be-written API into core for d8 (fingers crossed), but available as a module for d7 (and maybe d6). This was based on the expectations of the original group coming together for code sprints throughout the year beginning in January and continuing through at least the near future (the next being on October 23-24 in NYC).

I still believe, based on the combination of the fact this is all volunteer work, there are only so many hours in the day, and, that's just the way open source/drupal works, there's no way this is getting into core for d7, especially considering we're in the midst of a code freeze. Even if someone wrote a "magic patch", it has to be vetted through the usual process, which can easily take weeks for a small patch (the Stream Wrapper patch had active development over the course of a year, and the File API patch before it was a year and a half in development).

This issue, by the way, already has many champions, and the involvement of many developers. Though more are welcome: join the Media group if you're just coming on board!

signup for the sprint in nyc is at http://groups.drupal.org/node/26824 btw... :D

How does the Attach files button in the top right differ from the add files link at the bottom?

‘Attach files’ sends the selected files to the file field, ‘add files’ lets the user upload new files into the current folder. Your confusion (and I bet you’re not the only one having it) is totally understandable, as the interface got a bit messy again.

I’m in in the procress of simplifying it, I’ve uploaded a sneak peak for you to see where it’s heading. Note that I’ve renamed the ‘add files’ link to ‘upload new files’ and moved it to the bottom right of the page, next to ‘add new folder’ and ‘add new external source.’ I think this will help people understand the difference in functionality better. What do you think?

I'm going to move the version selector to 8, just so it's clear that this isn't for D7, since we're now feature-frozen.

I'm curious though why we don't just move it to the Media module issue queue? Is it to get additional eyeballs on it?

Well it *was* in the media issue queue once. #37 moved it, hoping it would make D7 core. I guess it belongs back in the media queue now, as this indeed isn’t going to make D7.

@mverbar,85: the sneak peak you linked to looks good and seems clear, but I wonder if instead of "Attach files" you could just say "Done".

I would think 'Done' is what users would be expecting in most cases, and perhaps the choice of where to attach files could be moved somewhere else (otherwise people might get confused).

I believe it’s common to have buttons describe what they do, like ‘save configuration’ and ‘update.’ ‘Done’ doesn’t exactly describe what you’re done with, so that might even be more confusing. ‘Attach files’ describes is well I think, you ‘attach files to a certain field.’

I completely agree about the choice where to attach files. In updated mockups, the secondary tabs are used for this. See http://www.flickr.com/photos/mverbaar/3930858601/in/set-72157621994336405/

A couple things:

1. Regarding 'Done' vs. 'Attach'

The reason I thought 'Done' made more sense was because I was expecting a different use case which is more similar to how Wordpress does things: click on 'Add an Image' button above the body edit field, a popup allows you to select an image, and then you'd click 'Done' when you were done with the action you choose (add image). Now that I look at the Wordpress system again though, I realize that even they use a descriptive 'Insert into Post' button instead of 'Done'.

I also re-read this from the beginning and agree that 'Attach' seems like an appropriate term.

2. Uploading new files

I like that in the most recent versions the 'add new stuff' operation links have been placed close to each other. Previously it was hard to find the 'Upload new files' link since I expected it to be near the 'Add new folder' link.

Overall - Looking great, can't wait to see this in action! Thanks!

I have posted the final mockups as a set on Flickr:
http://www.flickr.com/photos/mverbaar/sets/72157622536479456/

The upcoming days I'll be making screencasts to demonstrate some of the interactions. I hope to finish these before the monster sprint in NY.

Some more documentation is on it's way as well.

Good stuff! Comments are below, with link to related mockup.

Would it be possible for the 'edit delete' links to only show up when you mouse over the folder? Seems like that might keep the interface cleaner.
http://www.flickr.com/photos/mverbaar/3990648092/in/set-72157622536479456/

Thumnail sorted: I'm not sure what this view is showing us. It looks like it is sorted by username (Caroltron, Markboulton) but the sort options to reflect that (they indicated sorted by update time).
http://www.flickr.com/photos/mverbaar/3989892751/in/set-72157622536479456/

I like that the links for adding new stuff (upload new files, add new folder, etc) are at the top left and the Attach button is at the bottom. It seems to visually reflect people's expectations since we read top to bottom and we expect to first upload files and then (when we're done) attach them. Overall, a very well balanced display.
http://www.flickr.com/photos/mverbaar/3989893021/in/set-72157622536479456/

After uploading new files, the status message "The files have been uploaded and are displayed below" is great, but if the user is uploading new files should those files be automatically selected (checked) so they can upload files and then simply hit the Attach button (instead of having to select them a second time, first from their computer and then from the media library)?
http://www.flickr.com/photos/mverbaar/3989893763/in/set-72157622536479456/

The external media folders looks great, I can't wait! Integration with Flickr (and others) will be super.
http://www.flickr.com/photos/mverbaar/3990650446/in/set-72157622536479456/

Admin Content: it isn't clear what is linking to this or how to access this control.
http://www.flickr.com/photos/mverbaar/3989895141/in/set-72157622536479456/

Would it be possible for the 'edit delete' links to only show up when you mouse over the folder? Seems like that might keep the interface cleaner.
http://www.flickr.com/photos/mverbaar/3990648092/in/set-72157622536479456/

I would personally prefer that too, but it would have to be done as a Drupal-wide behaviour. Not just in the media library.

Thumnail sorted: I'm not sure what this view is showing us. It looks like it is sorted by username (Caroltron, Markboulton) but the sort options to reflect that (they indicated sorted by update time).
http://www.flickr.com/photos/mverbaar/3989892751/in/set-72157622536479456/

lol, my bad. Apparently I've been moving things around so much last night that I forgot to change the text. Here's an updated version with corrected text ('sort: author, ascending'): http://www.flickr.com/photos/mverbaar/3992673794/

Admin Content: it isn't clear what is linking to this or how to access this control.
http://www.flickr.com/photos/mverbaar/3989895141/in/set-72157622536479456/

The media library is available in two places; as a tab on the 'add content' page (content, meta information, media) and in 'adminster content' (content, comments, media). This mockup shows how the interface looks in the 'administer content' context.

I uploaded the first video which demonstrates the interactions for attaching files to an article. http://www.youtube.com/watch?v=NzqqzoHGovE

Looks great!

Questions: about 10 seconds in, you choose from media library. Next to that link are two buttons: Browse and Upload. 1. How is 'Browse' different than 'choose from media library'? 2. If you choose 'Upload' and pick files from your computer, would they show up in the media library next time you go there?

1. How is 'Browse' different than 'choose from media library'?

Ah a bit confusing, yes. The 'browse' and 'upload' button are part of the browser's native upload element. Perhaps we should replace it with a single 'upload' link or button, like e.g. Flickr.

2. If you choose 'Upload' and pick files from your computer, would they show up in the media library next time you go there?

I hope so :)

New video, about sorting files and creating folders. http://www.youtube.com/watch?v=ud5s-sW5srE&feature=channel

@mverbaar - no time to do a decent UX review right now, but just wanted to say awesome job so far!

This is awesome, great work.
In regards to sorting, I'm just wondering if users should really have to click [Change], then select the sort type, and then click Sort. How about providing the two drop downs where [Change] currently is and update the display asynchronously?

How about providing the two drop downs where [Change] currently is and update the display asynchronously?

I tried that actually: http://www.flickr.com/photos/mverbaar/3958038665/in/set-72157621994336405/

I felt the form was a bit too prominent, especially in the empty state, so I hid it behind a link :)

Yhea, the form should not be too prominent. It is not as critical type of functionality - like on content listing pages. Making it less prominent, helps the user focus on the contents of the table instead of filter functionality that he is unlikely to use a lot.

Ok, I totally agree now that I've seen that.

I'm just wonder if we could improve on the way that it currently displays below [change], how about if when you clicked change it displayed in place [change]. Similar to mockup on the left of http://www.flickr.com/photos/mverbaar/3958038665/sizes/o/in/set-72157621... but obviously include a cancel button.

I'm just wonder if we could improve on the way that it currently displays below [change], how about if when you clicked change it displayed in place [change]. Similar to mockup on the left of http://www.flickr.com/photos/mverbaar/3958038665/sizes/o/in/set-72157621... but obviously include a cancel button.

Might be a good idea. A bit difficult to align though: http://www.flickr.com/photos/mverbaar/4004500282/in/set-72157621994336405/

Or, perhaps, something in between: http://www.flickr.com/photos/mverbaar/4005833172/in/set-72157621994336405/

Everything on one line, like in the 'in place' version, but not 'in place.' A simple way to fix the ugly misalignment while still saving a bit of space.

Yeah, I feel that ties it in nicely and doesn't feel out of place

As current activities are no longer considered to be part of the actual 'microproject', I'll just close the issue. UI-related things should be addressed in seperate issues from now on :)

I enjoyed working on this, I'll keep involved working on design and theming parts of the media module.

Perhaps it should actually say 'fixed' ;)

Awesome! Great work on this, mverbaar! :D

Sorry, I need to re-open this for a bit; we've re-engineered the module so that it provides fieldable entities and integrates smoothly with WYSIWYG. However, some of this original vision has been lost in the shuffle. I don't think the issue needs further comments or work (if they do, please open new issues). I just want to make sure we haven't thrown out the baby with the bath water... I'll close the issue later when current work is brought back in line.

Thanks,
Aaron

At what point to we call this history?

At what point to we call this history?

to == do?

I haven't read all of this yet, but I encourage anyone who is inspired to do so, to get a handle on what's been figured out in this thread, but not yet implemented, and open new specific issues that aren't already in the queue, and comment on ones that are, to keep moving this forward.

People here may also be interested in #865006: Designs for library and wysiwyg (much of which has not yet been implemented). If someone sees things in those designs that are in conflict with decisions reached here, please comment accordingly on that issue.

It would be awesome to have an updated UI roadmap for the Media module by DrupalCon Chicago. We will certainly have one or several BoF sessions there to hopefully, move something cool along.

Assigning a version to this so it comes up correctly in the issue queue.

changing the branch, as the 7.x-1.x-dev branch is feature frozen.

All the designs from this issue are now gone from Flickr as mverbaar looks to have deleted his/her Flickr account. Seeing as this was closed on #109, I think we should close this issue again, look at #865006: Designs for library and wysiwyg and/or file new issues for new UX designs against the current version of the module.

Still, those mockups from flickr should be uploaded here for future reference. Heading to that other issue...

The Flickr photos are not available to anyone anymore. We've lost data because nothing was actually uploaded here. :/

I just pasted a few that I recovered from an old slide at #865006-20: Designs for library and wysiwyg .