Media - File Styles Roadmap

Share this

This past month I've been busy getting the Styles module ready for release. This module does the heavy lifting for display of Media objects. For those that don't know yet, Media, the File Browser to the Internet, is the future of media handling for Drupal 7. It exposes the underlying streams API of Drupal core, allowing for fieldable media entities (fields on files), mixing up images and audio, local files and YouTube.

File Styles for Drupal

Basically, the Styles module allows you to select a style for display with a field (or in a View or with WYSIWYG), and the field will be displayed as determined by the predetermined criteria. For instance, as shown in the above diagram, you might set the display as 'Medium', and the actual displayed file or remote stream will be selected according to the file's mime type (as an image, a video, in an mp3 player, etc).

The UI

The tricky part has been creating the UI for this. We're just about there -- you can finally create and modify styles with the supplied Styles UI module.

File Styles menu item

You can add new styles, and modify the provided styles.

File Styles listing

When editing the style, you'll note all the 'containers' to the left (Image, Audio, YouTube, etc.), with a preview of its display. Just select the preset for that container/style combo, and you're set.

Edit File Styles

However, we still need to add a way to create and edit the presets themselves. As an example, you might want to create a preset for images that will display a Medium image style linked to the original media, or a YouTube thumbnail that will popup the video in a ColorBox when clicked.

Technically, this isn't too difficult (and is on the way). However, from the stand-point of the administrator, this has been a bit of a stumbling block. Though I'm leaning towards doing some in-place editing of presets within this same screen. (For that matter, we could even go so far as moving this entire screen, perhaps as a dialog, within the media field display screen.) At the same time, I'm afraid of clutter; the concept is hard enough to explain as it is. I'd love to hear from anyone with more of an eye towards UX for the administrator.

Thoughts? Comments?

Comments

Anonymous's picture

shadowbox in drupal7

Hi,

1º pardon my bad english (sorry )

I am now developing new in drupal7, I am converting a drupal6´s site running ok to 7.
I had get running shdowbox running in images and link, because I can define it in the arch field (one in his correspondent resources)

I had configurated the media youtube ok. I can see running incrusted as I get concevited it.

My next progress is get a miniature (I define ok see as thumnail, or as I define) but I cannot see in any place how can be procesed by shadowbox, and this is my actual problem.

If any understand me, can help with this ? :
I need see the youtube running in same form I get with image, running with shadowbox.
Thanks
Sorry my bad english.

effulgentsia's picture

An in-progress architectural analysis

Hey Aaron. Great job getting it this far. You've had to figure out some complex stuff, deal with incomplete and volatile core APIs, and do all this with sporadic and partial availability. I still feel like I'm just getting my feet wet with all this, so please pardon if my analysis here is naive, incomplete, or unclear.

I think a lot of the complexity and confusion about naming, how to use the API, and how to present a usable UI is due to Styles trying to implement 6 or so layers of abstractions.

Layer 1: Representing a specific rendering of something as a series of operations. The Styles module calls this a "preset" and calls each operation an "effect". In Drupal 7 core, an analog of this exists for text, and is called a "text format" (e.g., "filtered html"), and each operation is called a "filter" (e.g., "limit allowed HTML tags"), and each filter may have settings (e.g., the tags to allow). In Drupal 7 core, another analog of this exists for images, and is called an "Image style" (e.g., "thumbnail"), and each operation is called an "effect" (e.g., "Scale"), and each effect may have settings (e.g., the width and height to scale to). However, Drupal 7 core uses a different pattern for a specific rendering of a field. That is called a "Format" on the Manage Display page for entity bundles, and a "field formatter" within code. But here, it is the format itself that has settings, and a field format is not represented as a series of operations. For example, for a text field, you can choose the Default format, or a Trimmed format, or a Summary format. And if you choose Trimmed, then you have a setting for how many characters to trim it to. For an image field, you can choose the Image format, and this has settings for which Image Style to use, and whether to not link it at all, link it to the original image, or link it to the content (e.g., node) containing the field. I'm not yet clear on why Styles requires the series of operations pattern. Configuring the video player with a certain size, color scheme, autoplay setting, etc. seems more similar to me to the field formatter model than to the manipulate text through a series of filters or manipulate an image through a series of effects model.

Layer 2: Representing a generic (or virtual) rendering of something which then maps to a specific rendering based on the type of content. The Styles module calls this a "style" (e.g., "large") and the type of content a "container" (e.g., "image" or "media_youtube"), so that something can say "render a large display of this media object", and if the object is an image, it gets rendered by the preset configured for the large/image combo, and if the object is a youtube video, it gets rendered by the preset configured for the large/media_youtube combo. In Drupal 7 core, an analog of this exists for entities. The generic rendering is called a "Display" in the UI and a "view mode" in code, and the type of content is called a "bundle" in code, and doesn't have a generic name within the UI, because the UI is always specific to the entity type. For node entities, the UI calls it a "Content type". I wonder if in future incarnations of Styles, we can leverage more of the Entity/Field APIs, rather than reimplementing this entire pattern as Styles currently does.

