The future of multimedia in D7 or "You don't want me to kill the monkey do you?"
Hey folks,
Did you know that Drupal 7 will have a amazing multimedia capabilities due in large part to the Media module?
Hi, my name is Jacob Singh.
You may remember me from such kick-ass projects as Acquia Search (ApacheSolr), Drupal Gardens or GUI updates in core. You may also just be dying to know what's going to happen to the monkey. Either way, I'm here to tell you about what I've been up to along with many of my colleagues and Drupal buddies.
The Media module provides a rich interface for:
- Managing files
- Uploading new files or adding them from the internets
- Browsing existing files
- Embedding files in WYSIWYG editors
- Adding fields and meta-data to files
- Generally making Drupal suck less when it comes to files.
But don't take my word for it, watch me stumble through this demo (about 5 min of fast paced monkey-on-baby action)
and then vote for my media session at Drupalcon
Related Content
Related Posts
Well, Sprint 39 just finished up at Acquia Engineering and we've got a number of new exciting features and bug fixes releasing to Drupal Gardens in the next week. One of these is Mollom - the best spam protection service on the internet - for all Drupal Gardens site owners. For those not in the know, Mollom protects your site from spam by analyzing the contents of comments or other content that is contributed by users and presenting Captcha challenges if the content is suspect.
Jacob Singh
In addition to the rush the Drupal Gardens team gets when adding cool new features, we like to get things right, striking a good balance between power and simplicity. In the last sprint, we spent a bunch of time polishing the powerful XML Sitemap and Media modules with a focus on simplifying the UX and providing smart defaults so they work immediately after site creation. Out of the box, these modules are highly customizable with many configuration settings. Our goal was to red
Chris Brookins
There exists an interesting story about a man and a butterfly cocoon. It is about a man that found a cocoon, and brought it home to watch it turn into a butterfly. As the butterfly inside matured, it struggled to get out of its cocoon, but couldn't quite get free of it. One day, the man became tired of waiting and decided to help the butterfly. He removed the remaining bit of the cocoon. The butterfly was pleased, but it had a swollen body and small, wrinkled wings. As a result, the butterfly never succeeded in flying and spent its entire life crawling around.
Dries Buytaert
AcquiaBlog
2010 has been an inflection point for the Acquia partner program. We are doing more business than ever with partners, including case studies with Palantir.net, Blink Reaction, and IBM Global Services.
Bryan House
It is that phase of my life! I'm just turning 30 in a month, working with Drupal for 7 years and just had my third Acquia anniversary a week ago. Time to look back and evaluate how things went, all the good and bad things; even better if the wisdom can be shared with others. This was part of my thinking when I submitted the session titled "Come for the software, stay for the community" for Drupalcon Copenhagen.
Gábor Hojtsy
It sounded like a really simple request: "Is it easy to add a search filter for 'My posts'?". In other words, add a search result facet for posts by the current (logged in) user through the Apache Solr Search Integration module APIs?
But then the wheels start turning - we want not just one blind link, but a real facet link that tells us how many results we'll get. Also, if we are filtering by 'My posts' then we probably have an equal use case for the opposite filter 'Posts not by me'. So we really need a facet block with two links and facets counts.
Peter Wolanin
Comments
First off: Great
First off: Great stuff!
Can't wait to get my hands on that.
The fact that you can add a Media field to e.g. a node, which is in turn fieldable (and shows those fields in the node), sounds a lot like Fieldable Fields.
Over at #695636: Figure out whether Fields API and Multigroup module can coexist that was discussed as a possible successor of the Multigroup functionality in CCK 3.x. Maybe you could leave a short note there about the approach Media module has taken and how that worked out.
Re Tobias Stöckler : The
Re Tobias Stöckler :
The only similarity is that both would be 'reference' fields, i.e fields whose values are ids of other objects - 'node' for noderef, 'taxo term' for D7 taxo fields, 'file' for D7 file and image fields, 'media' for Media field...
Fieldable fields (as a possible approach for the infamous 'combo field' request) boil down to nothing else than a 'ghost-entity reference' field : i.e., a field whose values are ids of entities of a specific, dedicated type. Those 'ghost entities' hold the values in the 'combo field'; unlike nodes, taxo terms, files, media..., they have no visible existence in you site (display, edit form) other than being 'embedded' into the display and edit form of the parent entity. The field values appear as if they belonged to the parent entity, when in fact they belong to a 'sub-entity' through an indirection.
None of this is ready yet, and right now there is no guarantee that it will be at some point. As far as I remember, the tricky bits notably reside in this 'form / subform' area, and also in the way this approach would translate in Field UI.
In short : 'fieldable fields' relate to 'Media fields' only to the same (limited) extent than they are to good old noderef fields. I'm not sure the specific case of Media fields carries interesting knowledge on that regard.
Jacob Singh
Hi Tobias, Thanks for the
Hi Tobias,
Thanks for the comment. I agree while writing it I said to myself.. hmm this would be better represented as some kind of entity reference API... but I like to build APIs after building working products, so looking forward to seeing what kind of integration will make sense there. The Acquia focus has been on WYSIWYG and usability thus far, but there will be a big push to the data driven side soon as we start supporting a slicker file browser as well as galleries.
Let's get in touch at DrupalCon. To chat about it.
Best,
Jacob
Curious what the monkey
Curious what the monkey alludes to :-)
Jacob Singh
Vote for my DrupalCon
Vote for my DrupalCon session or my daughter eats the monkey.
http://cph2010.drupal.org/sessions/rich-multimedia-drupal-7
Cool stuff. One of the big
Cool stuff.
One of the big questions I have with Media, though, is scalability of the interface. The media browser currently appears to give one big list. That's going to fall flat once there are a few hundred or, god forbid, a few thousand entries in the library.
Moreover, I've had cases where I've needed to say that certain users can use certain media but not others. Or a certain node can only use media that has a given flag, or is in a given nodequeue (D6 approaches, anyway). I'm unclear how Media module would handle such more robust use cases. (If it does, that will be awesome.)
Yes, I would really like to
Yes, I would really like to know this as well.
The browser interface really needs some sort of organizational structure, IMO. Like a folder/directory structure. Not that the files themselves need to be stored in the same directory type structure. Rather, tags, fields, and/or taxonomy attached to a media item could be used to give the media items an organizational structure which could then be used in the media interface to organize the presentation of media items as well as limit the media items available to certain users.
I get the feeling that this is possible, but requires custom coding or additional modules.
Robert Douglass
Views. I want to be able to
Views. I want to be able to filter by views. No more, no less. That solves every use case that there is.
I can imagine a dropdown that has all the views that are meant to act as media filters. Then, each view can have its own exposed filters. We can package some standard views/filters that make sense, like "my files", "files by tag", etc.
Robert Douglass
Senior Drupal Advisor, Acquia
Jacob Singh
We're actually hotly
We're actually hotly debating this very topic :)
What would you like to see in filters? Here are the various approaches:
1). Folder based. Everyone knows and love/hates it.
2). Tag based. Gmail did it, kinda worked. Doesn't work in lots of other places.
3). Text searches and filters - ala Finder or views exposed filters.
Any other ideas?
Btw, the current design actually pages as you scroll, so it does scale, it's just hard to find stuff.
Best,
J
Daniel F. Kudwien
...by "Jacob" and "Singh",
...by "Jacob" and "Singh", actually :P
First name and last name, that is. Of course, it's all views. But we need to think about (potentially endless) drill-down and abstraction of exposed Views filters to make things really useful.
Yes, we absolutely need to filter by files that are used more than once. (New file usage API to the rescue.)
Oh, and that said, filter by where a file is used? Entity type, at the very least?
It's going to get complicated. Don't even want to think about UIs here, although we have to. admin_views module shipped with admin_menu already provides a nice preview on the topic -- if all your administrative listing pages are views, you actually, really, totally, awesomely want much more, immediately!
However, changes are applied persistently, for everyone. You can't just go ahead and, for now, quickly filter all nodes to only match those that are assigned to taxonomy term 123, or assigned to any term in vocabulary id 6. But you absolutely want to!
Simply installing admin_views blows your mind makes you believe that you're actually sitting in front of the CMS of the future. But the day you're starting to use the äwesomesauce, you're going to ask for more. Permanently, or just quickly for the next required maintenance task you're facing.
Refreshed possibilities create new bugs. :)
Daniel F. Kudwien
unleashed mind
Jacob Singh
Hey Daniel, I've not seen
Hey Daniel,
I've not seen admin_views, nor does it seem documented so I'll have to take it for a spin when I get time on Monday/Tue. You're absolutely right about views as a potential backend. But for an end user who just installs the mod, some reasonable defaults with nice looking UI is a must. What are these default filters?
To your other point about tracking used files. Yes, this is great and it is also kinda impossible with embedded media :( I wish there was a nice solution for that. It is possible of course to track it whenever textfields are saved or loaded, but then you run the risk of getting out of date when dealing with API level changes or direct DB updates. I'm not sure really what the recourse is there when you can embed in any text area.
-J