Image field UI and general tidy up

[Peter Knight]

Hi guys,

Been "kicking the tyres" on some UI tweaks to the PW image fields and modal windows. Many of these are in-progress designs and to be straight, none of the designs are entirely resolved. 

At this stage, I thought I'd throw them up (poor choice of words!) and maybe someone can take them further or offer some fresh eyes.

I'm not a developer so making these a reality is impossible for me. They're flat designs.

Why?

PW is an amazing experience for editors. It's just so elegant and beautifully realised (especially with Reno Theme) that often, my training sessions with clients are very brief. One area which does cause friction though has always been concerned images, image fields and image modals. Especially with the latest image modules, I think a lot of inconsistency has crept into the UI. 

Hopefully these designs can help improve things a bit. A tiny part of the design work is influenced by a similar idea I had for MODX but which never progressed.

1A. Current Image Modal

Editor has clicked 'Add image' icon in CK editor.

Issues:

• I believe the Upload Image button can be better placed. 
• It's not clear to users that they have a choice of two actions (Select an Image OR Upload one)

To help solve this, I thought we could:

• Place available images under a Choose tab
• Create another tab titled Upload
• Rename modal to just Image (from Select Image)
• tweak slightly the Images on page path to be less prominent

The following image illustrates the result.

Clicking the Upload tab would result in:

In the above image I've created toggle-able accordians for Drag and Drop and Manual upload.

This follows closely the UI an editor is presented with when choosing Insert Link within CK Editor. IE Link to URL, Select Page and Select File and the extra Attributes tab. So overall, it's more consistent.

1B. Alternative to above - combined Select and Drag/Drop

I thought it might be worth exploring what modal would look like with no tabs and a single UI for both Selecting an image and Drag/Dropping.

1C. The Image field

I then moved onto looking at the Image field in PW.

So currently it looks like this (below) for a simple image field called Image Gallery.

So although the current Image field works great, I wondered if there was a way to simplify it by

• Making the drag/drop more visual and obvious
• Moving the Choose Files button and removing the No file chosen text and the file types allowed

Here's the result. Admittedly, this treatment adds more height to the overall field.

Here's how it looks when images are uploading (slightly smaller plus icon and "drag and drop..." text.

To be honest, I can't recall what other changes I made there!

And here's a proposed layout for when there are multiple images. This includes

• image titles
• grid layout
• mouse-over for edit and delete options/buttons

2. Cropping

Next thing I looked at was cropping. Native cropping introduced recently is one of my clients favourite features and time-savers and I wondered if things could be improved a little. 

So heres the current layout (this may have changed further recently)

And here's my proposal.

Changes are:

• Width, height and X and Y fields are moved below the image
• Apply and Cancel placed bottom right of the image
• Save Crop should be titled Apply. I think that's less confusing as in some instances there are so many Save options
• Save and Replace should be greyed out further

In addition to this, I thought it'd be neat if we had the free-form cropping function introduced by Ryan combined with some kind of list of pre-sets (displayed on right hand side).

Forgive the croptions label (Crop + Options pun - I was tired!)

The benfit of this I think is that Modules such as CoppableImage and native Crop would be unified in a single UI.

Presets (on right) could be a few out-of-the-box presets which come natively.

Croptions houses any crop ratios defined in image modules. if CopppableImage isn't installed, they just don't display..

That's it. I wish I'd more time to work on this but it's at the stage where it's ready for some initial thoughts. Hope you guys like.

[renobird]

I just dropped in for a quick minute, but wow!

I'll look closer at these later tonight when I have time.

[LostKobrakai]

This looks very nice. I really like consistent UI / UX and the image field did always lack by the tiny bits. My greatest bugbear was always the dropzones. E.g. if I not hit the input exactly it'll load the file as local resource and all changes to my page are gone. Also I've hesitated to use croppable image in the last months just because I really don't like the fact, that it needs to replace the whole UI, instead of gracefully building on it. Therefore I really like your proposed changes to the cropping interface. 

As you've asked for other opinions I've some thought for you:

