In TYPO3 CMS, we had positive feedback regarding editor experience when we simplified the responsive image handling to the max:
So the user can basically select position and size (relates to size on desktop device) in only one option.
What do you think is the best practise from the editor’s point of view:
- A combined select box similar to the screenshot above.
- One select box for position and one for size
- An approach not mentioned here
What do you mean by “responsive” ? In the screen shot I see only option about the position of the image, and nothing about the responsive variants.
Maybe the title of the topic is misleading: The reponsive behaviour is not controllable by the user but pre-defined through CSS. So it would be the same question for non-responsive websites.
I’d choose “One select box for position and one for size”.
But regarding size, I think elements should always stretch 100% to the size of parent container, and the width should be managed by grid elements (like grid and block-grid from Foundation).
It might be an extreme position, but I don’t like these dialogs at all and I think sometimes less options are much better for usability and end result.
I used to create “editor guidelines” like: “to create a new article create a headline, style 3, and underneath a Text w/ image, next to the text, 1/8 […]”. Just give those things a name and create a custom node type instead, it has many advantages:
- It’s harder to use it wrong
- It’s easier to redesign
- It allows for Structured Data
And with NodeType Constraints you can make sure that the “New Element” wizard won’t grow out of control and that the editor can’t add an “article” to the Footer of your website
+1 for @bwaidelich comment
The Editor must focus on content, the Integrator on enforcing the website style guide has much as possible and Neos is flexible and powerful, ex: you can change the alignement of image, if it’s in the main content collection or in a multi column or in a product page …
The layout in Neos must be context based, and no options based. You end up with a website with consistent layout, and editor free of long documentation on “What to do or not do”
Thanks for the suggestion. Implementing this is possible currently without any changes to the core and I agree that less is more here. It’s hard to create a solution that will work in all situations, so therefore I’m more in favor of keeping the core slim and making this something a custom package could do if you want. We have the alignment property currently from legacy reasons, but at least it can easily be removed if desired.