Express Migration - Buttons, buttons, buttons

[vhargrave]

Hello good people of the milo community 👋
As some of you might know, adobe.com/express is moving over from pure eds/franklin to milo. One of the interesting topics that we're currently discussing is how we want to migrate and manage our buttons. I have an idea, but I'm not sure it's a great one, hence this post here :).
We have at least 10 different button types currently in express and want to be able to still author those button types after moving to milo. See here - https://wiki.corp.adobe.com/display/adobedotcom/Button+Comparison+Express+vs+Milo
Currently, milo allows for 3 different button types to be authored with several different sizes.
Let's say that express is using a marquee from milo. As a developer I could theoretically override the styles of the milo marquee so that the primary button is not blue, but our more expressish purple. No worries.
At scale though, overriding css styles of buttons of lots of individual blocks & pages does not seem like a good long term solution + our authors have said that they want to be able to control what type of button is used.

I think the best thing we can do currently is the following. We map the three button types that milo offers into our most used button types from express. This allows for them to be easily authored.
At the same time I do think it would be ideal if there was a way for authors to define other button types in a block. The "easiest" way I can think of would be to add something like #_btn-other-details-of-the-button as a hash, which our code would recognize and treat appropriately. This type of approach is a bit annoying though, because authors can't see at a glance what type of button that they're dealing with, like if a link is bold or italic.

A part of me tells me that the most milo approach would be to dramatically reduce the number of button types allowed in express so we can author only using bold or italic links. I have broached this topic and this was deemed as very unideal from the design part of the team.

Curious on your thoughts :)

[mokimo]

Has the consonant team been considered in this? I'd love to route this through them or at least get their input on this. Milo has been established as cross consumer project with milo centralizing shared logic and ideally being the source of truth for most elements.
Thus, IMO it's either express reducing their number of buttons as you've mentioned, milo increasing their number of buttons or a mix of both

[overmyheadandbody]

Totally agree with @mokimo! Your great document comparing the button types should raise some designer eyebrows, there are simply too many variants of the same thing. I'm certain the variations can be reduced dramatically, so Consonant should be involved in this analysis.

From my perspective, we can safely assume that we won't have 10 buttons one next to another to justify having so many different styles. Maybe there's a way to figure out the maximum number of buttons you have grouped together in a given area. That should be the number of supported styles.

Looking at the document, you basically have two types of buttons - with or without border. The colors (text, border, background) then seem to vary wildly. You already mentioned that we're restricted by just a few authoring options - italics, bold, italics + bold, so my first suggestion is to increase the number of Express styles by defining additional classes supported by blocks that would influence the button styles. Although ideally, an author should not have to think which of the 10 variations they need to add, it should simply be contextual - in block X, a link that is italicized has a purple background, while in block Y, the same italicized link is hollow and just has a purple border. If you can figure out such a pattern, that would be ideal. You would gain consistency and make author's lives easier.

[JasonHowellSlavin]

+1 to @overmyheadandbody and @mokimo.

I think if you need all of them and some of the variants could have their styles set based on block context, that might be a win.

As for overrides, it is a bit different with the current Bacom overrides that we have (they mostly have to do with display and positioning for grid-width) but they have caused us a bit of a headache. Our overrides created a slightly different authoring practice, and now removing or modifying them from the content where they exist is going to be a big pain.

I am sure you would think of backwards compatibility, good defaults, etc. but I can also see a nightmare of having to fix a disparity between Milo and Express buttons down the line and most of the content is authored for to utilize an override.

[vhargrave]

@mokimo , @overmyheadandbody & @JasonHowellSlavin
really appreciate your feedback and some good points.
This is going to be an interesting conversation, because Express does not want to sacrifice on any of the buttons / functionality that we have, but that just cements more what you're saying. We need to talk to Consonant. 👍
I'll get back to you all after the outputs of that discussion are done.

@JasonHowellSlavin could you elaborate a little on the overrides that you have in Bacom? Just curious how you guys approached it. :)

[JasonHowellSlavin]

If you are interested, take a look at this PR: adobecom/bacom#181

