PW 3.0.17: Major upgrades to images field

[ryan]

Thanks to Renobird and LostKobrakai, ProcessWire’s images field has been re-designed and redeveloped with a lot of great new features we think you’ll love! This new images field is available for use now in ProcessWire 3.0.17. The linked blog post covers it in detail. There’s also a screencast at the end that shows you the new images field in action. 

https://processwire.com/blog/posts/major-images-field-upgrade/

[Jugibur]

Looks very well plus great functionally additions – thanks to all involved people for your work!

PS: What are you think about renaming an file in the backend (i.e. for SEO adaptions)? This is the only thing I've sometimes missed.

[szabesz]

Thanks for everyone being involved!

I have one issue though, see image:

This is a transparent png, a completely white logo that used to be visible, thanks to ProcessWire properly dealing with the issue (before the upgrade). Now we cannot see it anymore, also the new layout and the new buttons are useless in this usecase.

The logo is horizontal (a lot wider than its height) and now I might want to set its Column Width a lot wider so that the image is not rendered in such a tiny size. However, I cannot see the image anyway, so for the time being this width might do...

BTW: I will never want to crop the image (being a site logo, it is already resized to my liking), it will always have only one variation, so these buttons can clearly be useless, just take up precious space. Also, what if I do not want clients to fiddle with crop?

It would be nice to have options to turn these button on/off. Say, on the Input tab where Column Width can be set among other options.

I'm also missing a list view. Actually, for basic needs, the old way of doing things worked better. Now we have a lot of bells and whistles, but some basics needs are not fulfilled anymore. I hope this will improve in the future.

Thanks anyway!

EDIT: please read teppo's comment below, too. He did a great job of further clarifying what I meant.

Edited May 7, 2016 by szabesz

[apeisa]

I'm also missing a list view. Actually, for basic needs, the old way of doing things worked better. Now we have a lot of bells and whistles, but some basics needs are not fulfilled anymore. I hope this will improve in the future.

Can you describe in more detail what worked better in old UI? I agree that there should be some nice tiled background for transparent images, but is there some other basic needs that are missing?

I personally think that this is one of the "wow, that looks easy" moments for customers. Even more than before. Image fields used to take a lot of space in list view and old grid was lacking in features. Great work Tom, Benjamin and Ryan! It is also great to see more and more community effort in ProcessWire core dev!

[teppo]

Can you describe in more detail what worked better in old UI? I agree that there should be some nice tiled background for transparent images, but is there some other basic needs that are missing?

I personally think that this is one of the "wow, that looks easy" moments for customers. Even more than before. Image fields used to take a lot of space in list view and old grid was lacking in features. Great work Tom, Benjamin and Ryan! It is also great to see more and more community effort in ProcessWire core dev!

I don't really see what we're missing feature-wise here either, but that being said, I do have to admit that originally I was under the impression that this was going to be a replacement for the old grid view (which never made much sense to me, especially considering how it lacked so many features), not both the grid and the list view. The thing is that I too would prefer list view in some cases: especially when the images are intended to be displayed on the front-end as a list, it would make sense that they're displayed as a list in the back-end too 

The screenshot above displays two obvious use cases that could be handled better:

• backgrounds for transparent images (use a grid, not solid colour, just like we did for the old image field) and
• narrow fields (instead of trying to cram everything side-by-side, in some cases it would make sense to have the image on the top and other elements below it).

Additionally this UI doesn't make as much sense for the single-image use cases as it does for galleries and such. In my opinion it would be good to have the option of disabling the buttons on a field-by-field basis. Additionally it feels a bit awkward that even though there's only one image, one still has to click to see the edit fields; though this might be a question of preference, it's also one of the cases where the old list view made more sense to me.

That being said, this is a great update, so big thanks to everyone involved. I'm sure we can iron out the glitches and improve the usability of the field in some situations now that the new field is in the core. It's typical that some additional requirements only arise after a feature is in wider use

[szabesz]

Thanks teppo! You saved me a lot of typing by clarifying what I meant

[horst]

In addition to @teppo and @szabesz, there are more usecases what are currently seems not to be covered well. I must admit that I first also have thought that we need the list view too. But now, after playing around a few times in the last two or three weeks (with an unofficial beta, thanks to @Lostkobrakai) I'm not even torn. I have learned to live without the listview.

Usecases that are not well covered atm, for example are image rows with 20 motives that all look the same, where you need the filename, and I mean the filename of all files at once. What I come up and tested (in context of the croppableimages extension) for this are two things:

• one can toggle visibility of filenames over the thumbs
• using a little textbox for filtering by filename

This is even faster than looking through an endless list of filenames.

Another usecase sometimes may be to directly see the aspect ratios of all images at once, not a nice looking centered cropped square.

But you will not get that WOW-effect with a visually cluttered grid, also covered with filenames all over. So IMO it depends on the usecases and the user preferences:

As you also can see in the second screen, media queries are respected. This isn't what I have done, this is already in the new core imagesfield! (@szabesz: there must be a glitch somehow with your device / version)

I simply have extended the new core image field and was able to use comfortable supported hooks from the core field. Here seems to be all usecases already covered on the developers side!

Conclusion: with every newly introduced thing, first part is a confrontation with no more able to behave the same as before (we, the users / developers) (sorry for maybe long and bad describing words, but I think you get it) Phase two should be to find some time, play around and try out that new thing, and if you find a usecase that isn't covered well now, don't simply say we need to implement the old way here for that. I personally think I'm oldschooled in many things and also not a friend of often changing things, but I'm so happy that I have had the chance to get my hands that early to the new imagesfield and in addition also found the time to play around with it! As one result, now I have improved my own behave / workflow in some usecases and are also able to give my clients a very well looking edit page, so that they can see and say: WOW!

EDIT: and sorry if it looks that I shamelessly promote the croppable extension here. The new core imagesfield from @Renobird and @Lostkobrakai allone is responsible for all the ongoing new things. I wouldn't have done anything without it and also simply wouldn't be able to do things like I now could do. This all depends on the core imagefield. Most things what I have done to adapt the croppablefield with it, was to strip out great parts from the PW2 version so that all the design and magical stuff is delegated / handled from the core imagefield.

Edited May 7, 2016 by horst

[szabesz]

I must admit that I first also have thought that we need the list view too. But now, after playing around a few times in the last two or three weeks (with an unofficial beta, thanks to @Lostkobrakai) I'm not even torn. I have learned to live without the listview.

The old list view is not that useful anymore, but seeing the list view of the Variations, now that is what (or something similar to it) would be useful. That way we could see the complete filename, for example. Some Ajax driven editing features would be quit useful too.

As you also can see in the second screen, media queries are respected. This isn't what I have done, this is already in the new core imagesfield! (@szabesz: there must be a glitch somehow with your device / version)

This is not a media query issue, the "box" is narrow on a wide viewport, because I adjusted its Column Width setting (30%).

Do not get me wrong, I realize that these new features are big improvements, it just feels a bit 1.0

[titanium]

Very nice enhancement! One thing though: if the image has much more height than width size (imagine a skyscraper), then it takes too much place, which is annoying. Is the maximum displayable height configurable somehow?

[adrian]

I really love the enhancements you show horst - showing the names and filtering will be very helpful.

PS: What are you think about renaming an file in the backend (i.e. for SEO adaptions)? This is the only thing I've sometimes missed.

