Closed rofe closed 4 years ago
What about this approach?
banners
The author then adds a relative link like this:
/banners/acrobat_free_trial.html
to the Markdown, which Pipeline will pick up as an internal embed, which will be included. We then use CSS and a bit of JS to render the banner.
Advantage:
Disadvantage:
Would work for me as well. For ease of use, we could still provide a picker which has the QR-coded thumbnails.
@davidnuescheler wdyt?
For the record, here are some banner samples:
This https://github.com/adobe/helix-pages/issues/78 would be required to implement @trieloff's solution.
Also, if we embed the content in the page, how are we going to style it ? We should be able to define that this is a "banner" include that requires a "banner" style...
@davidnuescheler has convinced me that the source data is more table-shaped than document-shaped, so the first approach would probably work better.
I would love to see an example of that because in the current state, I do not see of this can work ;)
...
blablabla
---
/banners/1234
{{title}}
{{backgroundImage}}
({{buttonText}})[{{ctaUrl}}]
---
blablabla
...
As an author, I only want to do something like:
...
blablabla
/banners/1234
blablabla
...
@davidnuescheler's approach depends on https://github.com/adobe/helix-data-embed/issues/34 – @kptdobe you can look at the example there to see some ideas how the URL (and resulting markup) would look to the author.
In general, I think my approach favors the banner embedded, whereas @davidnuescheler's approach favors the banner author, especially when it comes to bulk editing.
I'm honestly not sure which way is better and the uncertainties about https://github.com/adobe/helix-data-embed/issues/34 don't help either.
Fwiw, I don't know if bulk editing is really a thing for these promotions, @avanishgandhi can you find out? It might well be that these are created as one-offs, referenced on a few articles for a period of time, and then left alone without ever being edited again.
Btw – just to throw another idea against the wall: These banners look like it would be really easy to author them using Adobe Spark Post. We do have an existing integration between helix-embed
and Adobe Spark that we could use.
The only limitation that I see is that the entire banner would be the link target.
They are already able to do these "banners as an image": https://theblog.adobe.com/business-resilience-leading-through-change/ At the end of the page, they are 2 "banners": one is an html version, the other is an image that they built somewhere else, similar to your Adobe Spark Post proposal.
At the end of the page, they are 2 "banners"
I only see the html COVID-19 banner on this page... maybe I'm looking in the wrong place?
The only limitation that I see is that the entire banner would be the link target.
I don't think that would be a problem. I even think it would be better from a usability perspective 😄.
You do not see the "Summit is now online" banner-like-image right after the COVID-19 one ?!
Nope:
Fascinating:
Secret feature ?
Another limitation with Spark: the link target needs to be specified somewhere. Maybe a staggered approach would work:
Secret feature ?
Apparently I'm not in any targeted segment 😂
- banner document embeds spark post and adds link (below)
I'm starting to think that Spark Post would be solving for the wrong a different problem: banner creation, which we excluded from the scope so far, instead of banner management (doc or spreadsheet) and referencing (embed).
Apparently I'm not in any targeted segment 😂
Scary. For me, it is part of the html response. So either they hide it client side for you... or the page is not cached at all!
While we are debating ;), I have made a test with what we already have + 2 minor fixes:
For the 4 identified banners, I created one md file with the required content to represent each of them following the same pattern (a lot of differences between the various banners). See the promotions folder: https://adobe.sharepoint.com/sites/TheBlog/Shared%20Documents/Forms/AllItems.aspx?RootFolder=%2Fsites%2FTheBlog%2FShared%20Documents%2Ftheblog%2Fen%2Fpromotions&FolderCTID=0x012000291CC2F215041D41ADE01F0A04AB94F2
As an author, to get the banner, I simply add (markdown):
../promotions/covid-19-response.md
or
../promotions/covid-19-response.html
or
/en/promotions/covid-19-response.html
And the banner is injected in the DOM as:
<div class="default" style="opacity: 1; transform: translateY(0px);">
<div class="default product-banner">
<h1 id=""></h1>
<p>As the situation with COVID-19 unfolds, Adobe is committed to giving you the support and resources to navigate this challenging time.</p>
<p><a href="https://www.adobe.com/covid-19-response.html">Learn More</a></p>
<h2 id="covid-19-response">COVID-19 Response</h2>
</div>
</div>
Final step would be to "reorganise + style" this piece of DOM clientside like we do everywhere else.
While this does the job, the limited correspondances between the banners (text overlay in one case, text in the image in another, one has no title...) make the approach hard to generalise and would require the author to know exactly what are the options. This applies probably less for the spreadsheet approach but the grid would be pretty randomly empty and reveal the un-structured nature of those banners. For the spreadsheet approach, we still need a place where to define "this is a product-banner" which I solved via the "class" in the frontmatter. Interestingly, this is our eternal issue that we solve with "components": I have the data, I have a way to include, just missing the piece in the middle that define how to render it.
Here are some first migrated examples with banners:
With https://github.com/adobe/helix-theblog-importer/pull/20, new banners are automatically created under /en/promotions
and corresponding DOM is replaced by an internal embed.
Initial styling is here: https://github.com/adobe/theblog/pull/187
Found a broken Adobe Sign banner here: https://promotion-banners--theblog--adobe.hlx.page/en/drafts/migrated/2020/04/27/the-state-of-utah-uses-adobe-sign-to-accelerate-telework-during-crisis.html
First implementation with:
/en/promotions/<bannername>.md
/en/promotions/<bannername>.docx
---
class: banner
---
Title (Heading 1 - optional)
Background image (optional, black background otherwise)
Description (paragraph)
<cta link>cta button text</cta link>
Product icon (optional)
Notes:
class: banner
frontmatter is mandatory (required for styling)Found a broken Adobe Sign banner here: https://theblog--adobe.hlx.page/en/drafts/migrated/2020/04/27/the-state-of-utah-uses-adobe-sign-to-accelerate-telework-during-crisis.html
For now, only the few blog entries I manually imported are up-to-date. I imported this specific posts to test and it renders as expected. But not super nicely. I'll create a follow up ticket to review the banner styling when the new design is implemented.
I am planning a full re-import (beginning of next week) of all the blog posts as soon as the embeds are stable and theblog.adobe.com cache has been flushed. This will re-import all banners in all blog posts and convert them properly as embeds.
Some articles feature promotional HTML banners consisting of a background image, a title and text, an optional icon and a "call to action" button with label. There is a number of them that will be reused in different articles.
Example:
I discussed a potential implementation with @davidnuescheler and we thought it would be best to edit this data in Excel and use data embeds to render them. So the above would look like this in a spreadsheet format:
The article would contain the URL to the spreadsheet incuding the ID of the banner to render. Helix would then apply a template and turn it into something like this:
What we need:
helix-data-embed
needs to support an ID so it will only render a single row.helix-pipeline
needs to turn the image with QR code into a data-embed