Skip to main content

Developing for read-only

Related links:

When a preso is in read-only mode, preso page functionality becomes limited, updates to the preso are no longer captured, and saves to the context are prevented in the app and on the server.

image

Read-only mode is activated in the following circumstances:

  • A user is viewing a preso that doesn't belong to them
  • Your client's instance is using the no_snapshot_create_after flag, which toggles read-only mode after a predetermined amount following the preso's end date
  • Preso has been locked by the app

If content is not developed with a consideration to read-only mode, slides will continue to appear editable (interactive elements visible, DOM updates etc.), however the user will return to find all of their changes have reverted as the slide re-fetches data from the locked context. To avoid the inevitable user frustration and confusion, content should be developed in way that prevents a slide from appearing editable when in read-only mode.

note

In most cases, you will want the same functionality applied to read-only mode as review mode. If this is the case, you can save quite a bit of development time by grouping the modes together when developing your logic and styles.

Read on for several use-cases where separate builds are required.

Detecting read-only mode​

When a preso is in read-only mode, the class preso-readonly is added to the body element of the LivePreso app.

<body class="preso-readonly">
	<!-- LivePreso -->
</body>

This can be used by the deck's CSS for basic style changes (eg. hide interactive elements, flatten buttons etc.), or by JS to test which slide elements to render (eg. interactive vs. static) or provide alternate functionality.

Referencing in SCSS:

#slideshow article#slide_id {
  .preso-readonly & {
    <!-- classes to apply when slide viewed in read-only mode -->
  }
}

Referencing with JS:

const $slideArticle = Bridge.Slides.getArticle();

$slideArticle.on("slideready", function () {
	if ($("body").hasClass("preso-readonly")) {
		// Functionality when slide viewed in read-only mode
	} else {
		// Functionality when NOT viewed in read-only mode
	}
});

Use-case examples​

As mentioned earlier, for the majority of use-cases you will be able to barrel review and read-only mode logic together. However, there are some use-cases where you will need separate logic across the modes. Here are several examples:

Handover of a preso with editability in all presentation modes​

This example features a preso that is editable in all presentation modes (prep, present and review), an initial user will prep the preso before handing it over to a colleague to finish and present.

The scenario:

John creates and preps the preso before handing it over to Louise to finalise and present.

The preso contains several questionnaires that are customised by John when he is prepping the preso. Louise will then populate the answers with her client during the presentation. These questionnaires can be revisited in review mode to update details that the client may not have had on them at the time of the presentation.

Build it:

Separate logic is required for the prep, present, review and read-only modes of this preso.

  • Prep mode: Questionnaires are customised, answers cannot be populated
  • Present and review modes: Questionnaire answers can be populated on the master side
  • Read-only mode: No changes can be made to questionnaire customisations or answers

Editable preso locked after presentation completion (custom instance setting)​

An example use-case where review mode edits are allowed for 24 hours following the preso end date, after which the preso is locked down to preserve the final state for future reviews.

info

Locking a preso after a predetermined time period is a custom instance-level setting. Other use-cases may allow for longer or shorter time periods, or not lock the preso at all (default setting).

The scenario:

Jane makes a preso, preps then presents the next day. After her presentation is finished, she re-visits the preso in review mode to make a few copy tweaks before sharing an online copy with her client.

24 hours after the preso end date Jane's preso becomes locked. She reviews the preso again to collect data for her follow-up report but can make no further changes to the preso.

Build it:

This scenario requires separate styles and logic for the review and read-only modes.

  • Prep, present and review modes: Input fields are editable on the master side
  • Read-only mode: All input fields are replaced with static <p> elements and a message is displayed on the welcome slide informing the viewer of the date and time of their final edits