UX problems with Lessons comments tool & CKEditor autosave
GENERAL
TESTING
GENERAL
TESTING
Description
Activity
Show:

Sean Horner July 20, 2021 at 11:18 AM
For what it's worth, given the (unique?) way that CKEditor is hidden after being loaded for the comments tool, the stop-gap approach my institution is taking is to disable autosave for the comments tool in Lessons pages. (We nevertheless have autosave working for editing rich-text items-- i.e., created via 'Add Text'.)
The mechanism I'm using to disable autosave for this specific use case entails modifying the autosave plugin code, which I'm resorting to anyway in order to address SAK-45824.
Details
Details
Priority
Affects versions
Components
Assignee

Reporter

Created July 20, 2021 at 10:53 AM
Updated July 26, 2021 at 1:23 PM
The vast majority of views in Sakai that load the CKEditor have this editor displayed and ready to use by the time the page is fully loaded. The comments tool feature in Lessons differs (perhaps uniquely) in that the CKEditor is first loaded and then hidden before the page is fully loaded. This behavior clashes with assumptions behind how the auto-save plugin for the CKEditor behaves, particularly when alerting users that auto-saved content for a Lessons comment differs from content loaded from Sakai. An incident of this is demonstrated in “Test A” in the Test Plan.
Another issue pertains to the different URLs expressed for a Lessons subpage when a user navigates to that subpage in different ways. The CKEditor autosave plugin currently uses the full URL for constructing a unique SaveKey for storing autosaved content. Consequently, even if the problem demonstrated in Test A is resolved, if a user has auto-saved content for the Comments tool within a subpage but later accesses the subpage in a different way than how the subpage was originally accessed when the comment in question was auto-saved, that auto-saved content will not be detected. An incident of this is demonstrated in “Test B” in the Test Plan.