Slate: Request for Official Support for Mobile (iOS, Android)

Created on 21 Feb 2018  路  11Comments  路  Source: ianstormtaylor/slate

Do you want to request a _feature_ or report a _bug_?

Feature Request

What's the current behavior?

Mobile is not an officially supported platform

What's the expected behavior?

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:

  • Officially support mobile browsers
  • Implement tests that run on mobile browsers (like saucelabs)
  • Builds aren't released unless they pass on mobile browsers
  • We prioritize mobile browsers before building new features

Here's why:

  • I think we are losing many developers, more than we hear about in issues, because not having mobile support is a no go. People are not commenting because they aren't getting started.
  • I think we will lose developers that use Slate now to editors that support mobile officially. For example, I started using SlateJS under the assumption that eventually mobile would be supported. It feels like this is not happening so I'm feeling like I need to consider other options. I just can't not have mobile support or have it break occasionally (without knowing others will work on it) because it's not officially supported.

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.

discussion

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. :)

All 11 comments

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.

FWIW, it sounds like this is an issue Basecamp is dealing with right now too 馃槃

image

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:

  • A guide to testing and developing on Android
  • A guide to testing and developing on iOS
  • Adding mobile unit testing to the workflow
  • More eyes and effort on fixing the Android problem
  • More work in making sure regressions doesn't happen on mobile
  • An official stance on adding more OS specific comments in the code (e.g. "this code adds an empty block here temporarily due to a bug in iOs that causes..."). Maybe adding comments into existing code that would help as well.

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:

  • Get somebody to act in a leadership role to make mobile happen and
  • Actually get mobile working

Would you be willing to:

  • Announce official suport for mobile on Slate
  • Add mobile support as a requirement for future releases after that (i.e. a release will not be pushed to NPM unless it has full mobile support)

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...

  • [ ] Update browserslist with reasonable mobile defaults.
  • [ ] Fix the existing issues with Android.
  • [ ] Fix any issues in iOS.
  • [ ] Add mobile device integration tests to ensure specific behaviors don't break.
  • [ ] Add a note somewhere about the "officially" supported devices/browsers.

They don't have to happen in a specific order. And at that point, I'd be okay with committing to:

  • Claiming that Slate "officially" supports mobile.
  • Not releasing a release unless it passes the tests/linter.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

chriserickson picture chriserickson  路  3Comments

YurkaninRyan picture YurkaninRyan  路  3Comments

ianstormtaylor picture ianstormtaylor  路  3Comments

bengotow picture bengotow  路  3Comments

ianstormtaylor picture ianstormtaylor  路  3Comments