RNGS archives/editions structure #1
Comments
Open question: AI filesOne option could be to put AI files -- So something like... ... in the development directory is ... ... added onto the media archive for that embed. Any AI files that don't map to an embed archive would then be uploaded directly to the RNGS server the usual way. |
|
This would be the dist structure built out of sveltekit in this example:
A client using our |
|
@MatthewWeberTR's map of Connect and dotcom/future arc outputs.
|
|
I think the individual things above make sense in general... ... EXCEPT to clarify I think "raw code" is not src files, because those assets aren't really separable for each embed. So I'm suggesting we push a separate edition to Connect which is just src code for clients who want to customize any part of the graphic project all the way down (including translating it) with clear instructions on how to customize paths and publish to their own servers. Then I'm suggesting we group the "flats" and "interactive" embeds as above in a single edition so if a client buys any chart they get all of:
... which looks like this in RNGS: I am suggesting we cutoff the route for folks who did weird things like customize the minified JS and CSS files. As we get into code-splitting (we basically already have...) that kind of editing of built files becomes impossible. ALSO worth being upfront about this: Because JS and CSS assets are referenced using root paths (ie, |
|
Also, Matt mentioned that what was missing from my editions mockup above was a full page embed. ... Kinda want to talk about how many clients actually embed that full page. If we start focusing on embeds that are parts of pages -- which to my mind seems more useful to a client, but maybe I'm wrong?? -- then we have a lot freer hand to design pages with more crazy parallax or whatever without needing to unwind it all for a page our clients would prefer was broken out in parts anyway. BUT nothing I'm suggesting cuts off our path to continuing to publish that full embed. It's just another embed! |
|
Just to convey my understanding of terminology w/r/t RNGS...
|
|
First agreed draft of pack structure:
|
|
This structure is now built using reuters-graphics/graphics-kit-publisher. |
|
Note, released a version of the publisher-kit that now packages media archives with an So now media archives will go up with editions like this: |
Imagine a project that has a single page for graphics.reuters.com and two embeds published in two locales.
RNGS archives/editions
Here's a minimal example of the edition structure:
public archive
All publicly hosted files go into a single archive,
public.zip.The archive only includes HTML documents. All page assets -- js, css, imgs -- are published to a separate CDN. That lets us absolutely reference them for easier self-hosting without needing to re-route relative src paths when the folder structure changes in the embeds.
media archives
_gfxpreview.pngis a screen-grab of the embeddable graphic, generated during the publish process.README.txtincludes the pym.js embed code referencing the page published in thepublic.zip/interactivearchive.host/index.htmlis a duplication of the HTML document for the embed published in thepublic.zip/interactivearchive.code archive
_gfxpreview.pngis the page's share card.app.zipis the git archive of the entire development project.README.txtincludes instructions on how to start up the development server, customise src files and build adist/directory that can be uploaded to client's servers.The text was updated successfully, but these errors were encountered: