Marquee(split) Enhancement - Ability to specify unique foreground Media element for Mobile #1704
-
An enhancement requirement has come for the split variant of Marquee block (MWPW-140864) to be able to specify unique foreground media element for mobile devices. When viewed on Mobile, the ambient video background should be swapped with a static background and a "hidden" static image is positioned as first/top element. As per my understanding and the discussion on the jira, this is the required behaviour from the split marquee -
I would like to request some confirmation on whether my understanding is correct regarding this, especially for the tablet view. In order to implement this, I am leveraging Milo's capability to specify unique backgrounds for different breakpoints and authoring the split marquee with one subject image which will be hidden in tablet and desktop viewports, but seen in mobile view. We are providing only 1 subject image in the authoring as we do not require other static images for tablet and desktop (since we only have an ambient bg video for them). Here is the link to the POC I have implemented - https://marquee-split-enhancement--milo--drashti1712.hlx.page/drafts/drashti/MWPW-140864/document @auniverseaway @chrischrischris @rgclayton @ryanmparrish @vhargrave @overmyheadandbody @jeremy @salonijain3 @dstrong23 @amitbikram @aishwaryamathuria @suhjainadobe |
Beta Was this translation helpful? Give feedback.
Replies: 13 comments 3 replies
-
Hi @drashti1712, below are few of my observations on above query:
cc @dstrong23 @auniverseaway @salonijain3 @rgclayton @chrischrischris @ccongerp |
Beta Was this translation helpful? Give feedback.
-
Hi @Ruchika4,
Please let me know if this authoring works.
This is the link to the updated POC: https://marquee-split-enhancement--milo--drashti1712.hlx.page/drafts/drashti/MWPW-140864/document-columns Kindly let me know if this works. CC: @dstrong23 @auniverseaway @salonijain3 @rgclayton @chrischrischris |
Beta Was this translation helpful? Give feedback.
-
Thanks for addressing the issues @drashti1712 . Regarding the authoring pattern, I am not an expert but I feel having all the foreground images in one column is better. We can also discuss this with Kyungwha Lee from Design team and finalize the authoring pattern. @rgclayton could you also please share your thoughts on this. CC: @dstrong23 @auniverseaway @salonijain3 @rgclayton @chrischrischris @ccongerp |
Beta Was this translation helpful? Give feedback.
-
After reading the Jira ticket, my understanding of the ask is the same as what Ruchika stated. Add the ability to have per-breakpoint (mobile, tablet, desktop) foreground images/videos. I don't see anywhere in the ticket that mentions swapping out background image with foreground image. I also think the authoring pattern @Ruchika4 mentioned is a bit more simple. Adding more columns to the foreground section of the block really starts to complicate and constrain authoring the content. To reiterate what Ruchika proposed. With this pattern I do think we would need to come up with options to NOT show an image on a specified break point. Maybe in place of the image the key word "none" is added? So the authoring pattern to only display images on mobile and tablet would look something like: If "none" is there it obviously wouldn't have a media-placement property. Also, something to note. The marquee background image |
Beta Was this translation helpful? Give feedback.
-
Hi @drashti1712 , One suggestion regarding adding css for reverse order can we add it like below with marquee block. My suggestion is to add like below as I see few issue with localization (will have to add DNT to media-bottom text else it'll not work on localized content) with above approach also find below more clean. Authors can add reverse-order(or a text that is more relevant and agreed upon by everybody) along with block name and we can put logic to reverse the position of media and text in mobile view if it is added. CC: @dstrong23 @auniverseaway @salonijain3 @rgclayton @chrischrischris @ccongerp |
Beta Was this translation helpful? Give feedback.
-
This is @udbroom = Kyung lee One thing to note is that how these foreground images should behave. foreground image should follow the same structure: When I review the POC page Ruchika provided, the page was broken to me. |
Beta Was this translation helpful? Give feedback.
-
Hi @udbroom @Ruchika4 @rgclayton Also below is the link to the current POC and the page is not breaking for me. If there are some specific issues, could you please let me know? |
Beta Was this translation helpful? Give feedback.
-
@drashti1712 - I took a look at your POC and noticed the .marquee.quiet is broken, but I'm guessing there is an easy fix to address this. [marquee ] This way we have a pattern that can in theory apply to other blocks and is easier to manage visually and in the .js decorator. There are also some SEO implications w/ having these assets show/hide based on view, I don't know if this needs to be SEO first and experience second, but something to consider. |
Beta Was this translation helpful? Give feedback.
-
Hello all, The authoring proposed above (an additional content row for each viewport) addresses this problem and takes into account potential future needs for unique copy per viewport. However, if copy is to always remain the same across viewports, we could also use different rows for each image. Something like: cc: @ryanmparrish @udbroom @Ruchika4 @rgclayton @salonijain3 @aishwaryamathuria |
Beta Was this translation helpful? Give feedback.
-
We also have another ticket that needs to integrate the same ennhancements in the Aside block https://jira.corp.adobe.com/browse/MWPW-140593 and we would use the same authoring pattern finalised here for Asides as well. CC: @salonijain3 @ryanmparrish @rgclayton @Ruchika4 @dstrong23 @auniverseaway |
Beta Was this translation helpful? Give feedback.
-
@auniverseaway Can you please look at this once, we will start implementing this as we have incorporated the comments in the final design. |
Beta Was this translation helpful? Give feedback.
-
I am not an authoring expert, but a simpler way to keep the table neat might be by adding an extra row(Optional) to support multiple foregrounds. cc: @rgclayton @auniverseaway @ryanmparrish @salonijain3 @dstrong23 @Ruchika4 @drashti1712 |
Beta Was this translation helpful? Give feedback.
-
My preference:
More cells are generally a bad idea. It adds complexity when often it isn't needed. It also creates a parsing nightmare when converting to divs. The one where we are blending colspans and rowspans is very much an anti-pattern that we should not encourage. There's a reason we gave up on table-based design in the early 2000s... complex tables are the reason... I would not ask any author to use this paradigm. From what I recall, the only thing we use cells for in background is so that we can group positioning text. With foreground, I don't see that being a need. Also, we can always use nextElementSibling to get any decoration text. I can live with Amit's suggestion as it keeps a consistent colspan / rowspan pattern and does not blend the two, but I do not prefer it. It changes the fundamental shape of marquee content in these contexts and I think that's not ideal. |
Beta Was this translation helpful? Give feedback.
Hello all,
I tried implementing the proposed authoring pattern with the stacked images in a single cell and I agree with @ryanmparrish's comment on this thread. The current marquee block lets authors add media credits below the image and make the image clickable by adding a link on top, as shown below:
If we stack the images in one cell and have different credit sources or links, then specifying them together might become an issue.
The authoring proposed above (an additional content row for each viewport) addresses this problem and takes into account potential future needs for unique copy per viewport. However, if copy is to always remain the same across viewports, we could also use diff…