Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Svedit on mobile? (did a testrun on Android) #16

Open
michael opened this issue Oct 24, 2024 · 2 comments
Open

Svedit on mobile? (did a testrun on Android) #16

michael opened this issue Oct 24, 2024 · 2 comments

Comments

@michael
Copy link
Owner

michael commented Oct 24, 2024

TL;DR: We have a long way to go; Chromeless content editing on mobile is really hard to do.

BUT: Quite a few things work nicely already. And I think it's worth exploring this territory.

  • Block selection markers (using CSS Anchor Positioning) feel quite nice and unobtrusive
  • Text editing and copy and pasting of text feels nice
  • It feels actually quite intuitive to select a block using text selection spanning over multiple text properties. Clicking backspace to delete that node, too.
  • Pressing ENTER when there's a container cursor as well feels natural.

Some issues:

  • Not possible to explicitly set container cursors atm (without using backspace). We'd need arrow keys to navigate. Wouldn't introduce a dedicated click area for cursors, as we have no way to communicate that (unlike on desktop where we can outline the cursor on hover).
  • Cursor does not always scroll into view as it should (maybe we need to add some extra offsets)

Considerations:

  • I think we should try to keep the keyboard always open for any active DOM selection). Ideally we could move the whole operations (delete, move up/down etc) to a custom soft keyboard. Then you only place a cursor on the canvas and all manipulations happen within the soft keyboard, which has a much more native feel than some tools floating around everywhere. We'd also solve the "toolbar above the keyboard" positioning problem by just not rendering a toolbar on the page.
  • The more vertical space blocks take the harder it is to edit on mobile. E.g. currently we show the image atop title + description. So it will be hard to intuitively select multiple blocks because you need to "break through" the screen boundary with your selection.

PS: There's hope that Blink comes to Safari, which could really help us here: https://9to5mac.com/2024/10/23/ios-18-2-web-apps-browser-engine-in-the-eu/

@johannesmutter
Copy link
Collaborator

I think we should try to keep the keyboard always open for any active DOM selection (…) not rendering a toolbar on the page.

Do you mean the native QWERTY keyboard?
I think this should only be open when you want to insert/edit text, as it takes away too much screen.

intuitively select multiple blocks on mobile

Craft has solved this quite nicely: swipe from the right edge to left to open the "multi select mode". Now little circles appear next to each block, tab multiple of these circles to make a selection.

RPReplay_Final1730234132.mov

@michael
Copy link
Owner Author

michael commented Oct 29, 2024

For context: The overall idea of our current "Svedit approach" is to always drive the editor by a native DOMSelection. On the native browser level, these are all text selections, but some of them (when spanning over multiple blocks) are mapped to "container selections" in our internal model.

Assume someone makes the following selection on mobile:
image

The text selections starts at "You only..." and ends at "...lines of code" in the next block. Basically you first have the cursor before the "You" callapsed. The soft keyboard is visible now, because you are in a text selection. Next you expand the selection by dragging the text handle and move it further down. During this drag there's an implicit transition from a text selection as soon as you cross field or block boundaries. I don't want to interfere with what the browser does here, so hiding the soft keyboard during making a text selection would turn into a flickery experience. That's why I thought we maybe should keep the keyboard open all the time. Basically creating an experience similiar to Apple Notes on iOS. The keyboard is always open there and the contextual tools are shown right above the soft keyboard.

The Craft-UI uses a completely different approach tailored for mobile (with special click and drag handlers that have nothing to do with native DOM selections in a browser). It's possible that we'll fail on mobile with our native selection approach, and then we are forced to somehow create two different editor experiences (one for desktop and one for mobile), but I'd first like to find out how far we can come with the pure DOM selection approach.

Because we get so many things for free:

  • automatic scroll into view on undo/redo, no switching between modes
  • 2 way mapping model-selection to dom-selection and vice versa. We'd lose that with any custom UI we'd come up with. E.g. if we enter some block mode like in Craft, we would destroy the DOM selection every time we click on a selection handle)
  • natural usage of the enter/backspace keys (e.g. select something with native DOM selection and hit backspace to delete it, no matter if its just text or a range of blocks)
  • completely chromeless
  • closest experience to a text editor with only cursors and selections and a keyboard.

TL;DR: This is a very difficult problem we want to crack here, so I really don't know how far we'll get how fast, but i'm really keen to try create a mobile editing experience based on native DOM selections.

PS: I understand now that we can't customize the soft keyboard (and add arrow keys for instance), so we need to render all contextual tools above the keyboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants