Thanks for flagging this @wschenk! Would you mind pasting a screenshot of what you see on your Android device? Is it a phone that you're using?

The code editor isn't a text box, it's something that is broken on android.

I've got it up on Chrome in Android. It seems to sort of work, I can click around and get a keyboard for a bit, but then I can't get the keyboard anymore and I can't tell why. Is this what you are seeing?

We're using the embedded code editor from VSCode. Maybe we should load a different mobile friendly editor when we detect it?

I was recently trying out ChainShot, which offers online coding tutorials. When I tried to access it on my phone I got this modal:

Should we either (a) decide not to support code editing on mobile or (b) not be able to find a code editor that's not buggy on mobile, we might want to implement something similar. We could check whether a lesson has an exercise box and only apply this if it does, meaning that text-only tutorials (like the rest of the website) would still be functional on mobile. Thoughts @mikeal?

@zebateira Would love your input on this one, particularly given that you just swapped out versions of our embedded code editor. I'm fine with adding a message about our coding exercises not working on mobile if there's not a good mobile solution. I do think that text-based and multiple-choice tutorials should be mobile-friendly, which to the best of my knowledge they still are.

@terichadbourne it is still not working properly on mobile and it seems that it's an issue with the editor itself: microsoft/monaco-editor#246

I'd say to go forward with adding a warning message.

I do think that text-based and multiple-choice tutorials should be mobile-friendly, which to the best of my knowledge they still are.

Yes that is correct, everything is working properly there.

I know we've decided to add a warning message, but I just wanted to leave this here for future reference: CodeMirror 6 supports touchscreens, so in the future, as a long term solution, we might want to experiment with it.

Some considerations:

• Detecting if the device is a touchscreen and then show the warning message to those users it not really the best solution because we now have devices that are touch, but they can still have keyboards attached to them.
• Detecting if the device has a low resolution (ChainShot example) is also not the best idea because large tablet users without keyboards will not get the warning message and will get the bugged behaviour.

Still, I believe that showing the warning message will still be an easy improvement to redirect the mobile users away from this issue, leaving just some of our 1% of tablet users facing the issue:

Implementation Notes

• Add a custom data-lesson-type attribute to the #app element with the lesson type string
• Show the warning message (fullscreen, blocking the content) only when the attribute value is code or file-upload and the mobile media query matches.
• Warning message component should be added in the root of the body

A couple of questions on this suggested approach @zebateira, which can wait until next week.

I can't envision this box existing on anything except a lesson page, so I'm curious why you suggest calling the component from App.vue, which doesn't know its own lesson type (but I could probably make it sort it out from the path if push came to shove). At the moment I've created a MobileWarningModal and am calling it from Lesson.vue, where its easy to determine whether it's needed based on content.

<MobileWarningModal v-if="!isResources && (tutorialType === 'code' || tutorialType === 'file-upload')"
      :tutorial="tutorial"
      :lesson="lesson"
    />

I haven't yet worked on the media query aspect... will that not be possible from the Lesson component for some reason? Or were you envisioning more than just lesson pages needing this warning modal?

I followed your explanation of the drawbacks of the various media query approaches, but didn't quite follow what set of conditions you recommend showing the modal for. Could you clarify?

I'm sure the wording of this will need to change based on your notes about the actual media queries to check for, but in terms of user actions right now, I'm pushing them to click a link to go to our filtered list of code-free tutorials, which will work from any device. The "x" will still let them close the window and continue having a (now-predictably) bad experience. Does that feel appropriate to you for options or would you actually disallow continuing?

From a UX perspective, we need to decide how soon we stop them. I'd like for all resources pages to stay available on mobile, and I think landing pages make sense as well so that you can at least preview the content to see if you'll be interested in pursuing it later. Within the lessons, though, some tutorials throw in one or two text-based lessons before jumping into coding challenges. The coding challenges certainly need the warning, but I was thinking of also including it on the previous lessons so the user doesn't waste time getting into content that they can't complete. (This is how my current draft works, assessing tutorialType rather than lessonType.) Thoughts?