RFC: Media Module Improvements / Extendability

daniellienert · December 30, 2017, 11:00pm

Disclaimer: With this thread I just want to kick of some discussion about Media Module improvements and extendability. No real solutions provided yet

The Problem

Media Module not extendable

For a customer project, I need to store license information with the assets and make them editable for the editors. The right place to do this is the Media module. But the module has no extension points. To add one field most of the templates and the controller (so nearly everything) needs to be exchanged.

Tags do not scale

Tags are used by photographers to describe a picture - a picture from DPA eg. may contain around 20 tags. The tags are also used by editors to structure the assets. The tag-sidebar is not capable to display a lot of tags clearly and it flips to the bottom when a few tags are available which makes it even more unusable.

Additional Info

Asset Meta Data Storage

With https://github.com/neos/metadata-contentrepositoryadapter it is possible to store arbitrary asset meta data using the CR and https://github.com/neos/metadata-extractor already extracts meta data from images. That makes the storage part completely flexible as customer-related properties can be added like for every other node.

Goal

The goal is an overhaul of the media module, addressing the problems above. My Idea would be to copy ideas of the content module - especially the inspector concept and lend some ideas from powerful image libraries like Adobe Lightroom. This is a first clumsy photoshop mockup of what I have in mind:

Basically the Detail View / Editing moved to the inspector. A configurable filter bar in the top filters by relevant attributes. The complete Media Module is a drop zone now, the drop zone is removed to gain space for filters and more thumbs.

Technical thoughts / to discuss

My first idea was to exchange the Fluid views with Fusion to make them extensible. Also extension points to the controller would be necessary to load and save the meta data of an image and to extend the search with additionally provided filters and search on all meta data.

Such a rewrite feels doable. The question to discuss is, if the next Media Module should also be build on react and should use the same technologies as the content module, which of course is a way bigger task but would offer much more flexibility and a lot more application-like interface.

I really looking forward to hear your opinions on that topic.

christianm · January 4, 2018, 10:06am

I was hoping to rewrite the media module to react (as well) to be in line. That would mean extensibility would mainly be done via JS, but could be possible.

I am open to both.

I would like to see nested Tags ASAP if we can do. And yes the metadata integration would be super great as well.
I also wouldn’t mind if in the process the media module was changing overall, if that’s needed to get the job done.

mficzel · January 4, 2018, 10:59am

I also think that react and the inspector editors from the new ui are the best choice for that. It would be great to finally have extensible nodes for assets.

mficzel · January 4, 2018, 11:01am

Regarding tags i would rather see a generic taxonmy feature for the whole cr (i am playing around for that currently). So this should imho be tackled seperately.

dfeyer · January 8, 2018, 9:32am

I think we have different project here:

Relaunch the Media Browser based on React
A generic Tag manager (usable for Asset, Node, Model, …), the current projet from Sitegeist (@mficzel) can be intersting here
Meta data extraction API

Both project can be run in parallel, but the the most important one currently is 1.

I love the idea use pattern from the content editing (Inspector, …). And this is really important to use the Module to build the missing (if something is missing) React based API / pattern and we can use this module to showcase how to build a React based backend module.

The mock up by @daniellienert is a good foundation. But I think need an other design iteration, I will hide the filter in a sub panel, to make it more scalable (in the future in can be nice to add more filters based on custom metadata, … and the current design does not scale)

It’s a good opportunity to have our first responsive module (design, and some feature like image/video upload from mobile).

I can try to design the next iteration this week and push to discussion in Guild UX on Slack and here.

We can take inspiration from Lightroom/Darktable (https://www.darktable.org/):

dfeyer · January 9, 2018, 5:56pm

Basic Media Module with Grid Preview

The search can support advanced feature, like tag filtering, … so it’s big enough.

File icons are simple SVG with extension name as text.

We need a better pattern when no preview is available.

When an asset is selected/hovered, action icons are visible

Filter panel

Filter pattern are stolen from Youtube (gray: available, white: selected, light: unavailable).

Open question, how to handle long list of filter (like tags, collections), maybe just a scrollable area, with active filter on the top of the list.

Batch Actions

Inspired by what Google Inbox did, the search is replace by a batch action toolbar as soon as one ore more element are selected. The toolbar can have a feature to show only selected items or trigger batch actions (delete, edit, …).

Edit: updated the batch action, with the selected asset visible in the inspector.

Multi select on Ctrl+click

Asset Preview

The Asset preview is design to be reusable as the default Image preview in the inspector.

If you agree on the direction I can explore a bit more

daniellienert · January 10, 2018, 2:28pm

Absolutely great @dfeyer! Thanks a lot.

Some remarks to the filter panel:

I wouldn’t put the sorting and the view under filters, but into separate panels.
A scrollable list for long filter lists would be great
Lightroom solves the problem of arbitrary filter dimensions by having a fixed number of “filter slots” and a selection to select the dimension. That would make the filter easily customizable by the users needs:

dfeyer · January 10, 2018, 9:02pm

More panels, more buttons … not sure, Youtube did it why not …

Some filter list will be small, so I prefere a bit more visibility on the available filter if possible. But yes for big list (tag, …) we should support this kind of UI pattern (full scrollable list).

robert · January 18, 2018, 10:36am

Hi folks, a little late to the game, but nevertheless …

I really like the approaches you suggested so far and maybe I can contribute something concrete for yet another part of the Media Browser.

For one of our customers I implemented a way to integrate a third party asset management system (in this case “Elvis”) to Neos. There were three major goals I followed for my implementation:

the external assets should appear as one of multiple possible asset sources and work side-by-side with the built-in Neos assets
as soon as an external asset is being actively used in Neos, it should be imported. Previously imported assets which are not used anymore should be automatically removed. All that happens transparently to the user and does not conflict with or mess up the built-in Neos asset source (ie. imported assets won’t appear in Neos asset source)

I introduced two new basic concepts: “Asset Source” and “Asset Proxy”. Asset sources are additional sources, like “Elvis”, Dropbox, Google Drive, Neos, you name it. Asset Proxy is a replacement for the concrete Asset and used in the Media Browser. It encapsulates things like metadata, thumbnails etc. so you can display assets in the Media Browser without actually downloading any of the assets.

In order to make the new features working for our customer as soon as possible, I decided to copy all the existing Media Browser package code into a new package (as of November 2017) and refactor the code rigorously. I did not touch anything in the Neos.Media package.

So, the new package is a drop-in replacement for Neos.Media.Browser. It introduces these new features, but it is still using the old / current UI (no real improvements there). My plan / suggestion is:

Discuss the Asset Source concept with you guys. And if you agree to it …
… port all the changes I created into the Neos.Media.Browser package

Ideally this would happen before we start tackling the UI re-design / re-implementation.

One task I also would like to work with you together on is metadata, as this should also go well along with these external asset sources / proxies.

If you’re curious, you can take a look at my changes here: https://github.com/flownative/neos-media-browser
I’ll check if I also can publish the Elvis adaptor I created, for further reference.

What do you think about this?

sebobo · March 2, 2020, 12:19pm

As the project has now actually started. Join the #project-new-media-ui channel in Slack for the project organisation.

Thanks for all the super helpful mockups and ideas!

simonschaufi · March 2, 2020, 3:57pm

I wish there will be features like image processing also considered like rotate for example.