Media Manager Next

[kongondo]

Hi all,

Media Manager Next/013

Sorry I haven't posted here in a while. 

I am currently working on the next version of Media Manager. It will part be refactoring and part be some new (some requested) features. I have been having some very helpful conversations with a number of you. Below are the current plans for the next version. Any other thoughts and/or ideas I should consider? It is a bit of work so I might have to stretch this into several updates (versions). Thanks.

New Features

1. Upload from external sources (Amazon, Google, etc.).
2. Point media to external resource (e.g. to a video in YT, Vimeo, etc.).
3. Independently set media title on upload 
4. Improve/extend media filter/profiles to MM Inputfields (possibly pick and apply a profile from a list) (thanks @gebeer)
5. PDF thumb preview (thanks @gebeer)
6. Upload and replace media (for single media MM inputfields).
7. API (thanks @MrSnoozles)
8. Any other thoughts.....?

Refactor

1. Remove dependency on JqueryFileUpload
2. Remove dependency on jQuery -> use htmx and alpine JS instead. Easier to maintain for me as well as more flexibility.
3. Improved preview of media and their properties.
4. Better preview of media before upload.
5. Redesigned GUI - Intuitive (like GDrive(?)), do away with media menus (use filters instead), need oMedia is just media.
6. Remove/reduce use of modals.
7. Allow grouping of media (link an album) <- not yet confirmed if will be implemented
8. Implement hookable methods to allow easier developer control for those who need advanced/custom control of their MM.

A number of reported bug fixes as well.

ETA? I cannot give a firm date about this, sorry.

Edited March 30, 2023 by kongondo
Added new feature 'API'

[David Karich]

Two questions where I just read that you are working on a new version.

1. what about focus points, can I define them differently on a per page basis? Or is a set focus the same for all instances of the image? If so, I would like to see this feature that I can define a different focus per page where I use an image.

2. if I buy a license for the current version now, will it be updateable for the new version or are there any breakers here. I'm building a new project with thousands of images to be managed through the MM, so if in half a year, or whenever the new version is ready, a complete reinstall or upload is necessary, I'd rather wait until you have the new version ready.

[kongondo]

Hi @David Karich,

19 hours ago, David Karich said:

1. what about focus points, can I define them differently on a per page basis? Or is a set focus the same for all instances of the image? If so, I would like to see this feature that I can define a different focus per page where I use an image.

I would have to look into this since I haven't worked with focus points before. My guess is that they are saved with the image, in which case they will be saved with the record for the original image in the MM page (i.e., not the page where the MM image is referenced in an MM Inputfield). I'll see if/how I can extend FieldtypeMediaManager to store focus information (and perhaps other info developers might be interested in) which you will be able to access via the MM object.

19 hours ago, David Karich said:

2. if I buy a license for the current version now, will it be updateable for the new version or are there any breakers here. I'm building a new project with thousands of images to be managed through the MM, so if in half a year, or whenever the new version is ready, a complete reinstall or upload is necessary, I'd rather wait until you have the new version ready.

I am hoping there will be no need for breaking changes. However, until I finish building it, I cannot promise. If such changes are inevitable, I'll provide code for migration. However, with the minimal progress I've made so far, I haven't encountered any breaking changes.

[David Karich]

On 3/1/2023 at 6:26 PM, kongondo said:

Hi @David Karich,

I would have to look into this since I haven't worked with focus points before. My guess is that they are saved with the image, in which case they will be saved with the record for the original image in the MM page (i.e., not the page where the MM image is referenced in an MM Inputfield). I'll see if/how I can extend FieldtypeMediaManager to store focus information (and perhaps other info developers might be interested in) which you will be able to access via the MM object.

I am hoping there will be no need for breaking changes. However, until I finish building it, I cannot promise. If such changes are inevitable, I'll provide code for migration. However, with the minimal progress I've made so far, I haven't encountered any breaking changes.

Hi @kongondo, 

thank you for your feedback. Since you still ask for wishes for the new version, here are two more. ?

Just like the focus point, it would be very helpful to save the image description differently per page base. Example: I want to use a image several times in an article, but I want a different caption in each article.

And the biggest wish I have to pass on: Folder, folder, folder. My clients love thinking in folders. It doesn't even have to be a real folder for PW, but just a "fake page tree". The main thing is to have the feeling of having something organised. In this context, a configuration would of course be necessary, where you can, for example, specify where the image is automatically categorised when uploading.

An example of how it is solved, for example, in the WP-media Library as an extra plugin. Article: https://devowl.io/2020/create-folders-in-wordpress-media-library/

[gebeer]

9 hours ago, David Karich said:

And the biggest wish I have to pass on: Folder, folder, folder. My clients love thinking in folders.

Same experience with our clients. They are coming from TYPO3 and are used to organize media in folders. Trying to explain that the MM approach is much more flexible. But they'd still love to have their folders back. Technically this would mean that there is some kind of default categorisation apart from media type. I think using tags would be the best and most flexible method.

[kongondo]

Hi @David Karich,

On 3/6/2023 at 4:09 PM, David Karich said:

thank you for your feedback. Since you still ask for wishes for the new version, here are two more. ?

Excellent! Keep them coming please! ? .

On 3/6/2023 at 4:09 PM, David Karich said:

Just like the focus point, it would be very helpful to save the image description differently per page base. Example: I want to use a image several times in an article, but I want a different caption in each article.

I think I could incorporate this in the FieldtypeMediaManager as well. It would have to cater for multilingual texts as well. The challenge would be the GUI. I'll have a think.

On 3/6/2023 at 4:09 PM, David Karich said:

And the biggest wish I have to pass on: Folder, folder, folder. My clients love thinking in folders. It doesn't even have to be a real folder for PW, but just a "fake page tree". The main thing is to have the feeling of having something organised.

I really love this idea! In a sense this is what I meant by 'Album/grouping of media' but you have articulated it way much better, so thanks! I agree; there is no need to make them 'real folders'. We just need to create a relationship at the DB level and show the virtual representation of that in the 'tree'.

On 3/6/2023 at 4:09 PM, David Karich said:

In this context, a configuration would of course be necessary, where you can, for example, specify where the image is automatically categorised when uploading.

The more I think about it the more I think we need to 'get rid' of the uploads page. It seems to me like an extra step that we don't need. Certainly many modern apps (that our clients could be used to) don't separate the 'upload' from the 'view'. It is a single view for both. Yes, we can have a setting for 'default' category, maybe even separate for the 4 media types (just brainstorming here!). Otherwise, if one drag and drops whilst viewing a certain category, that media will be assigned to that category.

Can a media belong to more than one category? Either way is doable; I am just curious about your experience and/or the WP plugin.

On 3/7/2023 at 1:57 AM, gebeer said:

But they'd still love to have their folders back. Technically this would mean that there is some kind of default categorisation apart from media type. I think using tags would be the best and most flexible method.

Virtual folders would provide the best of both worlds. Clients get to see their folders but behind the scenes we continue to use the ProcessWire/MM way. By tags, do you mean the inbuilt ProcessWire image/file fields tags?

 

A question to you all, how does the powerful but potentially confusing inputfield selector work for your clients? Do they use it or would you prefer a simpler interface such as the WP one in the screenshot shown above by @David Karich?

Thanks!

 

[nurkka]

Hi @kongondo

First of all thank you for the awesome plugin!

1 hour ago, kongondo said:

A question to you all, how does the powerful but potentially confusing inputfield selector work for your clients? Do they use it or would you prefer a simpler interface such as the WP one in the screenshot shown above by @David Karich?

It would be really awesome if the selection would run through an interface with a folder structure. And it would be perfect if one could define per template in which folder the selection would start.

An example: Assuming we have a folder "Employee photos" and a folder "Customers" (or a lot more folders and subfolders ? ), then it would be perfect if one could give the input field the information that the image selection on employee detail pages starts in the folder "Employee photos". That would be much easier for the clients/editors to work with.

And without a folder structure, it would be great if one could define per template with which category or tag the input field starts, i.e. to have a ore-defined filter setting per template.

[kongondo]

Hi @nurkka,

Thanks for chiming in.

1 hour ago, nurkka said:

It would be really awesome if the selection would run through an interface with a folder structure.

Yes. Perhaps my question wasn't clear. I am all for this folder structure. What I was referring to in my question about inputfield selector is whether we could also simplify that. So, yes, I definitely love the folder structure and will definitely prioritise that. 

 

1 hour ago, nurkka said:

An example: Assuming we have a folder "Employee photos" and a folder "Customers" (or a lot more folders and subfolders ? ), then it would be perfect if one could give the input field the information that the image selection on employee detail pages starts in the folder "Employee photos". That would be much easier for the clients/editors to work with.

This is a very interesting suggestion, thanks! I really like it as well! I think it would tie in nicely with the request to make it easier to use profiles in inputfield media manager. 

@David Karich (or any other person who knows), in the WP Media Lib, if the user clicked on the folder 'People', would that then display media for both 'Men' and 'Women' but if they clicked on 'Women' that will only show 'Women' media? I can't tell because the counts are not showing for some 'parent' folders such as 'People' and 'Office'.

[David Karich]

15 hours ago, kongondo said:

@David Karich (or any other person who knows), in the WP Media Lib, if the user clicked on the folder 'People', would that then display media for both 'Men' and 'Women' but if they clicked on 'Women' that will only show 'Women' media? I can't tell because the counts are not showing for some 'parent' folders such as 'People' and 'Office'.

@kongondo Sorry, I'm a bit tied up at the moment. But it behaves like real folders. When you click on "People", only two folders are displayed, but no pictures from both subfolders. I would also prefer this. Inheriting subitems in the view works well for a few folders, but not for 20, 50, 100 and then recursively over several levels lower.

[nurkka]

Hi @kongondo

2 hours ago, kongondo said:

Yes. Perhaps my question wasn't clear. I am all for this folder structure. What I was referring to in my question about inputfield selector is whether we could also simplify that.

It would be nice to have a full text search, which would always be visible.
If this is not possible, it would be nice, if the filter would be always open, so one can start typing immediately and previously set filter values would be visible right away.

Also a more compact view for pdf documents would be great, because the current grid and list view both require a lot of space if one has some hundred pdfs in the library. In a past project I added the pdf filenames to the grid view by modifiying some javascript files, to have a more compact view with the filenames visible. Perhaps, pdf icons could be a lot smaller or omitted at all in the document view.

The UI elements could be smaller and information like how many times an image was used, filesize, etc. could be hidden and made visible with a toggle button, so everything would take up less space and more image and document items would fit on the screen.

[gebeer]

13 hours ago, kongondo said:

Otherwise, if one drag and drops whilst viewing a certain category, that media will be assigned to that category.

That would be perfect! ATM there are too many steps involved when tagging uploaded media. Doing the tagging based on the "folder" would be a big improvement.

 

13 hours ago, kongondo said:

Yes, we can have a setting for 'default' category, maybe even separate for the 4 media types (just brainstorming here!).

I agree this should be separate from the media types. Maybe something like "uncategorized"

13 hours ago, kongondo said:

Can a media belong to more than one category? Either way is doable;

This should definitely be possible. So media that has multiple categories would appear in multiple virtual folders.

 

13 hours ago, kongondo said:

By tags, do you mean the inbuilt ProcessWire image/file fields tags?

Yes and no ? The inbuilt image/file tags could be used in the background to store the tags. But for editing I would prefer if I did not have to edit an image before I can input tags. It would be cleaner and faster for editors if they can just edit tags directly without having to go the extra step to edit the image. So the tags field would have to live on the MM page that holds the media. Does that make sense?

Also there should be a way how we can pre-define available categories. Just like we can pre-define available tags for aan image/file field.

13 hours ago, kongondo said:

A question to you all, how does the powerful but potentially confusing inputfield selector work for your clients? Do they use it or would you prefer a simpler interface

The simpler the better ? Almost all of my clients are overwhelmed by PW Lister filters. Even with predefined filter profiles it is hard for non-techy people to understand the concept and what they see in the dropdown selects. I think this is a very tough one to tackle. If you have just one search input like in WP, you get back results that you where not looking for because the search is too broad. Maybe a combination of a text input that searches for file names and one select dropdown that determines the category you want to search in could work? 

7 hours ago, David Karich said:

When you click on "People", only two folders are displayed, but no pictures from both subfolders. I would also prefer this. Inheriting subitems in the view works well for a few folders, but not for 20, 50, 100 and then recursively over several levels lower.

Totally agree. It could be a configurable option whether to include files from subfolders in the view or not.

5 hours ago, nurkka said:

Also a more compact view for pdf documents would be great, because the current grid and list view both require a lot of space if one has some hundred pdfs in the library. In a past project I added the pdf filenames to the grid view by modifiying some javascript files, to have a more compact view with the filenames visible. Perhaps, pdf icons could be a lot smaller or omitted at all in the document view.

Great suggestions. For the time being a config option for icon size would be helpful. Or do the Preview maximum width/height settings already have an effect on those icons?    

[David Karich]

20 hours ago, kongondo said:

A question to you all, how does the powerful but potentially confusing inputfield selector work for your clients? Do they use it or would you prefer a simpler interface such as the WP one in the screenshot shown above by @David Karich?

@kongondo From my experience, my clients are overwhelmed with the InputfieldSelector and Lister and don't know what to do with them. I would also prefer a very simple approach here: "Search field for text", optional filter options in a simple UI: file type, time period (of the upload).

[David Karich]

17 hours ago, nurkka said:

Hi @kongondo

First of all thank you for the awesome plugin!

It would be really awesome if the selection would run through an interface with a folder structure. And it would be perfect if one could define per template in which folder the selection would start.

An example: Assuming we have a folder "Employee photos" and a folder "Customers" (or a lot more folders and subfolders ? ), then it would be perfect if one could give the input field the information that the image selection on employee detail pages starts in the folder "Employee photos". That would be much easier for the clients/editors to work with.

And without a folder structure, it would be great if one could define per template with which category or tag the input field starts, i.e. to have a ore-defined filter setting per template.

