The future of the asset module

Now that I finally have it working (thanks!) I'm attempting to actually use it. Here are initial thoughts:

• "Insert assets" is no good for end users. "Add media" would be a little friendlier. Better yet is to make it integratable into editor buttons. I'm using bueditor and it has an add image button that's customizable.
• Using imagecache to size it is nice but making a thumbnail doesn't do much good if it's not linked. I'd like to see an option to choose the thumbnail preset and the regular preset and have asset do all the scripting needed so you can click and have a larger image popup with *box.
• I really liked the asset 2 UI. Unfortunately, I don't remember specifics about what I liked when I tried it briefly some time ago. I just remember thinking it was tons better than the UI for 1.
• I like the idea of tying it in with *field. I think, though I'm not positive, that imagefield is getting replaced at some point with filefield. So that gets rid of the problem of imagefield only handling images.
• Choosing directories is overkill for most users. IIRC, you can set it so regular users can't create directories but they still get the same UI. I'd like to see normal users presented with a simple UI that shows all the stuff they have and gives options to add more.

In general, I really like the idea of asset. Having a central repository of media so that you can use an image in your gallery and then put it in a forum post or an article is really nice. It also makes it easier to enforce a per user quota. Then there's the advantage of having one UI for all media on the site, which helps a lot with usability. So I'm glad to see this will be moving into D6.

Michelle

See my Drupal articles and tutorials or come check out the Coulee Region

I just wanted to throw my support in for making Asset more of a helper wizard interface rather than a full blown solution. The more I use things like jQuery media or emfield, the less I use Asset for everything. I'd like the direction you propose, I think it jives with where Drupal is headed.

Just wanted to throw my 2 cents in to support this direction.

