Feature Request
Mobile is not an officially supported platform
So a short summary of what I know (or think I know) about the state of Slate today with respect to mobile:
I don't think in the state of the web today that our stance should be "would like to support mobile" but rather "we support mobile". It's a small change in language but I believe will influence the way we prioritize. For example, QuillJS supports mobile which you can tell because they use SauceLabs to test against all browsers including iPhone and Android browsers and prominently display the passing tests on their home page.
Here's some things that I suggest:
Here's why:
In my opinion, the reach of SlateJS will be larger (more than double) with official Mobile support. With official support, perhaps we can rally developers around working on getting Mobile support and tests put in.
Of course, there are many people involved (not least of all Ian (you are awesome!)) so I understand alternative viewpoints but I thought I'd put this out there because I think others are thinking the same thing.
Edit: As a quick gauge of response, I added "Thumbs Up" for agreement. Or "Thumbs Down" not in agreement.
Good call, I've been using Slate with iOS and it's been comparable to desktop. Though that android issue seems absolutely awful. If that's solved and there are tests in-place I think it's mobile/ready. 馃憤
Hey @thesunny thanks for writing this up. I agree with you, in some aspects. I would absolutely love to see Slate work perfectly on iOS and Android. (As far as I last checked, it works pretty well on iOS.) And I welcome any and all contributors that want to help make that happen.
The biggest question of "official mobile support" to me is where the effort comes from.
I originally open-sourced Slate because I saw that the existing open-source editors were not being architected well鈥攊n ways that led to lots of leaky abstractions and leeching complexity.
But I contribute to Slate purely to solve my own needs. When I need a new feature, I build it. When I realize my end users are being impacted by a bug, I fix it. When I feel like certain architectural decisions are leeching complexity into my code base, I redesign it. When I notice something in Slate that isn't right, I refactor it. When I realize something isn't documented well for me, I document it. And then on top of that, I also try to fix egregious bugs or breaking changes that I caused that might be impacting others, and try to help others get their own contributions into Slate.
And I'm super thankful that there are others using Slate that do the same. When they see bugs, or get excited about a potential new feature, or realize that docs are missing, they contribute. (And you have done lots of contributing yourself, so thank you!)
So with that in mind, the issue with claiming "official mobile support" is where will the work come from. I currently appreciate iOS support, but it's not a core requirement for me. So I love when people contribute things to help iOS, and am happy to give them feedback and thoughts that might make contributing easier, but it's not something that I personally can devote hours to because my users just don't need it yet. (This will probably change in the future.) And as for Android, my need for Android support is even lower.
So I personally can't commit to "official mobile support".
If others want to see it happen, they will need to step up and contribute themselves. They'd need to fix the bugs on whatever mobile devices they find. They'd need to propose and implement a way for the tests to be run in the mobile browsers to ensure no breaking changes happen. They'd need to write good code comments so that non-mobile-contributors don't accidentally break things.
The issue with Android is that no one has cared enough so far to actually make it happen. Like you said, issue #725 has been open for almost a year, but in that time not a single pull request has been opened that references it. (That and it sounds like Android does some super non-standard things when it comes to mobile editing.)
So basically, I agree with you in that I'd love for iOS and Android to be perfectly supported. I just personally am not going to be the one to do it right now, so others need to step up. And in that sense, I'm not sure what "official" means.
That said, if others contribute the backbone of "official mobile support"鈥攊e. fixes and tests鈥攖hen I am happy to work within that system to not break it.
Hi @ianstormtaylor
Thanks for such a quick and thorough response.
You've given us so much with this project that it woud be unfair to put the expectation of building official mobile support onto you when it's not a high priority for you.
My hope was more along the lines of making a declaration and rallying the troops around this issue.
I can't be certain, but I feel like if there was a call to make mobile support official, that a group of people might start taking projects to allow this to happen. You have been putting together a team now after all. :) I would be happy to contribute (although I don't think I'd be the right person to lead) but, honestly, I'm a lot more inclined to help if I was part of a larger effort.
For example, some projects that I could see happening:
Obviously, this could happen naturally but it feels like it's not happening naturally which was the impetus for this issue. From another point of view, I think by prioritizing mobile support, we will have a larger group of developers using it and it may actually help bring more contributors to the non-mobile parts which would help your usage of the editor. How about that for putting some spin on it. :)
@ianstormtaylor
It is disconcerting seeing how many people have problems with Android and editors. I presume it's solvable since QuillJS seems to support Android and they have a backing store as well (i.e. the source of truth is not the editor itself). It's probably a lot of hard work though...
That is an interesting way to think about it 馃槃
I totally agree with you. I'm not even sure if it's a lot of work or not, we can't really know until the research is performed. It could end up being easy. That said, even someone just figuring out how to get in-browser testing for Chrome would help towards the mobile cause too.
@ianstormtaylor
In order to make this more actionable, how about this as a proposal?
If we can:
Would you be willing to:
Then perhaps we can do a search for somebody to manage mobile support.
Unfortunately, as I mentioned earlier, I'm unfortunately a bad choice; however, I'd be willing to commit some time.
I figured out earlier how to setup a development environment for iOS on a Mac which I'd be willing to write up for example. It's nothing especially mind opening but sure would have saved me a couple days having that all packaged nicely at the beginning. I went through buying an iPad for testing, trying to get it to work through the USB which failed because debugging and Internet couldn't work on the USB at the same time, to trying to get the simulator working, to finally getting it and then finding out that the keyboard has to be disabled to replicate properly, etc. Point being that there were lots of little things that I'm sure would save others time if they knew about it.
@thesunny I'd be okay with a tweak on that. It seems like we need people to contribute...
browserslist with reasonable mobile defaults.They don't have to happen in a specific order. And at that point, I'd be okay with committing to:
But I won't commit to not releasing without "full mobile support" for things that aren't covered by the test suite, just like I wouldn't do that for browsers either, which is why things break sometimes. Otherwise it requires too much manually testing to occur, which isn't sustainable.
@ianstormtaylor that's a great tweak on it
So now we go on the lookout for somebody to help manage this.
I'd be willing to help on this and maybe even add more details or specifics to the "to do" list so that the management role is well specified.
As I said, I don't think I'd be a good lead for this. I'm simply too inconsistent with when and how long I can be involved. I think a good lead needs to be checking in and following up. Probably doesn't have to be that often but should be consistent.
While I'm not a good choice for lead, I'd be willing to dedicate chunks of time to work through specific issues or complete certain projects.
So, anybody willing to consider the role? Or perhaps, any nominations. :)
Okay, I鈥檓 off to Hawaii on Wednesday for a week but sometime after I get back, I鈥檓 gonna take a crack at moving this forward with everybody that can contribute.
As I said, I wasn鈥檛 sure I鈥檇 be the best choice but in absence of any other choices, it鈥檚 pretty clear that by default, I鈥檝e become the best choice. :)
I'll close this issue soon as I've started a separate issue on developing a Roadmap to Mobile Support https://github.com/ianstormtaylor/slate/issues/1720
If you are following this issue, please pop over to the Roadmap.
Most helpful comment
Okay, I鈥檓 off to Hawaii on Wednesday for a week but sometime after I get back, I鈥檓 gonna take a crack at moving this forward with everybody that can contribute.
As I said, I wasn鈥檛 sure I鈥檇 be the best choice but in absence of any other choices, it鈥檚 pretty clear that by default, I鈥檝e become the best choice. :)