Layer 3: Limiting "preset" choices based on the container. For example, an administrator shouldn't be allowed to configure an image to display with a YouTube player. There is no analog of this within Entity/Field API. You can't, for example, say "This formatter can only work for images within Article nodes. For any other content type, it will break, so don't allow it."

Layer 4: Allowing the administrator to create named presets as a way of reusing a complex set of settings. This is similar to layer 1, but I call it out separately, because although it exists for text formats and image styles, it does not exist yet for field formatter settings, but yched has been wanting to implement it, and possibly the core field APIs are finally sufficient enough to be able to do so via a lightweight contrib module.

Layer 5: Mapping a field formatter to a style, not a preset. So the idea is that once you've setup your styles and presets, when you're on the Manage Display page of a content type containing a file field, the format that needs to be chosen for the file field is the style (e.g., "large"), not the preset (e.g., "such and such player"). There is no analog for this in Drupal core. Field formats in Drupal core are always specific, because they're working with specific field types, rather than a field type that can contain fundamentally different kinds of content. But this pattern does exist in contrib, anywhere there's a reference kind of field type. For example, in the Media module, the media field is a reference to a media entity, so you have a "large" media field "format" mapping to a "large" media entity "display". The confusing thing within Media module is that you then ALSO have the file field that's within the media entity having to configure that when the media entity is displayed "large", the file field should be formatted "large" mapping to the Style "large". We have some work in front of us to simplify this.

Layer 6: Trying to make the Styles module apply to more than just file fields and file content. The above 5 layers of abstraction are hard enough to grasp just for files. It gets much harder if you then have to have the abstractions also make sense for other things like node reference fields. I wonder if this is really necessary. Seems to me that node reference fields can be solved entirely through the field format / entity display APIs that already exist in Drupal 7 core, maybe with some improvements being worked on by yched, as per above. Perhaps if we focus on files, what else is needed for files to be full fledged entities, and use the existing entity display / format APIs and UIs, we can greatly simplify Styles and Media.

So, not sure where this leaves us. But I hope this helps the long process of us trying to understand this stuff ourselves, and then implement APIs, UIs, and documentation that make it understandable to others.

Sebastien's picture

Colorbox or other features

How/when do you plan to add the option to use by exemple Colorbox with Styles ? Are you going to add the option into Styles or is it an option modules like Colorbox will have to have in their own ? I'm actually using Media and Styles and since 1 week it work great... espacially the GUI to customize Styles.

But I think there is features like that, that seems to be a good idea to include in the future.

Is there any plan ?!? Is there any DEV version to test such option already ?!?

pwolanin's picture

Entity fix

Before going too much further, Media needs one of its deep architectural flaws addressed, which is that it's using the file_managed table as a base table. It seems instead it needs to be enhancing the file entity instead of declaring a new one.

The Views module and other module are being built assuming a one-to-one mapping of entity to base table.

aaron's picture

Amen!

Yes, I agree this is essential, and was the original direction we were going, as you well know, Peter. I'd personally like to fix that before a final release, but there has long been a push from Acquia (who has graciously done most of the development over the past year) to get the thing out there and working, and with Drupal 7 already out the door, the pressure is even greater. Unfortunately, in the mid-stages of development, we made some decisions based on then-current core limitations (around field entities), with long reaching consequences. Core is probably more stable now, so this is certainly feasible. I'd love to see you more in the issue queue! And there's always someone in #drupal-media if you have a moment...

winston's picture

Mixed metaphors?

I can see (perhaps) mixing video and images into the same "medium" style as they are both visual in nature, but what would that mean for audio?

Why is it necessary to combine these together? They are different things (videos have duration, etc.) - I would expect them to be treated differently. And what if someone adds other types of media that you aren't anticipating (ebooks or something), what does "medium" mean then?

