Hierarchical media tags / media collections

Creating Neos & Flow
1

I’m trying to find out how I could optimize work with media.

The website was managed with TYPO3 before and will now be transferred to NEOS. In TYPO3 we had 400 Files separated in 44 directories with an hierarchical structure.

I have a structure like this:

  • Concerts
    • 2014
      • Image 1
      • Image 2
      • Image 3
    • 2015
      • Image 4
      • Image 5
  • News
    • 2014
      • Image 1
      • Image 2
    • 2015
      …

Now I could create tags for Concerts, News, 2014 and 2015. Then add the tags to the media. So Image 1 would get the tags Concerts, 2014 and News. That’s fine so far.

But then when I would like to add a image node and select my media, I can’t say: "filter and show me all media, that have the tags 2014 and Concerts. Or is that somehow possible and I didn’t figure out how?

Since creating collections is only allowed for administrators, this isn’t a solution as well. Is there a possibility to give normal editors the rights to manage collections or something similar?

And is there a way to filter the list of tags, so that I could find the tag faster to activate it?

2

Hi Erich,

the media module is currently a bit limited in that regard.
We will start a rewrite of the module early 2020. When we reached a certain point we will certainly need support from the community. Maybe your company can also help us then also.

You currently can modify your policies to also allow editors to create collections. Each collection can have tags assigned. When a collection is selected only its tags are shown.
This allows at least a bit of hierarchy.

3

Great! Thanks for the hint.
I fond a documentation for the policies here:
https://docs.neos.io/cms/manual/backend-permissions/real-world-examples

So I could manage the persmissions for the management of collections for the role editor. This helps for the moment.

But the other features would still be very useful.

1 Like
4

hi!

in the video “Ein Blick auf NEOS CMS ( TYPO3 Usergroup Bodensee, 19.01.2021)” your dev repeats that you want to implement some hierarchical structure for the media library.

the dev is also talking about different ideas on how to implement that.
i want to add an proposal.

disadvantage of filesystem-like directory structure

a plain filesystem-like structure has the major drawback that every file belongs to exactly one branch in the filesystem tree. users would have to decide which directory fits best (which will not work, because people have different ideas of order) or they will start creating copies of files in different directories which is even worse.
of course, you could create something such as symlinks or hardlinks, but that might lead to other/new problems.

proposal: hierarchical tags

a nice way to get rid of that disadvantage is the way that mediawiki uses:
mediawiki has a similar flat structure of data as neos has. but the tags (which are called “categories” there) are hierarchical. this means, tags can be tagged themselves. it is very easy to add a media file to several branches in an arbitrarily large tree by just adding several tags/categories that that file belongs to. and the user does not need to know the whole hierarchical structure. if an image contains a flower, the image may just be tagged as “flower”. the user does not need to search the parent tag/directory (“botany”? or “flora”? or something else?).
and still the files are can be accessed without hierarchical structure, too, because the files themselves are not structured in directories.
additionally this method enabled users to search with filters by set-theory-based functions (union, intersection, …).
and finally mediawiki has a dublicate detector that prevents files from being uploaded several times.

so in my opinion this is one of the most flexible and still easy ways to structure media files.

2 Likes
5

Hi Seth,

Welcome to the community and thanks for your input! :slight_smile:

We actually added support for hierarchical tags in the core some releases ago but didn‘t make it accessible via the UI yet as our approach „didn‘t feel right“ yet.

We wouldn‘t throw away the tags and collections we now have. And the framework already takes care of duplicate prevention. So the folder like structures would just be another view (with its own metadata) on the same assets. You wouldn‘t need to use them as it would be optional.
Of course in a folder like structure each asset would only belong to one folder. If you want to tag assets you still have the tags or put them into collections.

It’s not fully clear yet how we approach this from a UX perspective because all three structure types have their own benefits and advantages but we will probably do some prototypes for it when the time comes.

The problem with nested tags is that they allow interconnected structures and recursion. So you have to prevent that from happening. Also it‘s hard to show where an asset is in a structure like that. And we have the problem with naming. Currently it would cause problems to have two tags with the same name. So when editors want to sort their assets for newsletters into date based structures we would have problems with duplicate months and days f.e.

File managers in operating systems solved this by having one level of tags and their folder system.

For me allowing the editor to use the system that best fits their needs depending on the usecase would be great. The biggest problem for me is the UX and how to make all those options „obvious“ to use.

What do you think?

2 Likes
6

hi!

thanks for your answer! :slight_smile:

i agree with the first part, i.e., if the ability for a hierachical file structure is implemented that does not mean that it needs to be used. however hierarchical file structures have less possibilities than tags do, as i said above. (in fact the strict file hierarchy is a tree and as such almost just a special case of the possibilities of tags which provide a net-like structure.)

The problem with nested tags is that they allow interconnected structures and recursion.

why is that a problem? i’d call interconnected structures a benefit. :slight_smile:
and concerning recursion, well, that does not need to be a problem. if people want to use circular structures, why don’t let them use those?
on the other hand: it shouldn’t be a problem to detect circular nested structures and warn the users if they are about to do such things.

Also it‘s hard to show where an asset is in a structure like that.

i’m not sure, whether i understood this correctly. what exactly is needed, but would be difficult?

And we have the problem with naming. Currently it would cause problems to have two tags with the same name. So when editors want to sort their assets for newsletters into date based structures we would have problems with duplicate months and days f.e.

i don’t see a problem here. let’s take the initial example:

the hierarchical structure:

  • Concerts
    • 2014
      • Image 1
      • Image 2
      • Image 3
    • 2015
      • Image 4
      • Image 5
  • News
    • 2014
      • Image 1
      • Image 2
    • 2015
      • …

would be restructed with tags as:

  • Image 1 – tags: 2014, Concert, News
  • Image 2 – tags: 2014, Concert, News
  • Image 3 – tags: 2014, Concert
  • Image 4 – tags: 2015, Concert
  • Image 5 – tags: 2015, Concert

there’s a bijective mapping between those structures. however the tagged structure is more flexible.
of course there has to be a good search interface where the user can filter the results by saying “i want all concert pictures from 2014 that were not in the news” or alike. but that should not be a problem. almost every web shop provides such filters.

For me allowing the editor to use the system that best fits their needs depending on the usecase would be great.

Yes, that sounds good, and i understand that this is not easy as the users are extremely heterogeneous.

7

Hi all,

thanks for your answers.

I would be happy to see the current type of asset management and the asset management with hierarchical tags (as beta feature) as two different nodes in the menu. With the possibility to activate them depending on user rights.

In projects with less assets the current version is fine. But as soon as you get hundreds of assets and lots of tags managed inside of NEOS the management is really boring and even hard to explain to editors.

I think adding it as beta feature would give a lot of cool ideas and feedback for UX. Searching for assets during assignment should definitely get the main focus.