Media Browser - Library Filter

Totally... There have been dozens of requests / mockups in the past and not enough code here ;)

My personal preference is to keep this really light to start because the UI could become Drupaly very quick :) Here's how I would order the backlog here:

* Filter by type
- We already do this (even though images are really the only supported type) by passing it when you invoke, but we should also provide a UI for it. Would be awesome to be faceted, but this of course is tough to accomplish w/o other tools (like Solr).

* Filter by "Folder"
- Actually, same as by tag but I got some convincing arguments from some UI folks to have an official "Folder" vocabulary so as to not confuse newer users. I think this is a good strategy

* Filter by Tag
- Yes, absolutely! I guess we get this for free beside the UI work when we do the previous one. See the media_dev profile. I've improved it a bit to add some fields to the media entities out of the box, namely the tags field. We're more limited by UI here I think, since the underlying structure is in place.

Good questions, I'll see what our designer / UI guys think about it. I'd like to give them a chance to lay something out first in Balsamiq, etc and then we can iterate over that if it looks hard technically or we don't like it much :)

The code for filters got partially implemented by Aaron, but I don't think it ever really made it all the way. A lot of it was a debate of do we build this stuff or just wait for views to be stablish and support all entities (including media). I think the answer is we will get views eventually, but we could make it a lot more rich now and that's okay.

I'm hesitant to say this because most of the current code was written "from the hip" in a relatively short amount of time given the scope (and it shows in places), but we should just jump in and get something working, not worrying too much about extendability. Type, Folder and Tag filters all feel like part of the core framework to me.

-J

Bummer :( We postponed our move, so I won't be in the states until July 1st. Aaron and I are talking about doing some media sprinting in the North East over the summer sometime though.

I would be absolutely interested in participating in a Media sprint on the 26th. If you can get confirmation today, it would be awesome since I have planning day tomorrow for this upcoming sprint (ends June 29th) and I could schedule my time for it.

Best,
Jacob

Here's what Acquia's planning for a first iteration.
#865006: Designs for library and wysiwyg

I'm not sure media would want to introduce a dependency for this functionality but if grid view acted like the jQuery Quicksand plugin it would be very neat.

http://razorjack.net/quicksand/index.html

Its GPLv2

That's really slick looking. My concern with adding something like that would be scalability. With potentially hundreds of media items in a view, tweening each of them to their new location would be a huge number of jQuery animations firing.

I could see this being implemented as a CSS3 progressive enhancement. Browsers that support CSS3 animations could benefit without the overhead of animating each thumb via jQuery.

As you can see Quicksilver uses CSS3 by default for transition effects which should scale nicely. If this has any interest in geting added in I would be willing to do some testing for performance. Testing 100, 200, 500, 1000, maybe 2000? With that many items it might also be wise to find something that supports only loading what is viewable on screen. I wouldn't be surprised to see a photographer with 2000 photos in a directory. I'd rather have a super fast system that can scale then one that looks pretty, maybe with CSS3 it might be possible to get all three.

Also a good/bad thing to note is that Quicksilver doesn't support IE6. If we have any interest in supporting tards this would probably not be a wise library to choose if we do choose an external library.

Any news about this interesting feature? :)

There has been no development for the feature.

I did take a second look at the plugin suggested in #7 and it does us jQuery animations for its transitions. The only CSS3 transition it does use is scaling and only uses it as a additional effect on top of the moving and fading that is done in javascript. I tested the demo in IE8. It has a few display and performance issues. So I don't see that being included in the media module.

We have a specific intent to keep the media module as lightweight and bare bones as possible so that other modules can hook into it and add more functionality. There is an effort to adding folders to organize media as part of the media_browser_plus module. You can find it at http://drupal.org/project/media_browser_plus

Very understandable.

Maybe when things stabilize I will look into what it would take to implement something like that as a contrib module or w/e. Who knows.

The "media browser plus" looks like totally unusable at this time, so...

Here is a patch to add IMCE "support" for media browser. With this patch, you can choose between original media browser and IMCE (with IMCE you can easily "add folders to organize media" ;-)

The second little patch just add a "cancel" icon to IMCE (1.3 and dev).

none of those patches work... I wonder if something is wrong with d.o?

Anyway, I'm excited to try this out. However, can you explain the use case where you would want media and IMCE?

-J

sorry, I mean the links don't go to the files.

Hmm.. I try to attach again (created a tar.gz)

Because the default media browser is too "user friendly" for me. I like to organize files/images in directories and i like to upload files with FTP/SFTP.

Sure, the problem with uploading files via FTP / SFTP is that media only operates on the file_managed table. Files uploaded that way wouldn't work properly. Have you looked at the very barebones media import functionality? It wouldn't be a bad add-on module to media to be able to configure a "dropbox" that would constantly scanned and imported from.

Hmm... "uploading files via FTP / SFTP is that media only operates on the file_managed table."... As I think FTP/SFTP can't operates any database table (not on file_managed too). "Files uploaded that way" cannot seen in media browser.
With this patch it is works, because IMCE see all files, and when we select a file it is automatically saved to 'file_managed' and so on like we just upload it...

"Have you looked at the very barebones media import functionality" - yes, but the main problem is that, media browser show up all media unstructured, and media_browser_plus looks unusable. Other bad point, you first FTP the files, Next import as media. Next you can use.

With this way you just FTP, and you can use...

"It wouldn't be a bad add-on module to media to be able to configure a "dropbox" that would constantly scanned and imported from." - yes, if it preserve the directory/folder structure below "dropbox"...

If media browser feature: "Filter by folder" come to life... but the meantime IMCE can do all this thing...

Ah cool... That's great.

Can you create a new issue for the IMCE integration and put these patches there? This issue is more about adding folders to the media browser itself IMO. Btw, the larger game plan is to use views to build a next-gen media browser now that views is out. This would support filters like labels and folders, etc. But for now, people needing direct filesystem access, this might be a great way to do it. I will happily review once you move it

Thanks,
Jacob

OK, just a brief overview of this patch. I added a 'keywords' param to the ajax callback used to query the media entities. From there, I tweaked the library js to add in a new method on the library class to handle the input field I hard coded into the HTML of the media container. Not ideal, but for now, its there.

Now I'm not saying this is the end all, be all, for a filter.. but its a start. This isn't really meant as a committable solution, but more of a point to get us working or at least me, in a common direction thats best for media module. This will get added in some form, whether it be a plugin or as part of the module.

Some questions/comments that I came up with while rolling this:
* we need some hooks in the library, where's the best place for them?
* I'm not a fan of most of this stuff being in javascript. (this makes me think of just rolling a new tab and hiding the default)
* I really like the idea of being able to do hook and alter the params for the media/browser/list callback.

I look forward to feedback. The faster responses come in, the better, im working on this for the next couple of days so if we can hammer this out.. I think we can find something to add in on a permanent basis. :)

sub

Subscribe.

re-rolled the patch from #22 to work with beta4 changes.

tweaked some html and removed some commented out code.

subscribe

Subbing

You should probably be aware of the work in this branch.
There may be overlap

http://drupalcode.org/project/media.git/shortlog/refs/heads/1139514_medi...
http://drupal.org/node/1139514

subscribe

subscribe

This will be solved by #1224766: Remove default media browser and replace with a default view.

Not sure if it helps, but regarding using the slick quicksand method of filtering.....
There is now a fabulous quicksand views plugin .

Would this work with the media browser views plugin? (which I know is for Media-7.x-2) but thought I'd post this here as there was mention of quicksand.