(Disclaimer: I haven't explored the new file API for D7 at all, so please forgive me)

Let's imagine for a moment a world of Drupal rich media that works seamlessly for users. Any kind of file is uploaded through the same interface and can be processed and displayed based on mime type.

What might this look like?

Hijack the Drupal file attachments form. Drupal form is completely removed where it is enabled and replaced by... let's call it RMFB (rich media file browser, but you can make up your own name). No more drupal file upload form, and probably we want to hide any CCK file/embed fields (more on this below).

The user clicks on the "add file content" (or something) link. This pops up the new and improved with 100% more awesome 2.0 GUI. User can add embedded content, or upload a file. User is presented with formatting options based on MIME (if admin has allowed). Data is stored in appropriate places.

Here, we create plugins for all of the rich media solutions that we have- embedded filters, image, imagecache, audio, video, etc. There is also a display option for each of these items so that complicated formats can get appropriate treatment (think flash video for example). Again, this should be either enabled by an admin, or preselected for the user.

The final piece is the placement question. How do we know where to put this stuff in a node? Potentially, we have various CCK fields, node body, and maybe some other places I haven't thought of. Here, we build a list of enabled fields in the node (that the admin has selected) and allow the user to place content there, or simply hide the choices all together for the end user, depending on the admin's need.

Obviously what I'm describing here is the GUI layer on top of some pretty complicated file handling stuff. However, with some refinements to Asset's API, we could start getting pretty close. I think it would require some close collaboration between module maintainers, however, done right, we could build a plugable architecture that doesn't bind a site admin to single solutions. And this I think is the really important thing- content doesn't get stuck if a module maintainer stops development. This was one concern I had with media mover, so I set up a system that can go and reprocess original media- you want higher bandwidth .mov files, just create a new configuration and let cron run. Likewise, I think this kind of file system has to respect original media and allow redeployment to the degree that it is possible.

The process might look something like:
* file is uploaded and stored
* choices are made in GUI
* file is processed into new files accordingly
* RMFB has pointers to the original file and processed file
* additional formatting is done
* new content is inserted

Obviously this is not so different than how Asset functions now- what would be different is that we work to create plugins for RMFB that allow us to pull this off, and some refinements to the GUI in appropriate places. And that's really the reality- we have some great solutions already, but they would kick so much more butt if they were integrated.

http://24b6.net

I don't think this conversation is done, however, it does seem like we are moving in a pretty interesting direction quite quickly. I'd personally like to set out what near term goals might be and if people are interested, plan a sprint where a group of interested developers can get together and start coding some of this out pretty quickly.

To move in that direction, here's what I think we need (please add your thoughts)
* define the API - we need to identify what hooks we will offer based on this conversation- perhaps use Asset's as the basis and extend it
* get buy in from as many rich media developers as we can. This will require doing some "lobbying" to convince people that this is a good direction to move in
* get support from people working on D7 file system changes to make sure any work that we are doing will be forward compatible
* identify the "core" of what this module will be and what it will support
* identify goals for the project of what it is and what it is not (ie: we don't want to replace Drupal's file system, we want to build a rich media handling system on top of it, etc)
* get support from development shops that this project would be valuable and supportable

If people are interested, I would try to help put together a sprint to do some of this work. Obviously, the more we can address some of the items above beforehand, the more successful the sprint could be. Are there any places that could host a few people, computers, and lots of media for a weekend?

http://24b6.net

Hi Wim,

I recently became the maintainer for FileField and ImageField. I'm glad to see this initiative to integrate better with other modules. I've personally been anti-"all-in-one" modules because it's analogous to putting all your eggs in one basket. Please let me know if there's anything that FileField can do to help Asset become friendlier with other modules.

FileField already provides some helpful API functions that asset could benefit from, such as backports of D7's hook_file_references() and other hook_file_*() implementations. So you can manage when a file is attached to multiple nodes. I'm also working on patches to CCK that would allow FileField to be extended (more easily) with features like using a browser like IMCE or Asset's file browser, textfield auto-complete for existing files, or referencing of remote files. All this would be enabled by #417122: Allow drupal_alter() on Field and Widget Settings. You can already do all of these things, but the patch would allow individual modules to each complement each other and extend FileField, rather than each module extending FileField separately.

All in all, I'd love to see more integration with other modules. I'm sure asset's pure size makes maintenance extremely difficult, and it'd be great to see tasks provided by other modules leveraged instead of duplicated.

Interesting reading this thread, and I think it reflects a general tendency (which is a good Drupal community characteristic) of trying to tackle the big problems in a cohesive way. But, each type of media, specifically audio and video and images, have significantly different needs and I think that the modular approach with minimal redundancy, inter-module cooperation, and highly focused tasks is a good goal.

But, right now, it is a mess, specifically for video developers. We are in the middle of redesigning our site (treet.tv) and essentially we have tried most of the current modules and have just decided we need to build our own. I hate that. I prefer reuse. But, I thought it would be useful to share my thoughts. I realize I am talking about "video" below, and in some people's minds media should be generic. However, that very generic approach results in a lack of flexibility and power in specific media categories (like video) which inevitably result in hacks, cross-module dependencies, and the kind of frustrating rewrites we are going through now.

First, there are three basic needs that need to be compartmentalized in design thinking:
Problem 1: The need to easily embed 3rd-party videos (emfield has been headed here).
Problem 2: The need to easily store and manage video assets (filefield, et. al. are tackling this)
Problem 3: The need to display video with emphasis on presentation and usability (nobody is really tackling this well, even though many modules include such features almost as an after-thought, such as JW player integration, etc.)

Each of these needs to be separate. You can't have lightbox trying to embed videos and have JW Player appearing as an adjunct to other modules. That may satisfy those who just need an "extra video" feature for their site, and that's all well and good, but in terms of satisfying people who use video as a focus of their business, it doesn't cut it.

In terms of what features are needed in these three problem areas:

Problem 1 featureset: (third party embedding)
* Ease of use, point and click no-headache administration.
* Silent integration with workhorse modules like imagecache, filefield, etc.
* Well thought-out plugin design so that dozens or even hundreds of providers can be added.
* Focus on exploitation of the features and free services of many external providers to that sites can be easily enhanced.

I think emfield is right on target for this. We have been using it (with our own custom provider entry) for weeks now using a custom player we designed based upon flowplayer source code. It's very close to working, and our approach has been to consider our own service almost as an external one (we built a separate api external to drupal to manage video assets, embedding and viral distribution). But, thumbnail management is completely lacking. Worse, integrating imagecache capabilities into emfield/emvideo is a nightmare because thumbnails are a per-provider capability. Trying to tweak or modify the emfield code to support proper thumbnail versatility for the many scenarios on our site proved such a hack that we had no confidence that we could merge in future versions of emfield, and there is no way we want a forked version.

Problem 2 featureset (asset management):
* Infinite mapping of an asset into sub-assets where the asset represents an instance of a creative work (such as a performance) and the sub-assets represent instances of various encoding formats, audio only tracks, closed-caption tracks, bitrate variations, protected HD download versions, etc. A single show we produce has a collection of about 9 different assets which represent the identical program to the viewer. Managing them separately is impossible, they need to be considered a unit.
* Extensible meta-data that can describe the top-level asset fully as well as mappings between the top-level asset and audience-specific (hearing impaired, international translations).
* Exposure of "packaged" presets (HD video, audio podcast) derived from the top-level asset that other modules (such as views, lightbox, etc.) can understand and work with.
* Storage plugins which range from local drupal storage (filefield) to SAN-based storage or storage systems custom-designed for a particular build or platform. In video, this is a must. It also isn't possible to take a "closed system" approach to storage, nor anticipate everybody's needs. So, robust plug-ins for storage are essential, along with mappings between asset records and remote or SAN-based storage paths or resource locators.
* XML-based feeds, such as RSS for providing asset information to third-parties. This is the place for this, and having RSS feeds derived from the many modules in Drupal that support video lacks the control and flexibility that an asset manager could provide.

Nobody comes close to this, and ultimately it becomes tempting to develop a complete information architecture using views and custom content types. But, this turns your drupal site into a nightmare for users and administrators, exposing myriads of irrelevant details of how assets are managed and related to one another.

Yet, creating a good foundation for asset management is, I believe, possible, without taking the over-designed approach vendors like Kaltura are taking. While the needs of asset management can't be ignored, and they are extensive, a small start could be possible focusing on the integration isssues first. Making sure the asset system is known and understood by all other drupal modules is essential, then refining and extending the internal management of assets comes next.

Problem 3 (display and user UI):
* Extensive support for Drupal's goodies. Views, lightbox, imagecache, etc. etc. This is where Drupal is really shining and every video provider wants to use all of these features, not just one or two of them. This delegates the responsibility for presentation fully to the many wondeful Drupal modules in development.
* Glue modules to create presentation forms of assets. Presentation forms (video players, audio players, image gallery browsers, video galleries, multi-track video editors) have specific requirements. While it's tempting to put these into the asset manager, it would be better if the asset manager exposed an api that glue modules could use reliability to present assets. For example, if lightbox wanted to present an asset, they should do so the same way as any other module without having to create hacky support for instances of particular players like JW or Flow.

Right now, many modules focus on this latter problem, and often add asset management features themselves in order to do so. This has provided some great short term value. But, as D7 and D8 come out, the range of such presentation and UI needs will grow significantly and the asset management needs to be separated.

I apologize for publishing such a "feature manifesto" and wish-list, but it based upon a lot of experience. While we are focused entirely on our internal development, at some point in the future once we get past some milestones we surely would be interested in contributing to such an effort as well.

Not everybody wants to be a full-service video provider, so I realize that our needs are not shared by the majority. But, I think it is an admirable goal to have a modular system which satisfies everybody, from those who want full control of video to those who want an occasional YouTube clip embedded and I hope my comments above provide useful in some small way at some point.