Storytelling tool: decoupling editing and viewing stories

Justin Obara obara.justin at gmail.com
Wed Aug 5 19:25:32 UTC 2020


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> 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/20200805/bb867e45/attachment.html>


More information about the fluid-work mailing list