Live Preview and Live Collaboration - Writing Text vs Scripting

General
,
1

Hey all!
I have been using Typst for close to two years now, and I love the control I get over a document. As such, whenever there is an opportunity to use Typst in a group setting, I push my friends/peers to give it a shot. Together, we have written group lab reports, memos, conference papers, and even posters within the Typst WebApp. Throughout all these experiences, I keep hitting a major paint point: disrupted live-previews.

When multiple users are simultaneously editing a project, the preview becomes unreliable. Often someone is making adjustments to styling or scripting a function that ends up generating a series of errors (missing arguments, delimiters, etc.), in turn pausing the preview. While this is less of an issue while writing text, this can become especially frustrating while adjusting styling for formatting that cannot be fully realized by looking solely at the source. This forces users to constantly switch mental contexts, imagining how their code changes will appear without immediate visual confirmation, slowing the design process and increasing the chance of errors.

Admittedly, this behavior is an inherent limitation of how computers process code and a major contributor to the software industry’s use of primarily asynchronous collaborative solutions like Git. Conversely, Typst advertises itself as document writing tool, and as such is subject to the same live-editing standards as tools like Google Docs. The live editing is there, but the second the live-preview is lost, the illusion is broken. Users looking at the preview become confused why their text editor is no longer working, only to drag their eyes to across the editor and realize the document is simply no longer compiling.

I recognize there are no easy solutions to this issue, which, by its nature, is primarily perceived as a problem when measured against the standards of traditional writing tools. One might be tempted to suggest evaluating only text when errors are present, but I recognize implementing such a feature would be largely time consuming, if even possible.

One work around is to separate your content into unique .typ files that you then #include in main.typ. While users then have the option to view their sections in isolation, you lose the ability to see the content in context and with the proper formatting/styling (assuming you are only applying styling in main.typ).

Perhaps then the only reasonable system-side solution is to change the way that we as users interact with the preview and editing windows to encourage users to pay more attention to the editing window instead of the preview, or better alerting the user when the document is no longer compiling.

I’m curious to hear if others have experienced similar frustrations with live-preview and/or other challenges during collaborative sessions. Please share your thoughts and any workarounds you’ve discovered below!

1 Like
2

i guess this is more of a general issue in how the compiler works, rather than in live sharing in particular. i can definitely relate to making a minor typo or only-temporarily-invalid change and having the live preview jarringly stop updating.

the way to “fix” this UX gap would be to implement error recovery. that is, make it so that some errors can be recovered from, thereby allowing compilation to finish like normal (if imperfectly), much like warnings.

right now i can come up with one example of easily recoverable errors: unexpected argument, where the argument may simply be ignored. but there’re a lot more that can’t be trivially recovered from! one general reason for this is that an “improper” recovery may trickle down to other areas and cause a bunch of other errors (which obviously shouldn’t be reported to the user!) that may result in an ultimately useless output.

but then it’s a question of:

  1. whether the slightly better UX is worth the quite high implementational complexity imposed on the compiler, and
  2. whether it’s at all a good idea to let a user build a document that has an arbitrary number of “fundamental” flaws that, when ignored, may lead the user to believe that the problem lies with typst itself. i guess it would be reasonable to only allow 1 recovered error per compilation (but then refer to point 1!), to make exporting more difficult, etc.