New pattern for qunatity-selector component.

[VKniaz]

Proposal for New Quantity Selector Pattern in Merch Cards

Dear Team,
I am reaching out to discuss a potential enhancement to our merch cards, as detailed in the JIRA ticket MWPW-135163(https://jira.corp.adobe.com/browse/MWPW-135163)]

The proposed pattern for this feature is [title:_min:_max:_step:].

document example:
https://adobe.sharepoint.com/:w:/r/sites/adobecom/_layouts/15/Doc.aspx?sourcedoc=%7BAA370755-2294-4115-97F1-367C5CE175F6%7D&file=Document6.docx&action=default&mo

link:
https://mwpw-135163--milo--vkniaz.hlx.page/drafts/vkniaziev/document6

I would greatly appreciate your input regarding this proposed change. Specifically, I am interested in any concerns or objections you might have about introducing this new pattern.

[vladen]

@VKniaz Thank you for bringing this up.
The web component, I'm currently working on, also needs some authorable literals/settings and I see two approaches to handle them so far:

1. Positional params, proposed by @yesil in the yesterday's demo: position of a content element in the content of its block defines its purpose.
2. Named params, proposed by you in this discussion: a content element contains an encoded set of key-value pairs.

IMO, to preserve simplicity of content authoring we should choose only one approach and agree it should be standard.

Let's analyse your proposal.
For the first card in the referenced Word document, Helix backend generates HTML having this structure:

<div class="merch-card plans secure">
  <div>
    <div data-valign="middle">#EDCC2D, #000000</div>
    <div data-valign="middle"></div>
  </div>
  <div>
    <div data-valign="middle">
      <h3 id="acrobat-pro">Acrobat Pro</h3>
      <p>
        Access advanced PDF and form creation, editing, and protection features
        tailored to enterprise security and compliance requirements.
      </p>
      <p>title=Select a quantity_min=1_max=3_step=1</p> <!-- named params -->
      <p>
        <strong><a href="...">CTA {{buy-now}}</a></strong>
      </p>
    </div>
  </div>
</div>

To parse quantity selector params out of it, you code needs to find a first p in the second div by performing positional lookup, then parse its content as an encoded string and then perform named lookup in the resulting collection.

This sounds three times more complex than just positional lookup, proposed by @yesil, and real benefits of such complication are unclear to me. So, I'd vote to keep simple positional lookup, already widely used in Milo, instead of introducing the need of manual creation of strings in custom format to pack sets of key-value pairs.

An inconsistency note: String format proposed in this article differs from the format in the sample Word doc.
title:_min:_max:_step: vs title=Select a quantity_min=1_max=3_step=1

An example of positional params in the catalog fragment, demoed by @yesil: https://main--cc--adobecom.hlx.page/drafts/ilyas/fragments/catalog:

<div>
  <p>Search all products</p>
  <p>Filters</p>
  <p>Sort</p> <!-- position param -->
  <p>Popularity</p>
  <p>Alphabetical</p>
  <p>0 results</p>
  <p>1 result in <strong><u>filter</u></strong></p>
  <p><u>10</u> results in <strong><u>filter</u></strong></p>
  <p>1 result for <strong><u>search</u></strong></p>
  <p><u>10</u> results for <strong><u>search</u></strong></p>
  <p>1 result for: <strong><u>search</u></strong></p>
  <p><u>10</u> results for: <strong><u>search</u></strong></p>
  <p>Your search for <strong><u>search</u></strong> did not yield any results</p>
  <hr>
  <p>Your search for <strong><u>search</u></strong> did not yield any results. Try a different search term.</p>
  <p>Suggestions:</p>
  <ul>
    <li>Make sure all words are spelled correctly</li>
    <li>Use quotes to search for an entire phrase, such as "crop an image"</li>
  </ul>
  <hr>
  <p>Show more</p>
</div>

[yesil]

Thus, the absence of QS might mean no QS should be displayed for that specific offer.

[vladen]

I like idea of comma separated list for min, max and step settings. With proper number of commas, any settings can be easily omitted if unchanged. the latest space character in the string can denote end of title and beginning of settings.

So, the parsing should be simple enough:

• split input string into two parts by the latest space
• use first part as title
• split second part into three parts by comma
• use three new parts for min, max and step
• assign default values to missing settings

The authoring/translation process looks simple too in this example.

Also, this content structure can be made multiline to separate component title from settings:

[VKniaz]

I like the idea of:
Quantity

• title
• config
  but it doesn't make sense to have it on the level of each option. Options are either radio buttons or dropdown-configuration.

My propositions to author it like:

[yesil]

@VKniaz this implies that, all the offers have quantity selector and have the same start, step, stop settings.
This is not flexible IMO.

[VKniaz]

The offer-select component, which has already been created using these instructions, acts as the controller that listens for changes in the quantity selector and applies different modifications to the cta or prices. If the q-ty selector is absent, it behaves like a radio button. So, having it as part of the offer makes no sense. We can discuss it in person @yesil @vladen.