Live Blogs Post Component

[ker-an]

Live blogs have a direct impact on engagement and drives search engine traffic which is why Content Innovation has been tasked with rebuilding (and improving) it.

Currently, a reader experiences two different versions of a live blog when viewing it on the App or FT.com - with the experience on the App being worse. Content Innovation would like to create a live blogs post component using x-dash so we can provide a consistent reader experience across Customer Products platforms.

Here's a screenshot of a current live blogs post on...

FT.com:

the App:

[apaleslimghost]

i think this is a good idea. i have a couple of questions:

1. i'm guessing it'll follow the FT.com design? using CSS modules in the component? (that's x-dash's convention, see x-gift-article for an example)
2. is the relative date required? x-teaser outputs o-date markup but expects the app consuming the component to initialise o-date, would that be okay?
3. same question as 2 but for the share buttons, is it okay for the consuming app to have to handle initialising o-share?
4. the live blogs controller in the mobile apps is... bad (it's okay i can say that i wrote it). using an x-dash component there might be tricky. do you also plan to build a live blogs post list x-dash component? there's nothing really that complex in x-dash yet but i think it would be a good fit; orchestrating the events & posts in the x-interaction model might be hard though, so that might be the time to investigate using Hooks (get rid of x-interaction #248)

[GlynnPhillips]

Hey @apaleslimghost here are my responses based on limited knowledge of x-dash.

1. Yes, taking a brief look at gift article I think this seems sensible.
2. Yes this should be fine
3. Yes this should be fine, but another alternative would be to have this component only interested in the "content" of a post and have the share component added by the consuming app.
4. With a lot of live blogs code base in the mobile apps and next-article we plan to start from scratch unless it makes sense to try and save something. I think your suggestion is interesting and something we should certainly look into and chat with you about for any guidance.

Worth noting we don't have a "final" design yet but we have something we can use as a starting point but this could mean there is room for change in these answers. Eg. If the timestamp changes this is something we would have to take into account and maybe change our decisions

[magsallen]

I don't have any technical comments but this seems like a great idea and I'm excited that the Live Blogs are getting this love and attention 💙

[adgad]

👋 I have a question, following on from some discussions about sharing code https://github.com/Financial-Times/spark/issues/1345

At some point Spark will probably want to have a preview of live blogs that looks something like this. Given this is our first new content innovation work, it would be good to think about how that works from the offset.

1. Can Spark import and use the x-live-whatever component? I know the Readme says FT.com/App, but is there any reason it shouldn't be used by us?

2. If the answer to the above is no - should we then make it an o- component from the beginning, so it can be used by Spark?

[ker-an]

@adgad good question! To be completely honest, I don't know about your first question. Maybe @apaleslimghost can shed some light! I believe she's on holidays this week so I'll check in with her next week.

[apaleslimghost]

hi! there's no reason an x-dash component can't be used in e.g. Spark. the "FT.com/App" clause is there because we wanted to be able to make assumptions about the environment that an Origami component can't. however: i can't commit Customer Products/Platforms to supporting this use case.

since this component looks like it will include templates, it can't be made an Origami component in the current spec. i know there's a desire to allow this in the future though. (who knows, in the future, x-dash components might be Origami themselves, but you didn't hear that from me)

[adgad]

Yeah, ownership/support is always going to be a problem 😅 But I guess of all things, a versioned, well documented component like an x-* is quite low risk for us to consume. We'd have to see if the same assumptions hold true for spark though, if it Just Works then hooray!

With the origami thing, I guess that I was thinking the styles could be o-dash, and then that would be consumed here for use with a template (with Spark using just the o-dash bit). Future sounds exciting though!