[DEPR]: Legacy Text Editor

[KristinAoki]

Proposal Date

2024-05-03

Target Ticket Acceptance Date

2024-05-17

Earliest Open edX Named Release Without This Functionality

~Sumac - 2024-10~

Teak - 2025-04

See discussion below -- we have delayed the removal to allow time for improvements to the replacement editor.

Rationale

The EditImageModal component that is used it the legacy Text Editor is also set for deprecation and removal. To prevent errors and regression while using the legacy Text Editor, it is best to remove it completely from the platform. The legacy Text Editor already has replacement that can be toggled with new_core_editors.use_new_text_editor and will be come the default once this deprecation occurs.

Removal

1. Remove toggle for switching between editors
2. Remove dependency on toggle for text editor redirect and make it always true
3. Remove dependencies on toggles when fetching the course authoring mfe url

Replacement

This code is being replaced by the frontend-lib-content-components/TextEditor. This text editor is a React based component and is rendered in the Course Authoring MFE.

Deprecation

No response

Migration

No response

Additional Info

No response

Task List

No response

[felipemontoya]

The removal of the ENABLE_NEW_TEXT_EDITOR_FLAG was done at the frontend in this PR https://github.com/openedx/frontend-app-course-authoring/pull/951. This happened due to a bug before the redwood cut.

[kdmccormick]

If you're watching the issue, then FYI there is some conversation about StudioEditableXBlockMixin going on in the related forum thread: https://discuss.openedx.org/t/deprecation-removal-text-editor-in-edx-platform-34692

[kdmccormick]

Based on the forum discussion, it looks like there are no blockers to removing this. @KristinAoki are we ready to move this to Accepted?

[kdmccormick]

@jristau1984 @robrap Technically the 6-month grace period for this would end Nov 17th. IIRC, the new text editor is already fulled rolled out on edX.org and Edge. Given that, do you have any opposition to waiving the rest of the grace period and making this available for removal?

@pdpinch , same question for you-- Would you have any opposition to the legacy Text component (ie, HTMLBlock) editor being removed on the master branch of edx-platform at this point?

Two notes:

• This deprecation is just for the old HTMLBlock editor. The base tinyMCE editor, which is used in a couple other parts of edx-platform, would remain supported.
• This deprecation would unblock the removal of the old studio-frontend repository, which is 90% unused and may be a burden in the Node 20 upgrade if we can't remove it before Sumac.

[jristau1984]

@kdmccormick I believe the legacy edtior is still avilable through the container page (directly navigable, and available thru the library block experience?), so removing it would have side effects.

[kdmccormick]

@jristau1984 Both in a Tutor environment and in edX Stage, I made a library with a text component, and then referenced that library in a course. When I entered the library_container view and edited the text component, it fired up the new editor for me: https://studio.stage.edx.org/container/block-v1:edx+tmccormack-test+1+type@library_content+block@997ed8d15d0144c9895ce87f6140ec9b#block-v1:edx+tmccormack-test+1+type@html+block@e53730f804cc4bd2205f

[robrap]

@jristau1984: Could we use observability to confirm if we have any usage of the deprecated code?

[jristau1984]

@robrap I think we could, I just dont know if people go there. I know that the Partner Support has used the container page as a workaround sometimes, but I dont know the frequency (especially recently).

[kdmccormick]

@jristau1984 We certainly need to keep the container page working, but my testing so far is showing that the container page has already been upgraded to use the new editor.

@robrap Observability-wise, you could check for any usages of the legacy text editor by looking for invocations of the HTMLBlock's studio_view, which is a GET to URLs of the form: https://<CMS_BASE>/xblock/block-v1:<ORG>+<COURSE>+<RUN>+type@html@<BLOCK_ID>/studio_view. Is that feasible with your tools? If not, we could instead check for invocations of the studio_view definition; is an edx_monitoring_utils custom attribute the way to go there?

[jristau1984]

@kdmccormick I see 12 instances of loading that URL over the past month in our Prod and Edge envs. I am tracking down the use cases now, but this tells me that while it is very much reduced it is not completely inaccessible.

[KristinAoki]

@kdmccormick I looked into the use cases for Jeremy. It appears that the legacy editor is not being used on the container page. The instances that are seeing in our Prod and Edge envs were not coming from the legacy editor actually loading, but instead from the API being called in the loading of the new editors. However, the frontend-lib-content-components PR #484 remove them need to call studio_view for all the new editors. The endpoint is now only used by the video editor because it is the only place to fetch the current transcripts associated with a block and the license details. That metadata is not stored with the other xblock metadata for some odd reason. The endpoint was previously also used for the text editor to determine if the editor was supposed to open in the raw or visual editor. However, some time between the creation of the text editor and today, the attribute is_raw was added to the metadata for the xblock. Therefore, the studio_view endpoint is no longer needs to be called and parsed to determine if the raw editor should be opened.

[pdpinch]

@pdpinch, same question for you-- Would you have any opposition to the legacy Text component (ie, HTMLBlock) editor being removed on the master branch of edx-platform at this point?

MIT course authors have significant UX issues with the new content editors. I had thought they were being addressed by 2U, but now I have my doubts. I'd like to understand the plan better before giving a 👍 to removing the legacy UI.

[cablaa77]

@pdpinch could you be more specific about the UX issues? Or if you wanted to address this privately through email that would be much appreciated. I believe I have your email and will send you a quick note. Thanks.

[pdpinch]

I may be confused about the scope of this deprecation.

The legacy Text Editor already has replacement that can be toggled with new_core_editors.use_new_text_editor and will be come the default once this deprecation occurs.

Does this mean that this UX will no longer be available:

and this will become the only text editor UX:

If this only affects the EditImageModal component but the modal text editor is still available, I have no objection.

[kdmccormick]

@pdpinch You weren't confused, the scope of the deprecation is the entire legacy text editor (aka, the modal HTMLBlock editor). Your screenshots are correct.

The EditImageModal part is relevant because it is what is blocking is from archiving studio-frontend, however, there is a general desire to coalesce around the MFE editors soon so that all of Studio can run in an MFE.

I'm also very interested in hearing your UX feedback!

[feanil]

MIT course authors have significant UX issues with the new content editors. I had thought they were being addressed by 2U, but now I have my doubts. I'd like to understand the plan better before giving a 👍 to removing the legacy UI.

@pdpinch can you provide more info, we don't want to be in a state of having 2 editors forever so we need to make a plan to unify this. If there are tangible improvements we need to plan for, we should get the requirements in front of the Product WG ASAP.

[SIdnani]

@pdpinch asked me to comment on the specific problems we at the xPRO Product development Group have with these MFE Editors.

During the our update cycle to Quince last December I, the xPRO Educational Technologist, proposed moving to the new MFE editors universally to the Course Development Product Group here with MIT xPRO. We trialed the editors in our test deployment area. The Product Group responded extremely and strongly negatively to the new editors. Feedback from the Instructional Design and Course Product Management Groups including Instructional Designers, Learner Success, and Subject Matter Experts (Faculty & Content Developers) was documented in the Google Form linked within the Editors themselves.

Summing up General Feedback:

1. All MFE editors remove the content being created or edited from the context of the content it sits within. For example, if the text block sits after a video and an assessment item, I can't scroll back up or down to see what other content is available in the unit. I would be forced to choose between closing the editor and "losing" my work or "saving" my work and then finding out that it isn't within the context as I originally intended. Thus increasing working cognitive load in a negative a detrimental way as the folks who build content are forced to remember the potentially dozens of items on a given page. Tasks like numbering assessment items on a unit containing a quiz using the Display Name become irritating at best and Sisyphean a the extremes as the number of items in a unit increases.
2. All MFE editors remove all the information available on the Unit page. For example, in the two text editors above, the Legacy "pop-up" editor contains important information like, what unit, subsection, section, and course the content being created or edited in. Legacy Editor also includes information like the location id, and publication status of the unit that you can just scroll to gather.
3. All MFE editors open in the same window/tab as the content being edited. I am navigated away from the course content, I am editing such that I cannot reference it. Note: From an Instructional Design perspective, removing learners from the course materials by forcing them to navigate away from the courseware will result in learner loss. The same thing happens when someone has to edit a typo in a piece of content. The Legacy editor would display the content without your edits on the unit page next to the popup with the edits you made until you hit save.
4. Overall, it took someone between 2-10 times as long to build content in the new MFE editors vs. the Legacy editors. Building a basic assessment item, like a Multiple Choice Question, from content written elsewhere went from 30 seconds in Legacy to 3 minutes with the forms required in the MFE editor. Advanced Editors are also a couple of more clicks to access. Toggling back and forth between the Advanced and Basic editors required to preview and complete LaTeX content became more time consuming. (This is where we get into content taking 10 times or more to build.)
5. Multi-part assessment items are harder or impossible to implement depending on the type of basic assessment item that needs to be used.

Personally, whenever I have to show one of our SMEs these new editors I usually have to apologize for how much more time consuming the process is in comparison to the legacy editors. I've had better luck showing folks how to build content using either a mail merge and some spreadsheets or just how to navigate the export file and edit everything in XML in a text editor and zipping it back up again.

[kdmccormick]

@pdpinch @SIdnani , thank you for your detailed feedback!

As far as I can tell, there is nothing inherent in the implementation new text editor that would prevent us from making the improvements you propose (non-full-screen mode, open-in-new-tab support, fewer clicks for advanced workflows). So, it's a matter of getting this feedback in front of the Product Working Group and, assuming they are supportive, getting the improvements prioritized. @pdpinch mentioned he would be able to do start the conversation with Product WG.

We still need to remove the legacy text editor, but I think would be valuable to wait a release to give the project time to improve the new editors. I propose that we delay the removal of the old Text (HTML) editor until Teak, and aim to get these improvements landed before then.

There is also the question of the legacy Problem (CAPA) and Video editors, which each have their own MFE replacements. I know you have touched on Problem editor feedback as well, notably lack of visual multi-response editing support, and @pdpinch mentions that there is other feedback on the new editor as well. I will write separate DEPR tickets for both Problem and Video editors so we can collect feedback there.

[jmakowski1123]

Noting that we will take this feedback as guidance when writing the Library specs for Library support of unit authoring. Any changes/enhancements to the editors will carry over to the course editors as well. @pdpinch @SIdnani please feel free to follow along with those specs here: https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4434264072/Libraries+Support+Unit+Subsections+and+Sections

[pdpinch]

@jmakowski1123 I left some questions on https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4434264072/Libraries+Support+Unit+Subsections+and+Sections -- let me know if they make sense.