1A Having tabs resolves the issue of showing the user his options, but I know it from myself, that it would bug me really soon (if I would use RTE's more often). If I want to add an image I click the image button in the ckeditor toolbar. While the modal opens I switch to Finder, drag my file to the browser and sadly notice, that the droparea is behind the tab. Then I'd try to not drop my image anywhere, where I would open it in the browser or to any wrong folder or the desktop. Change to the upload tab. Repeat first steps. Not very nice.

1B Your alternative would solve my issue with 1A, but it looks really imbalanced from a visual standpoint. Unlike all your other images this looks like a really rough mockup. Maybe a vertical layout would work better than side by side, but not necessarily.

1C Grids are nice to get an overview, but they lack to highlight the most important thing an editor need to be reminded of: descriptions. It also lacks tags, but I'm really not using those. But back to descriptions. I don't know about you guys, but I always use them for alt tags and these should really be filled if one cares for seo. I'm still not sure how this could be solved better, but I really think that only-image grids aren't the obvious way to go. 

2 As said before I really like the cropping option on the side and the more tidy placement of all things. The only thing I have to critic about it are the buttons. There are two cancel buttons and the "Apply" button fails to communicate what it does. "Save and Replace" like the bigger button below? I also think the "replace" part should not be part of an button, but part of your options. The "Save" button should only have a single type of action – saving the crop with the current settings – while I may decide while cropping, that I don't want to replace the current crop, but save a new one.

[Peter Knight]

Thanks for the feedback. LostKobrakai. I agree with pretty much all your comments. 

Regarding 1B (combined Select and Drag/Drop) I've struggled to achieve a balance here and you've picked up on that. After several different layouts I eventually settled on that one but I'm convinced a better layout can be realised. 

Regarding 1C (grid images), this assumes you've set Grid as the Default view in the Image field > Input tab.

2 (Cropping). Agree on the 2 Cancel buttons. Perhaps the first one should be Reset instead?

[Peter Knight]

Speaking of images, here's some feedback from a client training session. Again, Images being the only area that confused my client.

Process of steps.Everything good until after step 4

1. Click Insert Image in CK editor
2. Click Upload Image
3. Select a file from your computer
4. Hit Save once the image is uploaded

At this point, its  unclear what the required step is. 

"I can see my grid of uploaded images but no indication that I still have to select one. It's made a little less obvious by the two Upload Image buttons too."

and...

"When I do select my image, I am presented with the cropping UI and more options (Insert this image, Select another image, Cancel) and I'm not sure what to do next".

[adrian]

Hey Peter - these are awesome!

I posted a link to this thread on Github as a comment to an issue I brought up about this confusion I have seen:

https://github.com/ryancramerdesign/ProcessWire/issues/968

I especially love the Choose and Upload tabs.

[Nico Knoll]

Really love this! I hope ryan and tom can make that happen (Or maybe you can just send a pull request )

[Peter Knight]

Really love this! I hope ryan and tom can make that happen (Or maybe you can just send a pull request )

Cheers Nico. Just graphics at the moment. I've some refinements on the way.

[ryan]

Thanks for taking the time to explore this stuff Peter. I like what you've done, particularly the tabs in the modal, for consistency with the Link dialog. I prefer icon/text of your drop zone to the one we've got now. Though I'd want the drop zone to be consistent whether in the editor or in the modal. There's also the consideration of what image field you'll be uploading to. If you've got multiple image fields on the page, you are going to have multiple fields to which you can upload to, so a single large dedicated drop zone in the modal would not work. However, I think taking your drop zone that appears in the page editor, and using the same exact thing in the modal would do a nice job of having an improved drop zone, while still allowing for the possibility that there may be multiple drop targets. 

I like what you've got going on the Image Gallery screenshot in grid mode, but it does blur the line between list mode and grid mode. Not saying that's undesirable, but that it's different from what was intended: for grid mode is to be the opposite of list mode, and keep it as minimal as possible with basically nothing but the images themselves. Whereas list mode is meant to spill all the beans. Behind the scenes, these two modes use the same markup as a matter of efficiency, just styled differently. So there are some limitations in that respect (they have to use the same thumbnails and such). 

When it comes to any image operation in a modal, the buttons are placed at the top because we don't want them to fall into a scrollable area that's hidden. An important function of the image editor is to allow for the option of working with the image at its actual dimension rather than scaled, which in many cases means part of the image may need to be in a scrollable region. After all, we have no way of knowing what the size of the modal will be as it depends on the client side. If we adopt a standard of having any buttons/inputs, etc. below the image, then in many cases they simply won't be visible. That's why the choice was made to keep those buttons/inputs at the top. However the buttons that affect the modal window itself (like closing it) are able to go outside the modal document and into the window footer. 

I prefer your use of defined labels for "width", "height", etc., rather than the current arrow icons. I was trying to save the translators some work there, but after using it awhile agree that text labels are better. 

As for cropping presets, I agree about the usefulness. But I also really didn't want to cancel the purpose of Horst & Apeisa's crop modules, which they've put a lot of work into and already do a great job of this, better than I could do. Maybe someday we can get those preset functions integrated into the core image editor with their help. But the current intention with the image editor is leave that need to dedicated modules, while accommodating the more basic general purpose cropping needs, especially for things like RTE inserted images where a preset isn't necessarily what you want. But if there's sufficient demand for "croptions" (love the label), maybe we can talk Horst and Apeisa into helping us get those in a future PW version. 

I'm conflicted on the Apply vs. Save Crop labeling. My eyes prefer Apply as you've got it, but that button is actually saving a crop rather than applying the crop to an existing image. I like to leave the option of letting the user determine whether the crop should replace the original, or whether it should become a new image. To me, the term Apply implies replacing the original, though maybe since we give them that choice separately, it's okay to use it here. I'll take it for a test drive.

[Peter Knight]

Thanks for taking the time to explore this stuff Peter. 

Thanks for the feedback Ryan. Lots of stuff raised that I hadn't thought of.

As for cropping presets, I agree about the usefulness. But I also really didn't want to cancel the purpose of Horst & Apeisa's crop modules, which they've put a lot of work into and already do a great job of this, better than I could do. 

I was thinking that there was some kind of integration actually. IE If CroppableImage was installed and you had certain Crop-tions set, the Croptions part of the UI would display. If you don't have CroppableImage installed then you don't see 'em. That way I also imagined that future image Modules could selectively plug in to the modal.

Then, the more basic 1:1 3:2 and 4:3 were just pre-defined, standard and non CroppableImage out-of-the-box ratios.

Anyway, really good to hear from you as I realise there's a ton of complexity and considerations underlying some simple mockups.

[adrian]

I was thinking that there was some kind of integration actually. IE If CroppableImage was installed and you had certain Crop-tions set, the Croptions part of the UI would display. If you don't have CroppableImage installed then you don't see 'em. That way I also imagined that future image Modules could selectively plug in to the modal.

I would love to see this   

As much I like the existing crop modules, I honestly don't like the inconsistencies in the UI/UX between the new core cropping and the 3rd party ones, but I really want predefined cropping.

[Peter Knight]

As much I like the existing crop modules, I honestly don't like the inconsistencies in the UI/UX between the new core cropping and the 3rd party ones, but I really want predefined cropping.

My greatest bugbear was always the dropzones. E.g. if I not hit the input exactly it'll load the file as local resource and all changes to my page are gone. Also I've hesitated to use croppable image in the last months just because I really don't like the fact, that it needs to replace the whole UI, instead of gracefully building on it. 

Guys - I feel the same. PW has largely such a consistently brilliant interface that anything even slightly off is amplified. At the same time, the image crop modules are essential.

If any core-contributors or module-makers want to team up and move this along, please shout.

[adrian]

I'm conflicted on the Apply vs. Save Crop labeling. My eyes prefer Apply as you've got it, but that button is actually saving a crop rather than applying the crop to an existing image. I like to leave the option of letting the user determine whether the crop should replace the original, or whether it should become a new image. To me, the term Apply implies replacing the original, though maybe since we give them that choice separately, it's okay to use it here. I'll take it for a test drive.

Ryan - I agree with Peter here. I find that Save label confusing, because by itself it doesn't make any changes to what the user sees in the admin if they then choose to "Cancel" rather than "Save as Copy" or "Save and Replace".  I understand that the crop is saved to the page's assets/file folder, but it really becomes an orphan if "Cancel" is clicked - right?

As for the "Save As Copy" and "Save and Replace" buttons, I really think the developer needs to be able to control which of these is available. There are many times when "Save As Copy" can really mess with template code loops to output images in carousel or thumbnail gallery.

Thanks! 

[Can]

Nice thread and nice design ideas Peter!

I would like to add a thought of mine to this.

At least for me it would be awesome to have the cke image modal more like the link modal.

In the link modal you can just choose "child page" that would be awesome for the image modal too.

I have often images from child pages I wanna use..

And maybe a searchfield to find pages similar to link modal

Edit: another one: when I remember right (can check later) there are 3 different positionspositions/designs for the current progress. I think:

"Loading.." in the image modals title

"Saving" in a green button

And one more I don't exaczly know maybe it was the replaced save button?

This is a little confusing, I'm always expecting it at the wrong place thinking nothing happened until I find the right one ^^

Good night

[bernhard]

In addition to this, I thought it'd be neat if we had the free-form cropping function introduced by Ryan combined with some kind of list of pre-sets (displayed on right hand side).

+1 for at least more integrated cropping. i agree that apeisa and horst did an awesome job on their modules but i don't think that should be a reason to not build this functionality into the core. i use those modules in every project and i really think that's a very common and core-worthy thing.

thank you peter for your work on the mockups

[Peter Knight]

This post has had an inexplicable surge of Likes over the past few weeks so there seems to be quite a bit of interest in this 7 months later.
I've been unable to follow these concepts up with the time they deserve but those interested in an mage field tidy up can see Toms own beautiful work mentioned on the Dec 18 blog post.
Furthermore, Ryan mentioned in today's Roadmap blog post that these (Tom's) designs are already being worked on by LostKobrakai.

Exciting stuff!