3 ms·

I've been following this space for some time [1], and for me the constant struggle has been finding something that is both batteries-included, so I don't have t

by qrohlf 8y ago

I've been following this space for some time [1], and for me the constant struggle has been finding something that is both batteries-included, so I don't have to build a usable editor from primitives on projects where the core differentiator is not related to how content gets authored, and mobile-friendly, so that I don't have weird capslock bugs on iOS [2], completely broken Android support [3], and just general mobile weirdness [4]. To the best of my knowledge, Prosemirror has been most willing to prioritize mobile support, and currently has the best mobile browser coverage of the three most commonly mentioned modern contentEditable options (prosemirror, draft-js, quill). Unfortunately, building an editor with Prosemirror is a very hands-on process that requires you to make all the UI decisions and most of the UX decisions yourself, which isn't a great fit for most projects that don't need to innovate in the actual content creation side of things. I would LOVE it if a batteries-included editor like this, which clearly had a lot of thought put into the UX and UI aspects, was built on the very-robust technical foundation of Prosemirror (or similar). There are a few efforts at this on GitHub, but nothing so far with more than one or two contributors that I've found. The backend of editor.js looks solid, but without any discussion of mobile IME support, and without the backing of big players like NYT [5], realistically I can only guess that mobile support for editor.js will end up similar to the well-intentioned but partially complete mobile support found in other smaller projects like quill, slate, etc. [1] https://news.ycombinator.com/item?id=14417624 https://news.ycombinator.com/item?id=14417624 [2] https://github.com/codemirror/CodeMirror/issues/3403 https://github.com/codemirror/CodeMirror/issues/3403 [3] http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-on-android/ http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-... [4] https://github.com/ianstormtaylor/slate/issues/2062 https://github.com/ianstormtaylor/slate/issues/2062 [5] https://open.nytimes.com/building-a-text-editor-for-a-digital-first-newsroom-f1cb8367fc21 https://open.nytimes.com/building-a-text-editor-for-a-digita...

neSpecc 8y ago
Thanks for a feedback and links. We have done a lot of work on core stabilisation and API improvement. First version of editor.js is used for a while by local big (well, relatively) media projects — vc.ru, dtf.ru, tjournal.ru with the 200-500k DAU. This projects have UGC communities, so the Editor is using many times in a day. I mean most of our resources on the past stage was directed to the stability purposes. Fully agree with you about the importance of UI and UX (and mobile adaptation) in our case. This is a next step we have start today. And this is a reason why it is an open source and free. We see many talented developers and the demand, so we will continue to work.
Reinmar 8y ago
We've been doing quite a lot of research around mobile support in the early phase of working on CKEditor 5. We knew from our past experience that on mobile devices (especially smaller ones) you need a dedicated UI, rather than a responsive version of the same UI that you use on the desktop. When the software keyboard is visible (+ when you have autocompletion bar above the keyboard) there's really not much space for your UI and the text that you want to edit. It means that you need really good control over what's happening on the screen in order to be able to implement a reliable UI. Anyway, we had big plans for mobile support in CKEditor 5. Then we started doing more research [1] and it turned out there are critical issues with how WebKit works. You can guess, you can try, but with a tone of hacks you still won't be able to guarantee a smooth UI and great UX. Right now, we're in a state where: * after spending several months on it, text editing is well supported on iOS and Android (including spellcheck and stuff) – we don't get any bug reports recently about that part, * the default UI is not working great on smaller devices. The sad part is – we don't have any bigger plans to address the latter. We have some smaller ideas for making the current UI more responsive, but there will still be fundamental issues that you will face when using it: * The conflict between the native UI (the balloons/panels with paste/copy/cut/bold/italic) and the custom editor UI. I've been bringing that to the W3C's attention since 2015 and nothing happened since then (most recent topics: [2], [3]). Right now, I don't have the funds anymore to lobby for this (neither have anyone else, apparently), so those topics seem to be completely stale. * Inability to display your UI and implement functions like scrolling to the caret in a reliable way on WebKit due to its broken viewport mechanics [4]. I even talked about this with one of the Apple devs responsible for the current behavior and he agreed that there may be a problem (a good first step :D), but I got literally zero feedback after the last year's TPAC in Lyon when I presented this issue. * And more... IMO, it's due to those issues that we haven't seen a single editor (implementing more than some really basic functions) with a good and stable UX on both iOS and Android. Every solution I saw was flawed in one way or another. I'm not saying that it's completely impossible to build such a solution, but rather that, taken all the obstacles and moderate demand (desktop is still the main platform for rich-text editing), the ROI seems too low for anyone to invest enough in it. Anyway, feel free to contact me (e.g. via https://twitter.com/reinmarpl https://twitter.com/reinmarpl) if you'd like to discuss this more. [1] https://github.com/ckeditor/ckeditor5-design/issues/149 https://github.com/ckeditor/ckeditor5-design/issues/149 [2] https://github.com/w3c/editing/issues/176 https://github.com/w3c/editing/issues/176 [3] https://github.com/w3c/editing/issues/182 https://github.com/w3c/editing/issues/182 (my presentation from last year's TPAC) [4] https://gist.github.com/Reinmar/91c70d2882523f47da7c498050421204 https://gist.github.com/Reinmar/91c70d2882523f47da7c49805042...