Can we stop a minute and think about use cases? It seems like the above dialog presumes that someone will attach a media field to a content type in such a way that someone can attach ANY media type to that field. But how frequent is that use case? Usually I'm going to want to restrict this to one media type for a particular field, otherwise I'll just be confusing the heck out of my users. Each content type has a use case. Consider a "typical" article. It will have a lead image and body text. It might also optionally allow a video, audio, file or other attachment. However, I will most likely present that to my users as distinct options (so they'd each have their own optional field). That way I have more control over display and I'm presenting a clearer picture to my end users ("you have to provide a lead image and body, and oh here you can optionally attach video, audio or a plain file attachment, etc.").

Also, from a user perspective what is the difference between video and youtube? Yes, of course the source is different, video will presumably be something uploaded and hosted by the website and youtube is of course youtube. But that is a programmer's mental model, not a user's mental model. To the user they are both just video. So why would they have separate tabs. I think to a user it would make more sense for Youtube to appear under the video tab. Consider using a selector inside that tab so the user can select the sources they've configured. So example...

I've configured a field to allow the user to upload or select a local image on my site, OR get an image from either Flickr, Smugmug, or Picasa. The options for all 4 of those should appear on the Image tab because as a user to me they are all images. However, we can't hide from the reality that the external providers in particular may have limits on what they can provide that a local image wouldn't (specific sizes, etc.) so how to present that? I would argue that on the Image tab you would present a selector for "source" where the user can configure the behavior desired for each source that they will allow users to provide images from. Similarly for video (all video providers grouped together), audio (same), etc. If you have new types of media like ebooks then that could be a separate tab too if necessary.

One thing that has always bothered me about emfield for example is that it always felt like it was for a much more grandiose use case than what I wanted it for. Consider, if I've decided I'm going to put my audio on archive.org for my website, I don't really want options that allow for all kinds of other providers. What I _do_ want is to be able to configure in detail the way I want stuff I pick from archive.org to behave. That is what was missing from emfield that I'm really hoping will work well with media module. Emfield tried to generically allow anything you wanted to throw at it, but unfortunately because different providers have different options and capabilities it forced emfield into either being lowest common demoninator, or individual providers ended up quite inconsistent with other emfield providers in their behavior. Either way there was very little way for the emfield end user to control that other than with fairly hackish options that some provider authors put in to their emfield providers and others didn't.

aaron's picture

Good food for thought...

I can see (perhaps) mixing video and images into the same "medium" style as they are both visual in nature, but what would that mean for audio?

Everything in the web is fundamentally visual at the display level, including audio. Styles options might include the size of the player, whether to autoplay or begin at a certain time, an album thumbnail, shadowbox, etc.

Why is it necessary to combine these together? They are different things (videos have duration, etc.) - I would expect them to be treated differently. And what if someone adds other types of media that you aren't anticipating (ebooks or something), what does "medium" mean then?

Drupal core combines all this with its improved file & stream API. We're simply extending that with our work. It's precisely because they need to be treated differently that there's a need for this module (if not this approach). If someone adds other types of media, such as ebooks, pdfs, text files, etc, we'll have a default fallback, most likely (in the case of the medium style) a thumbnail with a generic file icon, or at the very least a link to the original media.

Can we stop a minute and think about use cases? It seems like the above dialog presumes that someone will attach a media field to a content type in such a way that someone can attach ANY media type to that field. But how frequent is that use case?

Nearly every site I've built in the past year-and-a-half has required mixing images and videos in the same location. Drupal 6 requires some fancy legwork on the theme level of views to achieve this; this module will alleviate some of those issues. And it's been a long-standing request in emfield's issue queue to present a grand unified field of all media. I haven't done a poll; this has always been, for me, more of a "scratch your own itch" process.

Consider a "typical" article. It will have a lead image and body text. It might also optionally allow a video, audio, file or other attachment. However, I will most likely present that to my users as distinct options (so they'd each have their own optional field). That way I have more control over display and I'm presenting a clearer picture to my end users ("you have to provide a lead image and body, and oh here you can optionally attach video, audio or a plain file attachment, etc.").

This allows you to have more control over display. Yes, you can still limit fields by type, requiring a lead image, etc. However, as this is combined with WYSIWYG, it also allows for a more consistent presentation of even inline media.

Also, from a user perspective what is the difference between video and youtube? Yes, of course the source is different, video will presumably be something uploaded and hosted by the website and youtube is of course youtube. But that is a programmer's mental model, not a user's mental model. To the user they are both just video. So why would they have separate tabs. I think to a user it would make more sense for Youtube to appear under the video tab.

The UI I'm presenting is available only to the administrator, and it is required there to separate YouTube from other videos, because there will be different options (for instance, although LongTail does, FlowPlayer doesn't support YouTube, though it does support local videos). The end user (or editor, rather) won't see all this -- they'll simply be offered a choice of whether to display their media as a thumbnail or a large style, for instance. For them, they'll see in the media browser several rows of thumbnails, initially all allowed media types mixed, from images to video to YouTube to MP3 albums, etc. Though they'll be able to later filter by type, search YouTube or Flickr within the browser, etc.

Consider using a selector inside that tab so the user can select the sources they've configured. So example... I've configured a field to allow the user to upload or select a local image on my site, OR get an image from either Flickr, Smugmug, or Picasa. The options for all 4 of those should appear on the Image tab because as a user to me they are all images. However, we can't hide from the reality that the external providers in particular may have limits on what they can provide that a local image wouldn't (specific sizes, etc.) so how to present that? I would argue that on the Image tab you would present a selector for "source" where the user can configure the behavior desired for each source that they will allow users to provide images from. Similarly for video (all video providers grouped together), audio (same), etc. If you have new types of media like ebooks then that could be a separate tab too if necessary.

Might not apply to this discussion; see above. Although I could see an argument for simplifying the administration with this in mind. Good ideas on the Media browser end of things, as well.

One thing that has always bothered me about emfield for example is that it always felt like it was for a much more grandiose use case than what I wanted it for. Consider, if I've decided I'm going to put my audio on archive.org for my website, I don't really want options that allow for all kinds of other providers.

I agree. We're doing our best to separate functionality from format; this is part of that continuing effort. Styles is simply an API, as is, at its root, Media.

What I _do_ want is to be able to configure in detail the way I want stuff I pick from archive.org to behave. That is what was missing from emfield that I'm really hoping will work well with media module. Emfield tried to generically allow anything you wanted to throw at it, but unfortunately because different providers have different options and capabilities it forced emfield into either being lowest common demoninator, or individual providers ended up quite inconsistent with other emfield providers in their behavior. Either way there was very little way for the emfield end user to control that other than with fairly hackish options that some provider authors put in to their emfield providers and others didn't.

I appreciate your points, especially considering your experience as a developer who's had to wrangle emfield, which I know you've had more than your share of with Media: Archive. Unfortunately, we're going to continue to see some of this, I'm certain. However, by separating things more from the get-go, it should allow Media to thrive where Embedded Media Field fell (at least in version 1, before we pulled out the providers from the main module).

winston's picture

I'd definitely like to get my feet wet

I'm maintaining archive (which covers audio and video), and smugmug (which covers video, photos, and photosets). I'd really like to get them onto media. It will probably be three weeks before I can put time into it though.

If there is any sort of "template" or "boilerplate" code to implement a provider that would really help and I'll be happy to be a guinea pig by attempting to make archive and smugmug work with media.

Thanks for considering my points.

Cheers!

moshe weitzman's picture

Media formatters

I think the word formatter should be in the module title. Media formatters? It is tough to name for sure. For me, Styles conjures up cascading *style* sheets.

aaron's picture

Blame core

I agree in principle, Moshe, and you're not the first to bring up the confusion with the name between this functionality and CSS. My reasoning for the name was the fact that ImageCache is now called Image Styles, and it's in core, handling a similar functionality. In fact, this module builds on that functionality. With that precedent, I sought a name that someone new to Drupal 7 might look for. Also, the module itself is an API, allowing for extension for other purposes, such as node types (as used in d6 already with Node Reference / Embed Media Browser). I'm not certain that 'formatters' is a term exposed to the administrator in core.

Matt Farina's picture

How Media, Styles (and file

How Media, Styles (and file styles), Image Styles, and Field Formatters all fit together are not obvious. When I've tried to explain it to several people they ended up confused at the interactions.

I think some good documentation with diagrams could help.

aaron's picture

Yes, we need better documentation!

I agree; I plan to use the diagram I posted here as a start.

scroogie's picture

It's indeed a bit hard to

It's indeed a bit hard to grasp the concept. How does this interact with field formatters? Is styles a field formatter for the media field, that itself introduces a new "preset" concept generalizing imagecache presets? This is how I understand it currently.

In that case I would seperate the two UIs. One to create the presets, like the imagecache UI. And one to bundle the different presets for the file types to "styles", with the possibility to reuse the single presets. I think at least for me, that would be easier to understand.

Cheers
scroogie

aaron's picture

You summed it up nicely!

Yes, Styles creates a field formatter for the media field, that itself introduces a new "preset" concept generalizing imagecache presets. And yes, the direction you've indicated, separating the two UIs, is how development has progressed thus far. Perhaps that's the best way to do it, at least initially.

Anonymous's picture

How would you combine this

How would you combine this with imagecache?

aaron's picture

Imagecache == Image Styles

In Drupal core, Imagecache is now called Image Styles. File Styles encapsulates it for images, so that each image style gets its own preset by default. Additionally (to come), you can mix and mash these with other options, such as linking to another path or displaying with a ShadowBox option.

The Society for Venturism has chosen me as the recipient of its charity for this year, to hopefully offer me cryonic preservation when the time comes. And this month, Longecity, an excellent forum for the discussion of issues related to extending the lifespan of humans, has offered up a matching grant of up to a thousand dollars to help out! So help out! Please.