Story format

[silvester-pari]

We had some initial discussions that markdown would be a good format for stories, as it comes with the benefit that it is easy to learn and widely adopted. It is also rendered natively by GitHub. Each markdown file would be corresponding to one story.

We could think of using some frontmatter to define meta about a story, e.g.

---
story-layout: scrolly
author: Silvester
thumbnail: ![https://eox.at](https://eox.at/EOX_Logo.svg)
---

Then, inside the story, we could define blocks/sections/pages with things like horizontal lines:

---
a new section!

Additionally, some settings could be done using hidden properties in markdown, which don't render in the GitHub preview, but do render in our own renderer, like e.g.:

[background-color]: #f00
[scrub-direction]: horizontal

Ideally, the interactive elements would always allow fallbacks, e.g. if a story is rendered without JS, it would still show a still image of a map, and when the story is rendered with our renderer, it would replace the image with an actual map etc.

<eox-map><img slot="fallback" src="https://eox.at/EOX_Logo.svg" /></eox-map>

[santilland]

Although i am very much in favour of using "vanilla" markdown and only supporting our special components, i still think it might be interesting to keep an eye out for other markdown formats that integrate javascript:

• MDX
• mdjs Markdown JavaScript - possibly more intended to be generated statically

I think these options are too open for allowing users to interact with and the "backwards" compatibility to vanilla markdown i think is lost, but they might have value to be explored.

[lubojr]

I am be in favor of not integrating of javascript directly via MDX, but we should support basic HTML elements - and Silvester's code snippet shows (coming back to our discussions for STAC Info Element) and like GitHub does and our custom formatting enabling functionality on top.

[srijitcoder]

To enhance user convenience, we should offer two way editing methods:

Markdown:

Following @silvester-pari's suggestion, we'll use a basic GitHub-like markdown renderer integrated with our frontmatter meta structure. This approach will configure each section/block/page effectively. Additionally, I am also against incorporating JavaScript with Markdown to keep things straightforward.

Drag & Drop Component:

In tandem with Markdown, users should have access to predefined block sections/components. These can be easily manipulated via drag-and-drop, and customized using a dynamically generated form, as shown in the third image.

For our MVP, I recommend using our predefined components to ensure consistent styling and easier maintenance.

[santilland]

I like the drag-an-drop approach, it would mean less experienced users can more easily use the tool. I am not sure though if it should be part of the MVP, i would focus on the markdown possibilities and checking that integration of components works as expected. I consider the blocks a "nice to have" that should only be started when other aspects are already working.

Looking at the concepts drafts, we should also consider how we can bring a state of the dashboard (for example, selected indicator, current extent and selected time) to the editor.

• Using the drag & drop concept, would the map component be pre filled with selections in the dashboard?
• Or would we consider instancing the dashboard within a "block configuration" area?
• Maybe (as we have with the "add to custom dashboard button" currently) we could have a "copy state for story" button, that creates the necessary markdown and you can paste it into your story? This could be the simplest approach for an MVP?