by qrohlf 8y ago

neSpecc 8y ago

Thanks for a feedback and links. We have done a lot of work on core stabilisation and API improvement. First version of editor.js is used for a while by local big (well, relatively) media projects — vc.ru, dtf.ru, tjournal.ru with the 200-500k DAU. This projects have UGC communities, so the Editor is using many times in a day. I mean most of our resources on the past stage was directed to the stability purposes. Fully agree with you about the importance of UI and UX (and mobile adaptation) in our case. This is a next step we have start today. And this is a reason why it is an open source and free. We see many talented developers and the demand, so we will continue to work.

Reinmar 8y ago

We've been doing quite a lot of research around mobile support in the early phase of working on CKEditor 5. We knew from our past experience that on mobile devices (especially smaller ones) you need a dedicated UI, rather than a responsive version of the same UI that you use on the desktop. When the software keyboard is visible (+ when you have autocompletion bar above the keyboard) there's really not much space for your UI and the text that you want to edit. It means that you need really good control over what's happening on the screen in order to be able to implement a reliable UI. Anyway, we had big plans for mobile support in CKEditor 5. Then we started doing more research [1] and it turned out there are critical issues with how WebKit works. You can guess, you can try, but with a tone of hacks you still won't be able to guarantee a smooth UI and great UX. Right now, we're in a state where: * after spending several months on it, text editing is well supported on iOS and Android (including spellcheck and stuff) – we don't get any bug reports recently about that part, * the default UI is not working great on smaller devices. The sad part is – we don't have any bigger plans to address the latter. We have some smaller ideas for making the current UI more responsive, but there will still be fundamental issues that you will face when using it: * The conflict between the native UI (the balloons/panels with paste/copy/cut/bold/italic) and the custom editor UI. I've been bringing that to the W3C's attention since 2015 and nothing happened since then (most recent topics: [2], [3]). Right now, I don't have the funds anymore to lobby for this (neither have anyone else, apparently), so those topics seem to be completely stale. * Inability to display your UI and implement functions like scrolling to the caret in a reliable way on WebKit due to its broken viewport mechanics [4]. I even talked about this with one of the Apple devs responsible for the current behavior and he agreed that there may be a problem (a good first step :D), but I got literally zero feedback after the last year's TPAC in Lyon when I presented this issue. * And more... IMO, it's due to those issues that we haven't seen a single editor (implementing more than some really basic functions) with a good and stable UX on both iOS and Android. Every solution I saw was flawed in one way or another. I'm not saying that it's completely impossible to build such a solution, but rather that, taken all the obstacles and moderate demand (desktop is still the main platform for rich-text editing), the ROI seems too low for anyone to invest enough in it. Anyway, feel free to contact me (e.g. via https://twitter.com/reinmarpl https://twitter.com/reinmarpl) if you'd like to discuss this more. [1] https://github.com/ckeditor/ckeditor5-design/issues/149 https://github.com/ckeditor/ckeditor5-design/issues/149 [2] https://github.com/w3c/editing/issues/176 https://github.com/w3c/editing/issues/176 [3] https://github.com/w3c/editing/issues/182 https://github.com/w3c/editing/issues/182 (my presentation from last year's TPAC) [4] https://gist.github.com/Reinmar/91c70d2882523f47da7c498050421204 https://gist.github.com/Reinmar/91c70d2882523f47da7c49805042...