Essentially, we had added some overrides to fix grid styles that were breaking some of our authored pages when a new grid system was added. Our authors got used to those overrides and authored utilizing them. It was found our overrides caused CLS, so we went to remove it. Fixing forward, like in the PR, apparently caused issues in other blocks unforeseen by my testing, so the merge got reverted and we still don't have a good fix for all of it 😬.

Not sure how many pages Express has, but with Bacom's 70k, any codified authoring practice will result in a fair amount of work to rectify if something changes down the line!

[vhargrave]

I see 😬 - hmmm, all we can do then is try to be extra careful then. We have to add these buttons, but we'll try to triple check that we're adding a good longer term solution. Thanks for mentioning that 👍

[vhargrave]

@mokimo , @overmyheadandbody & @JasonHowellSlavin
thought you'd be interested to know the status of our conversation with Consonant & Spectrum.
The short summary is our buttons are not consonant approved. What we have agreed to though is that until the spectrum team has prepared its spectrum v2 buttons , which will be integrated into milo at some point, our types of buttons will still work in express blocks & milo blocks. I'm going to add code to express which does this though and not to milo.
The plan is that milo looking buttons will get mapped to express looking buttons. See the table here - https://wiki.corp.adobe.com/pages/viewpage.action?spaceKey=adobedotcom&title=Button+Comparison+Express+vs+Milo and also give authors the ability to set specific button styles using the #_btn pattern I described. What I'll probably do though is use #_btn-ax- at the beginning of our buttons, because I think the #_btn pattern is decent and could see you wanting to use it as well for the spectrum v2 buttons.
@narcis-radu tagging you here too since I've heard from Bushra you're also involved with the spectrum v2 button work.

[mokimo]

Sounds like a good plan, particularly prefixing #_btn-ax- is a good idea if a consumer really wants/needs to follow their own path.

Thanks for the update well appreciated! Sounds like a clear and logical way to me to proceed with this

[rgclayton]

At the same time I do think it would be ideal if there was a way for authors to define other button types in a block. The "easiest" way I can think of would be to add something like #_btn-other-details-of-the-button as a hash, which our code would recognize and treat appropriately. This type of approach is a bit annoying though, because authors can't see at a glance what type of button that they're dealing with, like if a link is bold or italic.

Instead of adding the decoration value to the link it could be added to the display text with a | to separate the display text from the styling. Similar concept to how we apply alt text to svgs.

The benefit of this would be that you see the | style-decoration-token in the Word doc with out having to inspect the link.

The pipe and style token would be removed before the DOM is decorated, so that detail would not show up in button once rendered on a page.

cc: @ryanmparrish @vhargrave @overmyheadandbody @mokimo

[vhargrave]

@rgclayton That is a great idea . I've sent a ping to ask our authors what they'd prefer.

[vhargrave]

They prefer the | style-decoration-token in the display text approach. So we'll go with that. Thanks so much for chiming in @rgclayton !

[yesil]

@vhargrave the pipe approach might not work great with placeholders though, at least requires extra processing.
In commerce (also in feds I believe)we have places we call the placeholder API, and all this places need to be checked against this approach.
Ideally, the markup of your Express buttons are exactly the same as Milo ones so that everything can work as expected, which is important for analytics or MEP.

Maybe we can consider using CSS variables which Spectrum Web Components leverage in a nice way as follows:

All styling options such as color, font-size, spacing, etc are made overridable via optional CSS variables which are listed at below URL:

https://github.com/adobe/spectrum-css/blob/main/components/button/metadata/mods.md

If you set any of those variables in your DOM tree, all the nested Spectrum Web Components will use that value instead of default one.

I think this should be pretty easy do in Milo given how lightweight Milo styles are in styles.css.

[vhargrave]

@yesil I think it actually should work because our button code will execute directly at decoration, so even before placeholders or merch stuff is done. And we'll have a clear pattern of | btn or | button that we're looking for. That also keeps this simple and without introducing another pattern to authors.

[yesil]

The fact that some styles are applied via bold/italic and some others via | style-token looks confusing to me.
I wonder what GWP thinks of this approach?
But yeah, as you said, this should work at decoration time.