Page MenuHomePhabricator

VE mobile second iteration
OpenPublic

Authored By
Nirzar, Oct 6 2015
Tags
None
Referenced Files
F2660999: Keyboard-normal-editing.png
Oct 6 2015, 12:50 AM
F2660998: citation panel.png
Oct 6 2015, 12:50 AM
F2660993: format panel.png
Oct 6 2015, 12:50 AM
F2660996: keyboard up link.png
Oct 6 2015, 12:50 AM
F2660997: link panel.png
Oct 6 2015, 12:50 AM
F2661000: keyboard up- edited-undo.png
Oct 6 2015, 12:50 AM
Subscribers

Mock History

Current Revision

Event Timeline

Having a native selection causes the keyboard to be open. The only way to close it is to destroy the native selection. We do have a fake selection mode that just draws the blue box and would allow us to close the keyboard. We could trigger this when the use clicks on the format tool, but they wouldn't be able to modify the selection as the handles would disappear.

@Esanders yeah that is one restriction and I think the proposed workaround will work. modifying the selection would not be possible but if the user tries to select (tap & hold) the styling panel will go and keyboard will pop. is that right?

How do you envisage the usability of clicking on a link, specifically in slide 4? Normally clicking on a link would open the keyboard.

(@Nirzar Placing the selection back in the document would automatically re-open the keyboard, if that is what you are asking. Basically while the user is creating/editing a selection the keyboard has to be open. I think this is unavoidable. If they take some other action (e.g. click the toolbar) we can switch over to a fake selection to get rid of the keyboard.)

as a note: Keyboard is already open and then you click on the link.

"Viewing the link + editing link text at the same time" with the kind of space that is available is where the experience suffers drastically.

Following the simple rule of "one thing at a time" we show the link panel to inspect the link first and then keyboard pop button will enable you to edit the link text (slide5)

(@Nirzar Placing the selection back in the document would automatically re-open the keyboard, if that is what you are asking. Basically while the user is creating/editing a selection the keyboard has to be open. I think this is unavoidable. If they take some other action (e.g. click the toolbar) we can switch over to a fake selection to get rid of the keyboard.)

That sounds good :)

Also I like the idea of collapsing infoboxes, however we will to come up with a rule for that, as as far as we are concerned templates are all the same. We certainly wouldn't want to collapse inline templates, for example.

@Esanders yes. collapsing infobox would make the first scroll experience for the editor really great. I agree we can't collapse the in-line templates, is there another way to figure out inline templates?