This can be done automatically via CustomUploadNames (http://modules.processwire.com/modules/process-custom-upload-names/), but I would also like to the option for manual renaming in the core.

[Tom.]

In addition to @teppo and @szabesz, there are more usecases what are currently seems not to be covered well. I must admit that I first also have thought that we need the list view too. But now, after playing around a few times in the last two or three weeks (with an unofficial beta, thanks to @Lostkobrakai) I'm not even torn. I have learned to live without the listview.

Usecases that are not well covered atm, for example are image rows with 20 motives that all look the same, where you need the filename, and I mean the filename of all files at once. What I come up and tested (in context of the croppableimages extension) for this are two things:

• one can toggle visibility of filenames over the thumbs
• using a little textbox for filtering by filename

This is even faster than looking through an endless list of filenames.

new-imagefield-and-extensions-01.gif

Another usecase sometimes may be to directly see the aspect ratios of all images at once, not a nice looking centered cropped square.

But you will not get that WOW-effect with a visually cluttered grid, also covered with filenames all over. So IMO it depends on the usecases and the user preferences:

new-imagefield-and-extensions-02.gif

As you also can see in the second screen, media queries are respected. This isn't what I have done, this is already in the new core imagesfield! (@szabesz: there must be a glitch somehow with your device / version)

I simply have extended the new core image field and was able to use comfortable supported hooks from the core field. Here seems to be all usecases already covered on the developers side!

Conclusion: with every newly introduced thing, first part is a confrontation with no more able to behave the same as before (we, the users / developers) (sorry for maybe long and bad describing words, but I think you get it) Phase two should be to find some time, play around and try out that new thing, and if you find a usecase that isn't covered well now, don't simply say we need to implement the old way here for that. I personally think I'm oldschooled in many things and also not a friend of often changing things, but I'm so happy that I have had the chance to get my hands that early to the new imagesfield and in addition also found the time to play around with it! As one result, now I have improved my own behave / workflow in some usecases and are also able to give my clients a very well looking edit page, so that they can see and say: WOW!

EDIT: and sorry if it looks that I shamelessly promote the croppable extension here. The new core imagesfield from @Renobird and @Lostkobrakai allone is responsible for all the ongoing new things. I wouldn't have done anything without it and also simply wouldn't be able to do things like I now could do. This all depends on the core imagefield. Most things what I have done to adapt the croppablefield with it, was to strip out great parts from the PW2 version so that all the design and magical stuff is delegated / handled from the core imagefield.

Really really glad you've updated Croppablefield! I have really wanted to use it in the past but had issues with 3.0, I assumed you was no longer support the project as it had been dropped a few times in the past. Keep up the great work! I'm going to use this in the future

Great work to everyone involved with the new image field update! It looks amazing  

[Robin S]

Just installed PW3 so I could get a closer look at the new images field. The appearance and interactions are both really slick.

Some feedback:

• I think having the option to get an overview of which images in the field are landscape vs portrait, which have descriptions and which have tags is very important. The aspect ratio thing could perhaps be solved with a toggle between fit and fill for thumbnails. But for the description and tags I think we need to be able to toggle to something like the old list view. Not being able to see these things across all images would be a real annoyance in some situations.
• I think there needs to be a max-height set for images in the enlarged view. As @titanium pointed out, some images could be very tall and narrow and at some point the enlarged view will get excessively tall. Perhaps the enlarged image area should be defined as a 1:1 ratio and the image scales to fit.

[Macrura]

Echoing some other sentiments here, I definitely would need the ability to toggle to some view where one can see descriptions and/or tags on the main view.

In other words, it will be essential for quite a few of my existing sites to be able to see at once the tags on each image without clicking edit on each one...

[tpr]

I just installed the latest dev to see the images field changes. Some thoughts:

• instant previews are great
  
• d&d image replacement is useful
  
• when there's only one image added and entering edit mode, opening the lightbox and clicking on the image in the lightbox closes the lightbox but also closes the edit mode. This feels like a glitch. Clicking on "close" or on the overlay works fine though. 
  

Also, it would be nice to see these some time:

• viewing the file name somehow (as requested above)
  
• renaming a file for SEO purposes (as requested above)
  
• deleting all variations for an image, or maybe for all on the page. The "Variations" button could be modified to have a dropdown like the new Save buttons.
  
• the button "Crop" have other actions in the lightbox, so this could be perhaps renamed as "Edit". This would be a more appropriate naming even when adding new edit functions to the lightbox.
  

Thanks for everyone involved, this could be a hard work with no doubt. We shouldn't expect everything working perfectly on the first iteration but it's a great start to build upon.

[AndZyk]

First of all thanks to Renobird and LostKobrakai for the image field upgrades. I hadn't time yet to fully try them out, but after reading the blog post I am sure, that they are a huge improvement. Especially the drag and drop function in the old image field was a little bit tedious, when sorting images. Also I know, that huge improvements like this always come with some unexpected behavior. 

Some of those I noticed today in my current project:

I have a Repeater Matrix called content and inside this Repeater Matrix I have a repeatable item called slideshow. This repeatable item has only one regular image field called slides. Using the latest ProcessWire 3.0.17 release and its additions to the image field I notice two bugs in the UI:

1. Popover gets cut off

2. Mix-up in detail view

When I switch the detail view of the images, there is always one detail view displaying two images and one of them has no details at all.

Has anyone else noticed this? By the way, I am using the latest version of Chrome and couldn't see any errors inside the console.

Regards, Andreas

[Peter Knight]

I think the new Images field is really nice. Beautifully designed and miles ahead of the old images field.

I have to admit though. I really miss a list view. I'm not saying I miss the old list view but I think a list view is needed.

Right now I'm working on several galleries of images with many similar images (cropped and non cropped)

It's not practical with several images to hunt around via tool-tip for the image information. With a list view, I can see what I want instantly.

[Peter Knight]

I seem to have a bug with the new images field and 3.0.17

When I click the trash icon on a thumbnail, there's no effect. Previously I'd have a red line around the image border which signifies the image would be deleted on save.

Also when I hover over a thumbnail and click 'edit', nothing happens.

The only thing I'd done in the past few hours was to install the new V3 Croppable image but I don't think it's related to this.

[SteveB]

I was hoping for something more like Lister (rows, columns, sorting) but with thumbnails. It just seems like information is being obscured in order to have a more front-end kind of design.

Casting my vote for...

A way to see all the image filenames clearly, not truncated and supered over an image.

A way to see how they are tagged & described without having to drill into each one.

Thumbnails with same aspect ratio as the original image (cropped to square is the visual equivalent of all caps)

[szabesz]

I was hoping for something more like Lister (rows, columns, sorting) but with thumbnails. It just seems like information is being obscured in order to have a more front-end kind of design.

That is why I was pointing to the new Variations list as a starting point, which already has thumbnails and some basic info we need. Sure, it would need additional features others have already described above, but just one more: the columns visible might be customizable, so we can fine tune the list to our needs. True, the possibilities are endless, and we should figure out what tools are really missing in the current state. After all, system design precedes implementation

[Peter Knight]

 the columns visible might be customizable, so we can fine tune the list to our needs. 

Was thinking that too. 

[tpr]

This is probably an overkill, but it would be nice if drag-and-drop an image from an image field to CKEditor could work, even if showing a popup first.

[Bill C]

Even though I really don't know Renobird or LostKobrakai I would still like to extend a word of thanks for their hard work and the time they put in to make things happen and get stuff done. Congratulations on the roll out. Nicely done.

[AndZyk]

I have a Repeater Matrix called content and inside this Repeater Matrix I have a repeatable item called slideshow. This repeatable item has only one regular image field called slides. Using the latest ProcessWire 3.0.17 release and its additions to the image field I notice two bugs in the UI:

1. Popover gets cut off

Popover.png

2. Mix-up in detail view

Detail 1.png

Detail 2.png

When I switch the detail view of the images, there is always one detail view displaying two images and one of them has no details at all.

This evening I had some time to investigate the UI glitches I mentioned earlier this week and found some solutions.

1. Popover gets cut off

The popover gets cut off because of the Ajax loading of the Repeater Matrix items. The items have the overflow set to hidden as an inline style, even when opened. I can avoid this by not loading the items through Ajax, although it would be nice if this could be fixed, because I think setting the overflow of the item to hidden is not necessary, once it is opened.

2. Mix-up in detail view

The mix-up in the detail view happened, because in my template I have one image field for a thumbnail and the Repeater Matrix with the slides item mentioned above. Right now I have many pages where the thumbnail field and slides item contain an image with an identical file name. If I try to toggle the detail view of one of those two images with the identical file name, the detail view gets confused and shows details to only of those two images instead separate. I can avoid this mix-up by using different file names, something I should have done in the first place, but just wanted to let you now.

I hope I have explained this well enough. 

Regards, Andreas

[jrtderonde]

Will it be able to have an option (when cropping) to contain a certain aspect ratio, or "is the technology not there yet"?

[videokid]

On 5/19/2016 at 3:31 PM, jrtderonde said:

Will it be able to have an option (when cropping) to contain a certain aspect ratio, or "is the technology not there yet"?

This would be a nice feature indeed, and would make some modules [e.g. CroppableImage] obsolete...