I'm adding display formatters to the Media module, and could use some feedback.
Basically, I'm taking the work from the Image Styles built into core (which is a port of Imagecache), and building a wrapper around it. A Media Style would be a collection of styles, based on the stream (public://, private://, youtube://, etc) and file mimetype (image/jpeg, image/png, etc.), that would be applied to a specific filefield display (either in the node teaser/page display, or a view field display, or possibly other places, such as inline).
As an example, you might have a 'small-box' Media style that contains a 'medium' image style, a 'preview' youtube style, and an 'inline' pdf style. Thus, if the filefield contained an image, it would display it with the image scaling, a youtube video with a small player, and a pdf would be displayed in an iframe. Undefined streams/mimetypes would fall back to the default file listing.
The module is intended to work stand-alone, with File, Image, and/or Media. Thus, one question I have is if it should be bundled with the Media module, or packaged outside the module. On the one hand, as it can be run w/o Media, it might be useful in other situations. On the other hand, I imagine 98% of Media users would also want this module, so I'm hesitant to create a new external dependency. I've mostly decided to bundle it with the Media module, but am open to new considerations I haven't had yet.
I've included two screen shots. The first screen shot at the top shows current functionality. Clicking on a radio will automatically load a new preview of the selected style (that part's not built yet, but that's the idea).
The second below was the original display for administration. It's now actually using vertical tabs, as with the first, but I'm including it since it gives a large overview (and is what it would look like w/o javascript anyway).
I'm mostly looking for feedback of how the administrative UI could be improved, as well as how to word instructions to the user that won't scare them off. Also, for any other conceptual, architectural, or other comments.
Thanks,
Aaron
(Cross-posted in the Drupal Media Group.)
Comments
Styles FTW!
After some discussion here, at http://groups.drupal.org/node/35206 and on irc, I set up the Styles project to host this externally. Thanks for all the great suggestions! Most of them will find their way into the module.
By the way, some of the reasons for this is that I'm abstracting the architecture to be used for any type of field, not just File fields. For instance, one could create formatter styles for a node reference field that will format the display according to the referenced node type.
Media Support
I am attempting to install media, are you recommending that I upload my media that I have copyrights to Youtube or can I upload and install it directly onto my page?
Melissa Mouradian
Public Relations Specialist
San Diego, CA
Verizon
You should strongly consider
You should strongly consider keeping them separate.
Examples of modules that are better separated, but closely fit together to begin with:
- Token and Pathauto
- Panels and Ctools
- Fivestar and Voting API
Examples of modules that "did it all in one module"
- Ecommerce (Ubercart now owns the space as it is very pluggable)
- FAQ (actually pretty strong still, but cumbersome and would work better if it started its life as an API)
- Flexinode (not sure about this one, but I needed another "fail" module)
My argument goes back to a presentation Jeff Eaton made in Washington DC: Your module should be an API. What you are proposing (multiple formatters for ONE media filefield) is nothing short of awesome. Make the wrapper code that does this an API (call it multiple formatters api or something) and then use your API in your media module. Yes, you have a dependency for that functionality, but we're Drupal and we're used to that.
And then I can then make your multiple formatters api work for my new date widget. Otherwise, my date widget would have to depend on media module and "hack into the functions" to "re-use" the basic idea...
Josh
That's a strong argument,
That's a strong argument, Josh. Just the sort of mess I'd like to avoid. Thanks!
Technical information
About this:
"YouTube styles will be applied to the following:
Streams: youtube://
File types: application/octet-stream"
Could you provide more examples of this? I'm wondering if this is relevant to users. In this YouTube example, it seems not, because the vertical tab already says "YouTube" and the part that says "application/octet-stream" is probably all Greek to the average user.
Unless there are good use cases that require this technical information, I'd say remove it :)
Your thoughts?
I guess it's fine to leave
I guess it's fine to leave the supported schema/mimetypes hidden, as it's not a configurable option on the administrative side, but instead configurable from the API. We can revisit later if needed (or maybe have an 'advance options' section).
Every little bit helps...
Awesome, thanks Maarten! A great idea; that'll definitely go into the mix.
Vertical tabs
So the idea is to have one style ("preset"), that can be used for any type of media?
Screenshot with vertical tabs looks pretty good. Have you considered displaying the selected options as tab descriptions?
Mockup: http://skitch.com/mverbaar/n8gwu/skitched-20091112-154142
Post new comment