Restricted editing

[Reinmar]

📝 Provide a description of the new feature

This enhancement would allow to run the editor in two editing modes:

• standard mode,
• restricted mode.

The feature would allow to mark editor's content part as an editable part (see Marking as editable part).

Editing mode can changed at a runtime, via an API call. by configuring the editor. The modes should be operated by different users so there is no need to switch it in the same editor.

UC: Marking as editable part

Marking any part as editable should be possible only while in standard mode and it should be doable using a button. Below is an example UC:

1. Select a part of paragraph.
2. Click the "Enable editing" button.

✔️ Expected result

• Selected part is marked as editable in the restricted mode.
• Selected part gets additional styling indicating that it's editable in the restricted mode, let's make it a yellow background with some subtle outline that would differentiate it from yellow text background.

UC: Editable part toggling

1. Select a part that is already editable in the restricted mode (denoted by yellow highlight).
2. Click the "Enable editing" button.

✔️ Expected result

• Selected part is no longer marked as editable in the restricted mode.
• Visual marker is gone.

📃 Other details

I intentionally didn't use full editing mode as it might bring up some historical connotations with our lovely full package 🙂

---

Restricted editing mode enhancements (part III - follow-up PRs)

• names of plugins, commands, etc
• review approach of enabling commands - maybe better would be using schema - would be better with clipboard - one configuration).

Follow ups:

• placeholders of editable fields Placeholders for non-restricted areas in restricted editing mode #5804
• enable clipboard: Enable copy & paste in restricted editing mode #5802

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.

[dkonopka]

Icon

Two proposals here, I prefer the first one, but it might be confusing for the user because eg. restricted editable won't work for blocks of paragraphs.

Dropdown proposal

During the research of restricted editing in the Microsoft Word, I have found a decent improvement of this feature: moving between editables. Maybe it's worth to consider it after MVP implementation.

Highlight color

Word is using light yellow color for their restricted editables and it could work for us too, but we have comments feature with a comparable color. So I would propose something similar - orangish. In comparison, I'm adding here a "blue mockup" also.

Orangish

Bluish

Highlight style

It was a kinda tricky thing because I have been there during research on track-changes / comments & user selection features. To sum up, I'm recommending to mark editable areas similar to the highlight plugin way, but also Microsoft Word solution ( [ ] brackets) might work out too and it looks pretty nice inside editor instance.

Bordered highlight (looks buggy)

Brackets highlight (Word solution)

Brackets solution mockuped on live editor instance:

[jodator]

To track the progress of the feature I've added a detailed list with things to do in this task - not that the list may change.

[jodator]

After implementing plugins for the "standard" mode - in which content creators will mark parts of the content as "exceptions" in the "restricted" mode - I'm not sure if we should focus on "opening" parts of text rather then "locking".

As for now, I think that the button shouldn't be named "Restricted Edting" and maybe it's UI should be focused on the "opening" (adding exceptions) to the parts of texts.

In the draft PR I've renamed this part of the RestrictedEditing feature to RestrictedEditingException (the name is still open to change of course).

[Reinmar]

Notes from the call about the UI:

---

Standard mode

• Which icon?
  • When on normal text: [unlocked lock], "Enable editing" title
  • When on exception: [unlocked lock] "Disable editing" title
  • Should icon show the state or the action of the button?
    • Answer: the icon should reflect what the "on" state of that button is.
• Highlight styling
  • color
    • follow MS?
      • collides with our comments
    • orange seems fine
  • start/end markers – 👍
    • [foo]
    • positioned :after/:before content:'[/]'
      • slightly unsafe - because it's a selectable content
    • positioned :after/:before with some borders to pretend [/] characters - should be safer
      • will solve the empty element case - it will always be visible
      • such brackets are not selectable - which is good

Restricted mode

• Dropdown?
  • Easier navigation between editable regions
  • Fine for MVP
  • Should show keyboard shortcuts
  • Future: Balloon with next/prev like in a11ychecker
    • Problem: conflict with link and other balloons
  • Label: "Previous/next editable region"
  • Icon: as proposed – lock next to a text
• How will brackets work here?
  • If we'll choose the :after/before + borders, then it's completely transparent
• Styling when inside a certain editable region
  • Non-MVP: Opacity for non-editable text?
    • Is it technically possible?
    • It seems so - we should be able to easily wrap all non-editable text and blocks with some spans
  • Hover style
    • When outside: cursor:pointer?
    • When hover: cursor:text?
    • No decisions so far – let's test it live
  • Selection inside style
    • No decisions so far – let's test it live
• Conclusion: We'll refine those styles when we'll be able to see this live.