ryancramerdesign / ProcessWire

Our repository has moved to https://github.com/processwire – please head there for the latest version.
https://processwire.com
Other
727 stars 199 forks source link

New crop/resizing tools UI confusion #968

Open adrianbj opened 9 years ago

adrianbj commented 9 years ago

Minor I know, but I think these things are a little confusing:

  1. There is already a resize handle at the bottom right of the image - why would I click the dedicated resize icon (which btw looks like a move icon to me). I also don't understand why this button results in 8 different handles - I can still only resize proportionally, and I wouldn't want to squish it anyway.
  2. I don't get the Minimize/Fit to Screen button - where is it getting the dimensions from that it chooses to resize to?
  3. After resizing, if I click on the "No, use AxB radio button, I would expect to see it dynamically resize back to the original size, but it doesn't.
ryancramerdesign commented 9 years ago
  1. I've had more than two instances where my own clients didn't understand the resize handle concept or couldn't see it. The description text I added a long time ago helped somewhat, but not entirely. Plus, I'd rather have an actual action than a line of text. The button is to make it super obvious to those that need super obvious.
  2. Minimize fits to screen on first click (if not already there), and down proportionally from there on subsequent clicks. Maximize maxes the image to the full/original size.
  3. This refers to the file that is saved only. See the text that precedes the radio button. Lets say you uploaded a photo right off a camera at 6000 pixels wide. When you open it up in the edit window, it's going to scale it so that you can see the whole thing without having to scroll all over the place. If it didn't have that radio button, and you clicked one of the "save" buttons, it would take your 6000px image and reduce it down to 500px or whatever your window dictated. There's a good chance that's not what you wanted. So those radio buttons let you tell it what you intend and avoid unintended consequences of viewing an image on a screen that's not large enough to contain it. Once you perform an actual resize by dragging the size of it, then it adjusts that radio button to suggest that you really do intend to change the size of it when saving.
adrianbj commented 9 years ago
  1. I guess I think having multiple ways to do the same thing can be more confusing, and I still think the 4 arrows in the middle of the image edges are confusing - in most software these would result in stretch/squish if there wasn't something else to determine whether the changes should be proportional (maintain aspect ratio).
  2. I never thought to click the minimize button more than once - "minimize" sounds very final and discrete to me. What about "reduce" or something else ?
  3. Thanks for the explanation - makes a little more sense. I haven't been testing with large enough images to invoke the initial automatic sizing to fit to screen, so maybe that explains some of my confusion. However I tend to think that once you manually resize the image, it should be a sign that that is the size you want to save it at, which is why you have the "Yes" radio selected - perfect. I guess I thought it would make more sense that clicking back on the other radio would expand it back to either fullsize, or at least fit to screen since it is effectively undoing the need for manually resizing to less than fit to screen? Maybe not an issue.
somatonic commented 9 years ago

I was also confused a LOT by the how this new thing works. I can imagine others having even more problems what this all does. I already see a lot of phones/support questions by clients :)

To go the "consistency" route the "action" icons should be like page actions text only or icons with labels. Maybe not and all is ok.

I didn't get the resizing "minimize" and then have to click a radio box on top to get it saved with this size. "Save at this size? O Yes O No, use 1478x658" I think it's in a place I don't expect. It should be rather where I save the image. That's the next issue with this UI, there seems two placed where to "save". Although the bottom buttons are now grayed out when I select a tool.

A usability challenge is also the fact it "resizes" the image automatic to fit in view, there a lot of confusion coming from this alone. I test with large images clients usually have. Then the reason fro this tool might be to recut or resize a image. We have the real size in the file name on top with size (1000x1000) and then the inputs that show another size. People will struggle with this as they don't see this or understand enough. Then I want to resize that image cause it's big and don't know exactly what to do. Since the image seems already scaled down I hit save and since I didn't see the top radio boxes asking something in the wrong place I miss it and end with the same image. But then I open it and it's in the size it was before, but I don't know it's not rescaled.

Overall great works as always, just not as intuitive.

We need a image rotate tool. In case rotated images are uploaded.

This would lead to. Would it be possible to make this edit modal modular in a way it can be extended or plugged in like a RTE for example. Since jQuery UI is in core we should make use of the great js widget system it has for free. We can also use it for other parts of the admin. This would make a standard interface/way of doing stronger integrated pluggable widgets. Other thing would be Page field inputs, like ASM. It would allow for much greate and easier extendability of those parts that currently aren't or are a hassle.

somatonic commented 9 years ago

jQuery's UI Widgets also would allow "Widget.create Widget.destroy" etc and events/hooks that can be attached to them.

http://jqueryui.com/widget/ Example for a custom widget.

We already use them so why not make it a standard for all js stuff like Inputfields etc too?

apeisa commented 9 years ago

Soma, standardizing the JS side of things would be great - probably too much for 2.* branch (not sure though), but definitely something that should be given good thought on 3.0.

Do you have more concrete examples? Do you mean the whole image editor could have been build using jQuery UI Widget (without modal) or the editor inside modal could have been Widget?

owzim commented 9 years ago

I just thought about the JS standardization and a proper API the other day too. This definitely should be taken care of better sooner than later.

adrianbj commented 9 years ago

One more point to this - clients aren't always seeing the "Save as Copy" and "Save and Replace" buttons at the bottom. They are clicking the "Save Crop" button and then just clicking the "X" to close the modal, thereby losing their crop. Could we have the other two buttons also appear at the top right? This would also be consistent with the page edit setup in PW where the "Save" button is duplicated top right.

adrianbj commented 9 years ago

Ryan - there are some awesome mockups from Peter Knight that might help with some of the confusion that we have had: https://processwire.com/talk/topic/9986-image-field-ui-and-general-tidy-up/

I think he has some great ideas there!

eladnova commented 9 years ago

Thanks Adrian Mostly they're sketches in (hopefully) the right direction. I'd really like to see Tom or someone else progress and refine them before anything was commited

isellsoap commented 8 years ago

@adrianbj Is this still an issue?

adrianbj commented 8 years ago

@adrianbj Is this still an issue?

Yep - the same issues still exist with the crop functionality and the position of the Save as Copy and Save and Replace buttons.