Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
The crop UI shows immediately and that's nice for a use case where cropping is mandatory.
However, on longer forms, this leads to overlengthy form and cropping should be an optional thing.
Proposed resolution
The cropping area only needs to be opened when a button is pressed. It could be collapsed otherwise.
Similar to paragraphs module, this should be a widget setting.
When collapsed, a button should appear beside the image preview... (Or should we use the image itself?)
We could even completely replace the preview image with the cropping UI?
Currently, the cropping UI destroys editor experience in complex content creation forms.
Remaining tasks
Discuss, decide UX.
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | Screen Shot 2015-11-27 at 18.28.44 .png | 70.15 KB | miro_dietiker |
| #12 | expand-when-requested-2619162-12.patch | 6.32 KB | woprrr |
| #11 | expand-when-requested-2619162-11.patch | 2.9 KB | woprrr |
Comments
Comment #2
woprrr CreditAttribution: woprrr as a volunteer commentedHi @miro thanks a lot for your feedback again :)
This possibility has already been reflected, for now the main need was to have the widget automatically activated and ready to croper. I think it would be nice to add a general configuration page for IWC.
Or one could force open the widget has the upload. On the other hand we could add a button to trigger the crop when we are in the case of a non-mandatory field just as you suggest.
So it's better to make a general configuration or form-display option for forced or not the opening in the non-required. And in the case required it does not display the button but directly to the widget as inline_entity_form croper done.
Comment #3
woprrr CreditAttribution: woprrr as a volunteer commentedComment #4
miro_dietikerI don't think this should go into a global configuration.
This kind of settings usually live on form widget options and i really think it's to be determined on a per-field level:
- For a media specific node type, cropping possibly should be expanded right after upload.
- For a long content oriented node, with many fields, cropping is a rare case and the widget should be as compact as possible.
Having both a global and a per-widget setting results in inconsistencies or complexity.
BTW from the perspective of user awareness, say 3 crop styles are relevant, the current us does not help too much:
As user needs to click on each crop style to realise what will be displayed when the style is applied.
Instead, by default, a small cropped thumbnail should be displayed per crop style (by default).
Then the user can click on one of the thumbnails and the editing gets triggered.
I would consider it a special case that you want to have the editing area expanded to kinda force the user to crop.
What do you mean by non-mandatory field or required field?
Are you referring to required as in media upload, or required as in the cropping needs to be defined using the UI per style?
IMHO in both cases, awareness is enough and i don't see how we should enforce cropping at all (through validation)?
Comment #5
woprrr CreditAttribution: woprrr as a volunteer commentedIn the first version of the module, we have a thumbnail by style farmhouse actuelement what is present in the list that is not the image styles but different crop type used by different imageStyle. As seen with this absolutely must slashrsm based on different types of crop. Because a user just perfectly assign the same crop type over several ImageStyle and this in a view to making UX less verbose and less complicated to handle.
I can understand your point of view and there is a real need. In the end what to do actuelement I think, would be to propose a configuration on the widget like "expand" and by default set to false in order to have made "lite" with an outbreak of the widget via a button (a decide what we can do in practice) and clearly choose the default extended mode.
Regarding the need to offer the user the opportunity to view before saving. This is another need, and I already thought my expert UX add a side of the cross (hover) an icon like this one (http://fortawesome.github.io/Font-Awesome/icon/eye/). On click on this icon we would have a popin directly with a rendering of the crop and rendering perform with the image uploader.
Comment #6
woprrr CreditAttribution: woprrr as a volunteer commentedFor now, I have not touched a thumbnail part because it implies that imageWidgetCrop have assume the button responsibility "remove" and also implies a truly radical change with the image interface. Currently I add elements that provided a picture image and only adds its components also extend line items. I am staying in this light. I'll look at what this means to remove this preview image.
You have an example ? IWC integrated properly with multi upload mode (table), default form (edit / add) & quickedit too. I ve tested with field_group too and seem all fine.
Comment #7
woprrr CreditAttribution: woprrr as a volunteer commentedComment #8
miro_dietikerAbout: "the cropping UI destroys editor experience"
I'm referring to the fact that it adds large vertical scroll bars just because cropping is an option and the form gets significantly longer.
If a form has multiple image fields, the form gets really hard to handle.
IMHO, the widget goal should be to limit extra length to an absolute minimum for the default collapsed case. My theoretic goal would be the same length like the regular image widget. ;-)
Comment #9
woprrr CreditAttribution: woprrr as a volunteer commentedI work currently on it, i can purpose an example tomorrow ;)
Comment #10
miro_dietikerSounds awesome.
Do you think things are totally clear?
I thought best would be to trigger some people from the community for a UX proposal.
But i'm also happy about first steps in implementation to then challenge editors for more feedback / to figure out how we can further improve.
Comment #11
woprrr CreditAttribution: woprrr as a volunteer commentedA first proposal for the action button. This is not to change the whole flow and place the button in the widget zone of action (as remove button).
I think also use a wrapper such details so that it is directly supported by Drupal and the user just has to click to display the action area.
this seems to be the right way ?
Comment #12
woprrr CreditAttribution: woprrr as a volunteer commentedHere is a more complete version , and more functional .
( This is available on the branch 8.x.1.x-dev )
Comment #13
woprrr CreditAttribution: woprrr as a volunteer commentedComment #14
miro_dietikerAwesome step. Will test ASAP. :-)
Comment #15
miro_dietikerYeah i like this a lot.
Thought it is committed, but needed to apply the patch still..
A good starting point for more advanced UI steps. I think we should get this in and discuss in followups!
It's compact again by default!
(Not sure if it should be blue, button spacing is a bit strange if you have long filenames, and if the button should also toggle somehow)
I also tried with some multivalue field and i would prefer to have the crop button at a stable horizontal position.
Comment #17
miro_dietikerAwesome, a good step forward.
I created followups such as
#2625026: Crop widget crop list not following common patterns
#2625028: Display a crop thumbnail for all defined crops when editing
#2625032: Always expand crop if a crop type is defined