Very good approach, but possibly not or not only via a template approach. I am very fond of the PW-internal possibilities of input and field dependencies (https://processwire.com/docs/fields/dependencies/). Here is a productive scenario of how I run it in an editorial workflow on another system I developed from scratch: 

• The article template has the input fields date, category of the article (page reference or select), article images, etc. 
• The editor can upload new images (or select existing ones from the library and add them) directly to the input field of the article images by dragging and dropping. 
• When the new images are uploaded, they are automatically assigned in the library on the basis of the selected category and date. This eliminates a complete step of manual assignment for editors.

@kongondo My idea for the MM: to enable a configuration for the input field that assigns new images to defined categories on the basis of other fields of the template and their values when they are uploaded. If this option is not configured, then I would also prefer the default behaviour "uncategorised" as lying in a "root folder" and the editors have to clean up themselves.

[David Karich]

@kongondo And because it is so much fun to think about the new MM and which requirements are more difficult to implement so far, I have another feature request. ?

I have a few multi-language websites that keep running into the problem that different images have to be displayed depending on the language, e.g. because there is text on the images.

Currently, I can only solve this in a complicated way using the PW-internal option with image tags. Personally, I find this a design workflow break in the whole PW concept, because the rest works wonderfully with the LangTabs modules. Perhaps also a feature request to @ryan at this point. ?

My wish here would be to map the MM-InputfieldImage in the same way as multi-lang text fields. So with a simple language switch, select another item from the library.

[kongondo]

Thanks @David Karich, @nurkkaand @gebeer for the great insights and suggestions!

On 3/10/2023 at 7:08 PM, David Karich said:

But it behaves like real folders. When you click on "People", only two folders are displayed, but no pictures from both subfolders. I would also prefer this. Inheriting subitems in the view works well for a few folders, but not for 20, 50, 100 and then recursively over several levels lower.

Thanks for confirming. I now see how displaying all items from nested folders in the parent folder view can be problematic.

On 3/10/2023 at 8:38 PM, nurkka said:

It would be nice to have a full text search, which would always be visible.

I have been thinking of this (as a 'simple search') that is always visible and underneath that a link to click to reveal the 'advanced search'. This could either be a 'toned down' lister (e.g. some system settings not visible as clients perhaps don't use this) or a (configurable?) custom filter/lister that has only the most relevant features such as date, title, etc?

On 3/10/2023 at 8:38 PM, nurkka said:

and previously set filter values would be visible right away.

Yes, can work this in. Either cookies, local storage or session.

On 3/10/2023 at 8:38 PM, nurkka said:

Also a more compact view for pdf documents would be great, because the current grid and list view both require a lot of space if one has some hundred pdfs in the library. In a past project I added the pdf filenames to the grid view by modifiying some javascript files, to have a more compact view with the filenames visible. Perhaps, pdf icons could be a lot smaller or omitted at all in the document view.

I agree about the need for compactness and even make this configurable. A visual to mockup to get more going would be great if you could show me one, thanks.

On 3/10/2023 at 8:38 PM, nurkka said:

The UI elements could be smaller and information like how many times an image was used, filesize, etc. could be hidden and made visible with a toggle button, so everything would take up less space and more image and document items would fit on the screen.

Agreed. I am leaning toward how it is done in GDrive, with the 'view details' icon opening the details pane on the right.

On 3/11/2023 at 2:43 AM, gebeer said:

ATM there are too many steps involved when tagging uploaded media.

Yes, agreed.

On 3/11/2023 at 2:43 AM, gebeer said:

I agree this should be separate from the media types. Maybe something like "uncategorized"

Good idea.

On 3/11/2023 at 2:43 AM, gebeer said:

The inbuilt image/file tags could be used in the background to store the tags. But for editing I would prefer if I did not have to edit an image before I can input tags. It would be cleaner and faster for editors if they can just edit tags directly without having to go the extra step to edit the image. So the tags field would have to live on the MM page that holds the media. Does that make sense?

Definitely agree. Tagging process should be as easy as possible for editors. In terms of the DB layer, I thought a bit about using the inbuilt image tags but now I am leaning toward saving these separately as 'categories', one per page. Although I am still thinking about this, one page per category has many advantages, including:

1. Management: Managing all categories in one place: e.g., categories 'animal', 'dog', 'cat' are easier managed in one place rather than in image/file tags. Editors wouldn't have to know or worry about these pages. Their only interaction would be creating, managing (editing, deleting, etc.) categories.
2. Editing: Edit once, edit everywhere: If we wanted to change 'dog' to 'Canis lupus familiaris' for instance, we can do it easily in one place just by editing the category 'dog' instead of updating image/file tags.
3. Inputfield Control: Per template category control of available media (suggested by Nurrka) Using pages would make this implementation much easier, e.g. if people is a category, and an MM inputfield is limited (at template level) to only allow media in people category, we would only allow selection and storage of people children, i.e. categories 'men' and 'women', for instance.
4. Category Tree: This will help with building the tree on the left. It is easier than to fish for tags saved in media. It is easier to work with what is referenced (the categories) instead of the 'referrer' (the media themselves) in this case.
5. Nesting: It is also easier to nest categories (folders) if the are pages instead of image/file tags.
6. Multilingual: Page titles (category titles) can be multilingual; image/file tags are not.
7. Customisation: Pages allow one to scale as much as they need to. Say, in future, you want your categories to have a description or some other field, developers can easily add extra fields to the MM categories template.

On 3/11/2023 at 2:43 AM, gebeer said:

Also there should be a way how we can pre-define available categories. Just like we can pre-define available tags for aan image/file field.

Agreed. In my thinking above, this would be a new 'Manage Categories' MM view. Predefined categories will force editors to only pick from these categories. We can perhaps use the details pane on the right (like GDrive) that I am thinking of as mentioned above for this. Editors could then apply categories to a selected media. Choices would be in a Selectize input. In this details pane, just like GDrive, if one media is selected, we show you its details, plus have the input for categories. If multiple media are selected, we don't show details, just manage/add categories input. 

I'll have a think about whether to retain the current MM bulk apply/remove 'tags'. Also, whether to retain this feature at all (i.e., the current 'tags'.) given that 'categories' are a more powerful feature (at least that's what I think).

On 3/11/2023 at 2:43 AM, gebeer said:

Almost all of my clients are overwhelmed by PW Lister filters. Even with predefined filter profiles it is hard for non-techy people to understand the concept and what they see in the dropdown selects. I think this is a very tough one to tackle. If you have just one search input like in WP, you get back results that you where not looking for because the search is too broad. Maybe a combination of a text input that searches for file names and one select dropdown that determines the category you want to search in could work? 

Thanks for the feedback. Maybe my suggestion for a 'simple' default search and an 'advanced' one would help with this issue?

 

On 3/11/2023 at 2:43 AM, gebeer said:

Totally agree. It could be a configurable option whether to include files from subfolders in the view or not.

Good point, maybe even add a configurable threshold, e.g. if 20 or more items, grab first 20 then show text like '+ 150 more' or similar.

On 3/11/2023 at 2:43 AM, gebeer said:

For the time being a config option for icon size would be helpful. Or do the Preview maximum width/height settings already have an effect on those icons? 

Another great suggestion! We can make this configurable.  No, the preview min/max are just for the upload (They are jQuery File Upload options).

 

[kongondo]

On 3/11/2023 at 9:27 AM, David Karich said:

From my experience, my clients are overwhelmed with the InputfieldSelector and Lister and don't know what to do with them. I would also prefer a very simple approach here: "Search field for text", optional filter options in a simple UI: file type, time period (of the upload).

Thanks for the feedback.

On 3/11/2023 at 9:42 AM, David Karich said:

My idea for the MM: to enable a configuration for the input field that assigns new images to defined categories on the basis of other fields of the template and their values when they are uploaded. If this option is not configured, then I would also prefer the default behaviour "uncategorised" as lying in a "root folder" and the editors have to clean up themselves.

I'll have a think about this @David Karich. It does sound like something that could be accomplished via a Hook. 

On 3/11/2023 at 9:51 AM, David Karich said:

My wish here would be to map the MM-InputfieldImage in the same way as multi-lang text fields. So with a simple language switch, select another item from the library.

Very interesting idea. So, the images themselves (the pages in MM library) would be language-unaware but the MM Inputfields would be language aware (perhaps configurable) and fall back to default language media if no media in 'other language'.  I am not good with GUIs so any mock-up for this that I can get would be appreciated. Although, for consistency, it should perhaps mimick the current image fields language tabs.

Lots to think about for me but thoroughly exciting! ? 

[gebeer]

15 hours ago, kongondo said:

I thought a bit about using the inbuilt image tags but now I am leaning toward saving these separately as 'categories', one per page.

Great idea. This is the most flexible way of handling categories. Go for it ? 

[MrSnoozles]

@kongondo Just want to let you know I'm super happy development on the module continues. The functionality of the current version is great, it's just a bit unpolished compared to file managers from other CMS.

As for new features: I agree with the others, folders and simplified search (+ advanced filtering) are definitely my top two wishes too. Also easier API access to render media in the frontend would be a nice to have. If I remember correctly it was a bit more complicated to use than the usual ProcessWire API.

Super excited for the updates, thank you!

[kongondo]

8 hours ago, MrSnoozles said:

The functionality of the current version is great, it's just a bit unpolished compared to file managers from other CMS.

Agreed! 

8 hours ago, MrSnoozles said:

Also easier API access to render media in the frontend would be a nice to have. If I remember correctly it was a bit more complicated to use than the usual ProcessWire API.

Great thoughts! I've thought about this before. I am keen to work on it. A $mediaManager variable will make it very easy to interact with MM in the frontend. This will make it easier to directly use media items in the frontend. For instance, directly build a photo gallery using images from the library without the need to add these to a page first. It will also make it easier to manage media items using the API, import items into the library, etc.

I have updated the the MM Next plans post.

[gornycreative]

Hey @kongondo I just realized you were redoing this - wow!

If I could suggest two places to look for inspiration from the UI side. WP is nigh unusable out of the box for a number of clients in terms of both media and filtering and the two favorite plugins I deploy to handle these have always been Admin Columns Pro on the filtering side and WP Media Folder on the media management side:

https://www.admincolumns.com/what-is-admin-columns/

Admin Columns Pro is just pure magic for clients. Being able to edit-in-place on the post/page list, add images from the grid, batch commands from the grid - this plugin alone does so much for wordpress it's a no-brainer first install. But the filtering columns at the top of the list that conform to custom posts and pages (like if you are using ACF or Pods) is really intuitive and awesome AJAX. Like I said, clients love how much it streamlines their work.

I personally have gotten used to listers, but the experience of listers on Processwire is a lot more like NSP Code's advanced ordering WP plugin where you are able to filter and sort hierarchical lists and then create set list pages for them:

https://www.nsp-code.com/premium-plugins/

This sort of thing is fine for developers to put together special lists - and I actually use lister pro to provide clients with worklists that detect content that is incomplete (missing author, card image, unpublished, too short, etc.) but as other have mentioned, the lister interface for some reason is hard to grasp. I always had the same problem trying to train people on using Advanced Post Types Order.

https://www.joomunited.com/wordpress-products/wp-media-folder

I tried a bunch of media managers for wordpress and this is the one that folks seemed to like the best, and I like that it produces its own metalayer without disturbing the file system away - so if for some reason they uninstall it everything revert to the big perpetual stew that is WP media.

Not saying that you need to duplicate anything here, but I saw others posting about things that clients have liked from a UX perspective and so here ya go!

[kongondo]

Hey @gornycreative,

Great write-up, insights and suggestions!

4 hours ago, gornycreative said:

Not saying that you need to duplicate anything here, but I saw others posting about things that clients have liked from a UX perspective and so here ya go!

This is very inspirational! It is going to be very helpful, thanks!

[kongondo]

Hi all,

I wanted to update you on the progress of the next MM as discussed from this post onwards. Here's a very short preview of the next MM.

It is still very early days. Nothing is polished and things may change. My main focus is on the functionality although I spent a bit of time on the GUI. I have spent considerable time thinking about the conceptual design, especially for the API and I am quite pleased with that so far. 

Before you ask, I don't know when this will be ready. It is not a small re-write. I do know that it won't be until after the summer though, that's for sure. Happy to get early feedback, thanks.

 

 

[froot]

how does that work? Each image still lives on a page object, right? What are the folders technically speaking? Will it be possible to move existing images into folders without destroying the image path?

[kongondo]

1 hour ago, fruid said:

how does that work?

Like ProcessWire page reference fields.

1 hour ago, fruid said:

Each image still lives on a page object, right?

Yes. Media pages are not nested. They reference 'categories' (folders) which themselves can be nested.

1 hour ago, fruid said:

What are the folders technically speaking?

To the user, they look like 'folders' in everyday computing (sort of). Conceptually, they are virtual folders. Technically, they are like page reference fields. This means that a media item can belong to more than one category. This is achieved simply by it referencing multiple 'category pages' (like page reference fields). So, technically, we don't nest media items. Instead, we nest the categories and the media items follow that, virtually.

Categories are nestable pages. For instance, in the demo, People is a top level category (folder) page. It has two (ProcessWire) page children, Men and Women. If we wanted to, we could further sub-divide this, e.g. Men > Sports Men > Martial Arts > Etc... These are all 'category' pages. It is not shown in the video but from the screenshot below, you can see the category 'Fruits' is deeply nested.

Deep Nesting

Back to the demo, for example, the images (media items) you see when viewing 'Men' have the category 'Men'. 

1 hour ago, fruid said:

Will it be possible to move existing images into folders without destroying the image path?

Definitely. This is because as explained above, we don't nest the media items themselves. Their paths are fixed. For instance, to move some media from the category 'Berries' into 'Apples', behind the scenes, we will just change its category (reference) to 'Apples' (or 'Green', to be more specific). The media itself doesn't move. I am still working on the 'move' from the UX point of view but it will most likely be via both drag and drop and using menu (context) options.

[David Karich]

5 hours ago, kongondo said:

Hi all,

I wanted to update you on the progress of the next MM as discussed from this post onwards. Here's a very short preview of the next MM.

It is still very early days. Nothing is polished and things may change. My main focus is on the functionality although I spent a bit of time on the GUI. I have spent considerable time thinking about the conceptual design, especially for the API and I am quite pleased with that so far. 

Before you ask, I don't know when this will be ready. It is not a small re-write. I do know that it won't be until after the summer though, that's for sure. Happy to get early feedback, thanks.

 

 

Wow. Looks absolutely incredible. ? Really gives you a feel of an asset library. Great work. Looks intuitive too. Can't wait to test it out. ?

Two questions: how should uploads happen? Can I just upload assets via DND in a folder or is the "New" button meant for uploads? If so, I would give it a different name, e.g. "Upload Media".

Second question: does the search always refer to the entire library or only to the currently selected folder? Can I change the search behaviour in an advanced mode?