Storytelling tool: decoupling editing and viewing stories

Cindy Li cli at ocadu.ca
Thu Aug 6 14:11:47 UTC 2020


Hi Justin,

> I think it would only be published changes that triggered the redeploy. 

I agree the redeploy should only be triggered by publish clicks.

> Regarding the redeploy, I wonder if we can update the deployed site with only the changes, so that the entire site doesn’t have to be rebuilt.

Using incremental builds is a good idea. WeCount site uses Eleventy to build the static site, which doesn’t support incremental builds for now but it does have an open in-progress project  <https://github.com/orgs/11ty/projects/3>for it. There might be other static site generators that already support incremental builds.

In terms of the workflow for the WeCount site, WeCount has 2 backend APIs serving data: one is the WordPress site where WeCount team members create news, views and some site pages; the other is Airtable that serves WeCount workshop information, user comments for workshops, AI resources and tools data.

For the WordPress backend, any save to pages and posts will trigger the WeCount static site to redeploy.

For the Airtable backend, the work to support it is in progress. The plan is, adding new records to the “Workshops” table, or marking user comments, AI resources and tools data as “reviewed” will trigger the static site to redeploy.

People who manage these backend data are WeCount team members, not the public, so there’s a smaller chance to have large swamped updates at one shot. From my experience, the time taken from updating a wordPress backend page to this change being reflected on the static site needs a couple of minutes. When Eleventy supports incremental builds, hopefully this time would be much shorter.

As story telling tool is an authoring tool facing the public, the user experience is more important comparing to the WeCount site. Understanding:

1. The time taken between a user clicking the publish button until the user can view the published story on the browse page;
2. How will this lagging impact the user experience;

are important.

Thanks.

Cindy

> On Aug 5, 2020, at 3:25 PM, Justin Obara <obara.justin at gmail.com> wrote:
> 
> Hi Cindy,
> 
> Thanks for your feedback on this, and you definitely raise some good points. 
> 
> I wasn’t aware that auto save was happening on the server. I had thought it would be in the user’s local storage. In that case though, I think it would only be published changes that triggered the redeploy. 
> 
> Regarding the redeploy, I wonder if we can update the deployed site with only the changes, so that the entire site doesn’t have to be rebuilt. However, we should be able to debounce the site redeploy, so that multiple incoming changes will be packaged together. In general, we’ll probably want some mechanism for telling the storytelling tool that the publishing has actually completed and that the story is available to view. Not sure how difficult all that will be.
> 
> We could also look at ways of having editable sites be dynamic and readonly sites be static. However, it might be harder to maintain like that. I’m not sure.
> 
> Cindy, could you explain a bit about the workflow for the WeCount site? That might give us some more ideas about how a potential setup might look and also some issues we may run into.
> 
> Thanks
> Justin
> 
>> On Aug 5, 2020, at 1:34 PM, Cindy Li <cli at ocadu.ca <mailto:cli at ocadu.ca>> wrote:
>> 
>> Hi Justin,
>> 
>> I think using static websites for archived storytelling websites is a great idea.
>> 
>> However, for the site that editing can be enabled, since each save to the database will trigger a re-deploy of the static site, we might like to understand and clarify some questions before making a decision:
>> 
>> 1. The usage of the editing tool: how are stories created? Are they usually created in workshops with a number of people editing/creating stories simultaneously, or the usage is spread over time?
>> 2. How fast the static viewing part can be deployed?
>> 3. Would swamped saves to the database mess up the deploy of the static part?
>> 
>> Moreover, with the implementation of server side auto save <https://issues.fluidproject.org/browse/SJRK-289> for uploaded medias/files, creating/editing a story could lead to multiple saves to the database rather than at the publish step.
>> 
>> Cindy
>> 
>>> On Aug 5, 2020, at 7:58 AM, Justin Obara <obara.justin at gmail.com <mailto:obara.justin at gmail.com>> wrote:
>>> 
>>> Hi Gregor and Dana,
>>> 
>>> I was reading over the Branches <https://github.com/fluid-project/sjrk-story-telling/blob/master/docs/BRANCHES.md> doc for Storytelling this morning and also reflecting on the testing work that was needed following the 0.3.0 release last week. If I’m understanding things correctly, only the AIHEC <https://aihec.inclusivedesign.ca/> (currently in production use) and staging <https://staging-stories.floeproject.org/> sites allow for authoring stories. During the “Storytelling Tool long-term technical road map discussion <https://docs.google.com/document/d/1Y7nXxUeCt9qcLQbjYoblzsrKLKpeLA2H6kFyu-EsIl4/edit#heading=h.wn80pjfkqwr2>” we spoke about the possibility of integrating with a SSG like 11ty <https://www.11ty.dev/>. I don’t think I fully grasped, and may still not, the distinction between the authoring of stories and viewing stories on the site. At the moment it appears that these are coupled together into a single system which can be set to enable story authoring/editing. In the case where editing is disabled there is still a server and database backing the browsing/viewing of stories.
>>> 
>>> If our end goal is to decouple the authoring/editing from the story viewing/browsing, we should revisit this along with the login and authentication. It will probably depend on how things are actually implemented so I’ll just illustrate one possible scenario below. We should consider how we actually want this to work, what the benefits and tradeoffs are, and etc.
>>> 
>>> Possibile scenario:
>>> 
>>> The deployed story site is always a static site. When a story is authored/edited, the server triggers the site to redeploy at which point the static site is regenerated with the content stored in the database. When story authoring/editing is enabled, an instance of the storytelling tool is deployed alongside it. The storytelling tool being just an authoring interface which stores stories to the database. When login/authentication is provided, it will also provide a view into the users' stories for editing/deleting. When story authoring/editing is disabled we only deploy the static site; the storytelling tool does not need to be deployed. Additionally the backend database can be archived and disabled if the stories are intended for view only and are effectively archived.
>>> 
>>> Points of configuration between the systems would include configuration for the SSG to enable/disable the link to the storytelling tool, linking from the storytelling tool to the published story on the static site, and styling for preview in the storytelling tool to match the output in the static site. 
>>> 
>>> Please let me know what you think and if I’m misunderstanding anything.
>>> 
>>> Thanks
>>> Justin
>>> 
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca <mailto:fluid-work at lists.idrc.ocad.ca>
>>> To unsubscribe, change settings or access archives,
>>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work <https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20200806/744fa7c7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1487 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20200806/744fa7c7/attachment.p7s>


More information about the fluid-work mailing list