{"action":"created","issue":{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/149","repository_url":"https://api.github.com/repos/ckeditor/ckeditor5-design","labels_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/149/labels{/name}","comments_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/149/comments","events_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/149/events","html_url":"https://github.com/ckeditor/ckeditor5-design/issues/149","id":160677439,"number":149,"title":"UX: Mobile editing","user":{"login":"oleq","id":1099479,"avatar_url":"https://avatars.githubusercontent.com/u/1099479?v=3","gravatar_id":"","url":"https://api.github.com/users/oleq","html_url":"https://github.com/oleq","followers_url":"https://api.github.com/users/oleq/followers","following_url":"https://api.github.com/users/oleq/following{/other_user}","gists_url":"https://api.github.com/users/oleq/gists{/gist_id}","starred_url":"https://api.github.com/users/oleq/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/oleq/subscriptions","organizations_url":"https://api.github.com/users/oleq/orgs","repos_url":"https://api.github.com/users/oleq/repos","events_url":"https://api.github.com/users/oleq/events{/privacy}","received_events_url":"https://api.github.com/users/oleq/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/labels/question","name":"question","color":"cc317c"},{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/labels/UX","name":"UX","color":"000000"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-06-16T14:35:33Z","updated_at":"2016-06-16T14:53:12Z","closed_at":null,"body":"Unlike CKEditor 4, the new \"5\" must be mobile–friendly by providing dedicated interface and editing experience to the users.\r\n\r\n## Research\r\n\r\nThere are multiple factors to consider in this issue like screen size ([RWD](https://github.com/ckeditor/ckeditor5-design/issues/115)) or input method (touch vs. click), but most importantly, it's all about confronting the UX/UI ideas with technical limitations of the most popular mobile web browsers.\r\n\r\n**Note**: The following research involves Safari on iOS only so far.\r\n\r\n### Native Fullscreen API editing\r\n\r\nThe initial idea of mobile editing involved the usage of [Fullscreen API](https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API). Users would click the button (or some area) on the webpage to start editing and then the editor would show up in fullscreen mode, non–scalable with a toolbar on the top of the viewport. The editable area of the editor would be scrollable when content exceeds available screen height. \r\n\r\nThis solution solves UI/UX conflict between webpage and editable content – the editing experience is similar to a standalone (native) text processor application, undisturbed by floating webpage elements not related to the editing process.\r\n\r\n\r\n![image](https://cloud.githubusercontent.com/assets/1099479/16120183/f0721e5c-33de-11e6-9bc2-ffef7ae6b374.png)\r\n\r\n\r\nUnfortunately, the Fullscreen API is [unavailable in iOS Safari](http://caniuse.com/#feat=fullscreen) and [unlikely to be implemented](https://twitter.com/grorgwork/status/743147727588986881) in the nearest future. It's hard to tell why Apple falls short in this matter but it could be that a conflict of interests between fullscreen web pages and native App Store content might be the case. I could also be that since iOS devices come with a single hardware button (there's no direct \"back\" button), Apple is reluctant to enable Fullscreen API for all element due to UX concerns like fullscreen \"hijacking\", etc.\r\n\r\nIdeally, CKEditor 5 should use an universal mobile editing solution for each environment. Still, using Fullscreen API in Android devices (research needed), and mocking it in some way in iOS is also an option.\r\n\r\n### Fullscreen mocking and alternative interfaces\r\n\r\nBecause Fullscreen API is unavailable in mobile Safari, some mocks and alternative approaches have been researched. Samples can be found in [mobile-editing branch](https://github.com/ckeditor/ckeditor5-design/tree/mobile-editing).\r\n\r\n#### A quick note on viewport mechanics in mobile Safari (iOS 9+)\r\n\r\n(Mocked) Fullscreen WYSIWYG editing in mobile Safari is quite tricky because of the soft keyboard. \r\n\r\nAs long as the keyboard stays invisible (editable blurred), the whole area of the editor is available to the user. Editable can be scrolled to reveal more content off the screen (green scrollbar).\r\n\r\n![image](https://cloud.githubusercontent.com/assets/1099479/16120237/18da7e5c-33df-11e6-9b70-047a788db4ce.png)\r\n\r\nThen the keyboard appears (editable focus), Safari compensates its height with an extra scrolling area (blue, virtual scrollbar). The problem is that the process happens on some higher \"higher\" level, which means that the whole web page is wrapped with some scrollable layer in Safari.\r\n\r\nWhat does it mean? It means a lot. For instance it means that all the elements which have `position:fixed` or `absolute` relative to the `<body>` will go off-screen. They're positioned to the web page, which is now scrolled **as a whole** within the keyboard–height–compensating Safari layer. \r\n\r\nWanna use `position:sticky`? It's sticky as long as the keyboard is not visible. Then it goes off-screen as everything else. It makes sticky toolbar and such structures pretty useless because they are not visible to the user most of the time.\r\n\r\nOn the desktop it would be as if something *scrolled the entire browser tab within the browser to accomodate some extra structure appearing inside*. It's an application level scrolling, not web–page level.\r\n\r\n![image](https://cloud.githubusercontent.com/assets/1099479/16120248/1fda0bfa-33df-11e6-94f5-b67f4cc0f0c0.png)\r\n\r\nSo now the user has 2 levels of scrolling: editable and keyboard–compensating. The problem is that they don't go well together. Or maybe: they require adaptation from the user. Editable scrolls smoothly, but when the user scrolls towards its bottom, some content is covered by the keyboard. To reveal it, a slightly longer \"touch&move\" is required. It's quite annoying and besides... the toolbar has gone off the screen now (panic, how do I exit the editor?!). \r\n\r\n![keyboard-fullscreen-scroll-to-bottom](https://cloud.githubusercontent.com/assets/1099479/16120414/af6cc8e8-33df-11e6-8f70-ed91cf5809bb.gif)\r\n\r\nSo to go the top of the keyboard–compensating layer and reveal the toolbar, the user starts scrolling again in the opposite direction. If not familiar with the viewport mechanics, they scroll the editable instead, which is also pretty frustrating. Another longer \"touch&move\" is required to move the whole webpage to the top and see the toolbar. Again, not very nice UX, although it works.\r\n\r\n![keyboard-fullscreen-scroll-to-top](https://cloud.githubusercontent.com/assets/1099479/16120375/8f692910-33df-11e6-80fc-6932c657af12.gif)\r\n\r\nSo how about zooming now? Yes, it works at the same layer as keyboard–compensating scrolling and engages higher–level scrolling in both directions. It means that it's even easier for the user to get lost in the editor, both horizontally and vertically, especially when the keyboard is visible.\r\n\r\nSo maybe it's possible to compensate that funny scrolling offset which appears when keyboard gets activated or user zoomed? Nope. The web page and DOM JS interface knows nothing about what happens when the keyboard kicks in. All the geometry/scroll/etc. values remain the same as if nothing happened. It happens in some other layer.\r\n\r\nMadness.\r\n\r\n#### Non–scalable fullscreen interface mock\r\n\r\nSamples: `fullscreen-non-scalable-*/index.html`\r\n\r\n**Note**: During the research Apple [announced](https://twitter.com/thomasfuchs/status/742531231007559680/photo/1) that due to accessibility concerns Safari in iOS 10 will ignore `user-scalable=none` meta declaration. The news has been confirmed – in iOS 10 beta1 it's impossible to block pinch to zoom using `<meta>` tag. In theory it could by bypassed by blocking [`gesture*` events](https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//apple_ref/doc/uid/TP40006511-SW1) like\r\n\r\n```js\r\ndocument.body.addEventListener( 'gesturestart', function( e ) {\r\n    e.preventDefault();\r\n} );\r\n```\r\n\r\nbut it's not a good idea really. In practice it's a source of event more problems because the editor is still unable to enforce `1:1` scale when in going fullscreen and there's no way to manually zoom out.\r\n\r\nLong story short, both `fullscreen-non-scalable-*` samples in [mobile-editing branch](https://github.com/ckeditor/ckeditor5-design/tree/mobile-editing) can be discarded because soon they will not correspond with the API of iOS Safari.\r\n\r\n#### Scalable fullscreen interface mock\r\n\r\nSample: `fullscreen-scalable-smooth-scroll/index.html`\r\n\r\nAfter some tinkering, Safari will display the editor like it was a native Fullscreen API mode. The result provides a decent UX, at least for a hack. Toolbar sticks to the top of the screen most of the time, but it is prone to disappearing due to the viewport mechanics (see **\"A quick note about viewport mechanics in mobile Safari\"**).\r\n\r\n![enter-fullscreen](https://cloud.githubusercontent.com/assets/1099479/16120535/0c045b7a-33e0-11e6-83e4-6aac64a336d4.gif)\r\n\r\n\r\nAt the moment, it's the only sample that provides some decent UI/UX in mobile Safari.\r\n\r\n#### Scalable fullscreen interface mock (with autogrow)\r\n\r\nSample: `fullscreen-scalable-autogrow/index.html`\r\n\r\nThe idea is to disable scrolling within editable by auto–growing it as the new content arrives. It would certainly improve the UX because the users would not need to struggle with double scrolling mechanics (see **\"A quick note about viewport mechanics in mobile Safari\"**).\r\n\r\nThe problem is that the trick which mocks fullscreen mode assumes that `body,html` have `width` and `height` equal `0px`, so the content of the web page which does not belong to the editor does not activate another web-page layer of scrolling (then would be 3 of them, yay!). To have an editable which expands vertically, these restrictions cannot be applied and also the editor itself cannot have `position: fixed` in respect to the bottom of the web page.\r\n\r\nThe result is that when the content of the web page is much longer than the content of editable, it becomes visible below the editor layer (which has `position: fixed`), at the bottom of the editor. Possibly, if the height of `body` was automatically adjusted to equal the height of autogrowing editor, this sample **could be a valid solution**.\r\n\r\n#### Scalable interface mock (with sticky toolbar)\r\n\r\nSample: `incontent-scalable-sticky-toolbar/index.html`\r\n\r\nIt's an implementation of https://github.com/ckeditor/ckeditor5/issues/135.\r\n\r\nUnfortunately `position: sticky` does not work as desired when the keyboard appears (see **\"A quick note about viewport mechanics in mobile Safari\"**). So it's as good as no special solution at all.\r\n\r\n#### Scalable in–place toolbar mock (TODO)\r\n\r\nSample: TODO\r\n\r\nSince any kind of CSS positioning does not go well with the presence of soft keyboard and user zoom, pinning the toolbar to the selection could be a solution instead. It would certainly limit the amount of space available for toolbar controls and perhaps cover some content, but it would clearly follow the user as they edit and format the content.\r\n\r\n## What's next?\r\n\r\n* A similar research on Android and Windows Phone is needed to compare the results and chose the right solution, possibly the same for all the platforms.\r\n* Additional samples should be created to check the pros and cons of the toolbar attached to the caret."},"comment":{"url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/comments/226509552","html_url":"https://github.com/ckeditor/ckeditor5-design/issues/149#issuecomment-226509552","issue_url":"https://api.github.com/repos/ckeditor/ckeditor5-design/issues/149","id":226509552,"user":{"login":"oleq","id":1099479,"avatar_url":"https://avatars.githubusercontent.com/u/1099479?v=3","gravatar_id":"","url":"https://api.github.com/users/oleq","html_url":"https://github.com/oleq","followers_url":"https://api.github.com/users/oleq/followers","following_url":"https://api.github.com/users/oleq/following{/other_user}","gists_url":"https://api.github.com/users/oleq/gists{/gist_id}","starred_url":"https://api.github.com/users/oleq/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/oleq/subscriptions","organizations_url":"https://api.github.com/users/oleq/orgs","repos_url":"https://api.github.com/users/oleq/repos","events_url":"https://api.github.com/users/oleq/events{/privacy}","received_events_url":"https://api.github.com/users/oleq/received_events","type":"User","site_admin":false},"created_at":"2016-06-16T14:53:12Z","updated_at":"2016-06-16T14:53:12Z","body":"## How to play with samples in mobile Safari\r\n\r\nTo use a physical device like iPhone or iPad with live console/elements debugging and to get rid of caching issues:\r\n\r\n1. In iOS enable Settings > Safari > Advanced > Web inspector.\r\n2. On Mac, in Safari Setting enable Advanced > Show develop menu.\r\n3. Connect the device with a cable to Mac.\r\n4. In Safari application menu select Develop > [Name of the device] > [Tab name]\r\n\r\n**Note:** You can install XCode to use device simulator instead but it's not as smooth and \"tangible\"."}}
{"actor":{"display_login":"oleq"}}