UX focused prototype idea for non-technical text-based page edits

Apologies in advance @jeanduplessis & @ericschurter regarding proper issue format and/or labeling. In Meltano we don't do it exactly the same way as GitLab. Anyway, I'm curious of your thoughts about the idea below.

---

Something like this may already be proposed in an issue, but I have a prototype idea that's optimized from a UX ease-of-editing perspective. This is based on the assumption of a UX adhering to this user's internal monologue:

1. I just want to click some text and start editing
2. When I'm done I just want to hit "Save" or "Cancel/Abort" to confirm the change(s)
   • I don't care about git at all but recognize the value of tracking changes over time... so I'll add a quick change description
   • Thank you by, I can move on with my day.

Now here is a more detailed set of notes describing an approach to pull this off:

1. I just want to click the specific piece of text I want to edit for the page I'm on
   • I don't want to have to scroll to the bottom (or anywhere) and click "Edit this Page" as I know exactly where I want to start my edits
2. Though a half-baked idea (poor for UX discovery), I can right-click the specific text to edit (or we'd have some CTA that in fact got you to this point), and select "Edit page"
   • Custom item in the browser's context menu saying "Edit page" that's ideally adorned with the Tanuki logo (menu item style like 1password in the image below vs. just plain and boring text)
   • With event listeners pre-wired in the page we get:
     • The exact <h1>, <p>, etc. node clicked/tapped on
       • This node has a data-gitlab-editable-{{id}} (or similar) attr where we have a mapping of each of these attrs to each markdown node. This is the magic hook to enable WYSIWYG editing we can then reliably sync to a commit
     • Where we may additionally be able to tap into the user's preselected text to then preselect it in the edit mode (small UX win). This actually may happen automatically based on the browser.
   • The exact position in the document from which to spawn a spatially aware modal/popover (exact position: absolute value derived)
     • This is likely just a mini login form when not signed in, otherwise skip to step 3.
       • I have animation ideas of morphing this modal and placing it unobtrusively in the corner of the browser frame where during transition its contents also become the aforementioned "Save" or "Cancel/Abort" buttons
3. I can just start editing text. Due to the aforementioned click event we know which node to dynamically set contenteditable on. We would likely do this on all or a subset of nodes as opposed to just this one, but one node is an MVC.
4. Once I feel done with my edits I simply click "Save" or "Cancel/Abort" of the aforementioned animated menu. I know where it is as it visually spawned and animated from the exact click location of where I wanted to edit in the first place!
5. We now have confirmation the user is done. Once "Save" is clicked/tapped the hovering modal again morphs to display a pre-filled/selected commit message input (UX progressive disclosure principle). We leverage the data-gitlab-editable-{{id}}(s), parse the new contents, change diff from the old, and replace the corresponding markdown node. Update committed and thus tracked.

There are likely hidden challenges to this, but technically speaking I think this is very doable where the UX drives the implementation.