#I honestly haven't consciously developed for mobile

[heart-forge]

Hi! You obv dont have to answer this but Ive also been working on a twine game on harlowe for some time and usually play yours on my desktop. But I just played it on mobile and wow! That's such an effective conversion for mobile! I have my layout on harlowe all figured out for desktop play but just cant figure out how to make my passages and such responsive and mobile friendly but your mobile version looks completely different from the desktop version. I looked for some guides on how to achieve responsive passages and such in mobile but I didnt find much and what I found didnt really help me bc I probably understood it incorrectly. Could you maybe give some advice on how to tackle making a mobile version on harlowe? Of course I understand if its too much trouble!

I also really love your games and am looking forward to the bad ritual update!!

Oh thank you....thank you so much this means so much to me 💚💚💚

Okay so the straightforward answer is “my degree was really mobile focused so I’ve next to never built anything that is not optimized for mobile so I barely think about it” but I do absolutely have tips when I do sit down and think about it !!

Okay so pretty much all of this will exist in your CSS file, and it’s a pretty easy fix. One of the easiest things you can do to make things more mobile friendly is to tell pixels to get lost and jump on the percentages train. This happens in two main areas: font sizes, and dimmensions.

For a long time I did font sizes in pixels because that’s what the internet tells you to do when you ask it, but then I switched to doing font sizes in “em”. This makes it so that it’s using the user’s default font sizes as a references point, which generally makes things easier to read because the user will have their system font set to something they can see. So instead of trying to do a system style:

tw-body {     font: 13px; }

You’d instead write:

tw-body {     font: 1em; }

1em is using the exact system sized font the user has set, and then you increment it by decimal points to make it larger (or the opposite way to make it smaller but it’s a little dicey to start purposely going below what your user is comfortable seeing; it’s not impossible to need to, because if you have icons that link to things using the <a> tag, it will technically be a font and not an image). Always start at one, and change by .10 when you’re incrementing it.

Besides using em for font sizes (and font sizes only), you can also ditch pixels when you’re setting widths and heights. This is less common I’ve found because Twine really does most of its own work when it comes to how things are laid out, but say you do want a box or an image to sit somewhere on the page. Instead of writing something like:

.box {     width: 50px;     height: 50px; }

You can instead do something much safer and write something like:

.box {     width: 30%;     height: 30%; }

Now that isn’t a 1:1 size ratio, and part of the struggle will be to figure out how to make a percentage dimmensional value sit as precisely as you’d think an explicit pixel size would, but the benefits of taking up a percentage of the screen rather than an exact pixel value is that barring some browser nonsense, it will more or less look exactly the same on every screen. That saves you a LOT of trouble down the line: elements will be less likely to run off the screen/create weird scroll bars, and you’ll get less grief from an element taking up both 30% of a TV screen like I use in my daily life to read things, and 30% of a cell phone screen which is much smaller, versus having an element that takes up 20px of precious real estate on a cell screen versus a measly 20px of a TV screen.

This can also be used for stuff like margins and custom line spacing, it just isn’t necessarily AS important. Sometimes you don’t notice the difference, and sometimes it’s just a little added oomph of consistency that lets you more easily develop on one device for many. Another good tip that I should use but rarely do is to make sure that even though you’re developing on one device, check as many others as possible. Occasionally open up the file on your phone, just to see what everyone using a phone is seeing. I know when you’re using desktop Chrome you can preview the game in mobile (and on specific mobile devices) like this:

Open your game in Chrome (again, this might work for other browsers but I’m most familiar with Chrome), right click on the screen, and click “inspect”:

In the upper left corner of the menu that appears, you’ll see a little icon that looks like a tablet and a cellphone: go ahead and click on that.

The view of your game will then switch from desktop to mobile! From here you can see what it looks like, I think the default is “responsive” because that’s just generalized “what it looks like when the screen gets smaller”, but you can also toggle specific devices, or switch from portrait to landscape!