[drupalMedia|drupalImage] Allow removing data-align in the UI, and making an image inline

I noticed something similar. Since the very beginning inserted media were getting data-align="center". I don't know why.

I like option 2 best.

Hm … the UX works as expected, but I am really confused by the button label. I would expect:

• No alignment
• Flow with text

as button labels, not break text. Maybe that's just me? 🤔 I have never seen "break text" before.

The icon is clearer than the label IMHO.

Will compare with similar UXes tomorrow.

On top of that, images have an option to make an image inline.

I still can't make images inline, if that's what you mean? Can you elaborate?

Apple Pages: "above and below"

Atlassian Confluence: /

Toggling the currently active alignment style is what disables alignment, just like the second proposed solution in the issue summary (which btw needs an update because the current MR implements a third, undocumented approach)

CKEditor 4 in Drupal 8|9

Same as Atlassian Confluence.

CKEditor 5: "in line"

… but this behaves slightly differently: this really makes the image in line with the text line. It is either in line without alignment, or with text wrapped (== inline too) + left/right aligned or text not wrapped + left/center/right aligned.

Demo: https://ckeditor.com/ckeditor-5/demo/#document → the signature image

Google Docs: "break text"

I … am not sure. I was pretty confused by "break text" — I had no idea what it meant. It only makes sense when somewhere in the UI it says "wrap text" too, and that really is only the case in Google Docs. Apple Pages names it differently. Microsoft Word (which I do not have available) uses again different terminology (based on a DuckDuckGo image search).

That is more inline with the default CKEditor implementation + approach implemented by Google Docs.

This is true. But it's not exactly the same.

My conclusion: every rich text editor does this differently. Therefore there is no clear best choice. I personally think that the label Break text is confusing, and either No alignment or No alignment (breaks text)would be clearer. But if you feel strongly about the current approach, I'm fine with that too.

19b3c464 basically is exactly what the CKEditor 5 text editor does at https://ckeditor.com/ckeditor-5/demo/#document. The other demos that they have there are tweaked to have a "side image" image style, which is always right-aligned (left aligning is not supported in those demos).

Discussed in detail by 3 people: @lauriii, @nod_ and I. We reached the conclusion that A) there is no consistency at all between different rich text editors, B) "center align with wrapping text" is not supported by Drupal's data-align filter, which arguably is confusing/inconsistent, but it's been working this way for many years now. Changing that would definitely result in a BC break.

Therefore it seems reasonable to move forward with a solution that:

1. is better than HEAD
2. follows CKEditor 5's lead (which is why this is also adding the ability to turn a block image into an in line image)
3. does not break backwards compatibility

We can then refine this further in the future.

I agree that this is an improvement over HEAD and that justifies adding as-is, but I do have concerns about the wording that I'd like explored in a stable blocking follow-up. Perhaps we could bring it to a UX meeting. That doesn't need to block the feature addition here, though.

I also noticed the tooltip provides different wording for effectively the same button depending on it being whether its directly in the toolbar or a dropdown. This would be a consistency concern regardless, but it seems especially important here as the icons are kind of difficult to visually distinguish already.

Not sure I like the dropdowns either - I'd rather it be a single dropdown or all in the main toolbar. It doesn't necessarily need to be in this issue's scope but I wanted to get that documented here too.

I also noticed the tooltip provides different wording for effectively the same button depending on it being whether its directly in the toolbar or a dropdown.

I noticed this too. There's less text in the tooltip if you're already in the context of a specific dropdown. I think this is okay? This is the way CKEditor 5's dropdowns work.

I'd rather it be a single dropdown or all in the main toolbar

"All in the main toolbar" is exactly what @lauriii had in his first iteration and what I opposed. It becomes an enormous toolbar with an overwhelming number of choices.

I personally also still prefer a single dropdown. But @lauriii has some solid concerns about that because not all alignments work in the same way, AND for images there's also the "inline" functionality.

That being said … I think that a single dropdown for both images and media, and descoping the "inline image" button from this issue might be the most elegant way forward nonetheless. IMHO presenting all of these in a single dropdown is still the least amount of mental overhead, and the effects of any of the choices are clearly observable.

Curious what @lauriii thinks 🤓

I presented the tooltip naming and button location to the Feb 25 UX meeting: #3265255: Drupal Usability Meeting 2022-02-25. It was an active and productive conversation.
Broadly:

• There was agreement the tooltips should not have different naming based on their location
• The preference among all attendees who discussed this was to have all alignment buttons in the primary toolbar - unless there was a chance of there being significantly more alignment buttons in the future, in which case a single dropdown would be desired.
  Everyone was +1 or neutral on adding separate buttons:
  
  A few additional things:
  • Were a select element used, @benjifisher specifically mentioned a preference for a dropdown vs the current dropbutton, and @ckrina agreed
  • Several people mentioned that the # of buttons would not bother them. Toolbar real estate isn't a big deal. We checked on mobile widths and everyone was still fine
  • It was pointed out that usefulness of separating the different types of alignment is canceled out by the confusion of separate buttons making the functionality appear more different than it ultimately is

The "in line" wording was not discussed. I'd still like that to happen at some point but it doesn't have to be in this issue.

For the record, the attendees at today's usability meeting were andregp, Antoniya, AaronMcHale, ckrina, bnjmnm, kimberlly_amaral, worldlinemine, victoria-marina, tmaiochi, rkoller, shaal, and me.

It looks as though @bnjmnm credited most of us before Comment #25. I will add credits for the ones he missed.

The issue for the usability meeting (link in #25) will have a link to the recording and a transcript.

After so much careful iteration and balancing of different aspects, I feel like we've arrived at a very good balancing point.

When @lauriii, @bnjmnm, @hooroomoo and I discussed this yesterday, I felt @bnjmnm made a crucial point: it is very empowering for the user to be able to toggle between different options in a fast and simple manner. Then concerns about making the labels perfectly understandable — while still important — matter less. Especially in a context like this, where no text editing software in the world is conveying this perfectly, hence they all do it differently.

This is without a doubt a leap forward. 😊🚀

Very minor feedback in MR, enough that it can be switched back to RTBC after it is addressed in my opinion.

Prepared to commit when the version-specific patches are green

I suspect tests need to be updated due to #3264775: [drupalMedia] Toolbar should be visible when element inside <drupalMedia> is focused being committed since tests last ran for this issue.

Great work and navigation of tricky UX issues. Committed to 10.0.x and 9.4.x, and intend to add to 9.3.x (since CKEditor 5 is experimental) when the production branch freeze is over.

Commit freeze is over, so ported to 9.3.x.