Is Twine optimized for mobiles?

Hello,

I’m currently working on a visual novel for smartphones (iOS and Android), I’m a complete beginner.
Twine seems like a good tool to developp it, however I’m a bit concerned about the final result on a mobile screen, because Twine seems mostly used on desktops.

Can I be sure once all my project is over on Twine it will be possible to have it optimised for mobiles (responsive and everything) ?

I have some solid bases on CSS, so the coding part in itself won’t be a problem, however I never released an app before.

Thanks,

Sylvain

1 Like

You know, I’m kind of in the same boat as you. I’m looking forward to more insight on this as well.

If you have CSS knowledge, you are over half-way there. The one thing that you have to make a decision over is what story format to use. Harlowe is great out of the box. SugarCube is the choice for most who want as much freedom as Twine stories can offer, but you have to will most likely want to use Tweego (compiler) and VS Code (code syntax highlighting) and you have to configure both with some effort… which means you aren’t using Twine’s editor at all.

It’s funny, because while I’m technically savvy with computers, I still struggle with understanding how Github actually works (very user un-friendly) and setting up Tweego… I need a step-by-step instruction manual. But ask me to write some JavaScript that controls SVG elements to create dynamic radial health gauges and such, I’m your man. :wink:


Edit: Sorry, I missed that you put SugarCube in the tags of your post.

2 Likes

The base UI for SugarCube has been optimised for mobile view.
However, if you edit the UI in StoryInterface or add large items in a passage, you may need to add some @media rules in your Stylesheet to make it work.

EDIT: here are the base CSS StyleSheet for SugarCube

EDIT EDIT: Twine was not created with Visual Novel in mind, more text-based projects. It might not be the best program to use.
Also Twine output is an HTML file, one you can host on a website or platform like itch. If your goal is to turn it into an app, you will need to use programs like Cordova.

6 Likes

This might interest you.

5 Likes

@manonamora

Thanks so much! I’m waist deep in Harlowe at the moment, but when the water reaches my chin, I’ve got a folder of SugarCube shortcuts ready to read. Your page is now at the top of the list. :slight_smile:

3 Likes

Simply put, the default HTML structure & CSS being applied to it of the main Story Formats should appear ok on a mobile device.

And if the Passages of your project only consist plain textual content, and you use standard links to transition between those Passages, then it should still appear ok on a mobile device.
eg. something along the lines of a Chose Your Own Adventure.

However, once an Author start moving away from such a project, and start:

  1. using a Story Format’s built-in features, or HTML & CSS, to customise the default layout & appearance of the page
  2. adding visual media content.
  3. adding more advanced web-development features to the page.

…then it is up to the Author to make sure those things are still mobile friendly.

3 Likes

Thanks for your replies

1 Like

this is false. you can use sugarcube with the twine editor app, unless things radically changed recently.

1 Like

@pieartsy
You are correct.

Yes, Twine supports SugarCube, but it is less than ideal without syntax highlighting… which is probably the main reason why most SugarCube developers encourage the use of VS Code and Tweego. I should have been more clear with the intention of my statement as it could create confusion.

I’ll edit my post.

3 Likes

Hi - the Passages of my project only consist plain textual content, and use standard links to transition between those Passages, I have nothing special happening going on but I have used some buttons within the code. I am using Harlowe story format however the text looks quite large on the mobile view. It requires a lot of scrolling. I do see the meta coding in my html so I’m not sure what else to do. Anyone able to help with this?

<head>
<meta charset="utf-8">
<meta content="width=device-width, initial-scale=1" name="viewport">
1 Like

I’ve just recently looked into mobile styling and can offer a solution for Harlowe much later in the day, if no one else does.

Not to worry. We got this! :slight_smile:

In the stylesheet

@media screen and (max-width: [value in px]) {
    tw-story {
          font-size: [the value wanted];
    }
}

you can replace width with height otherwise.

Essentially, the @media CSS rule will help you set how the page looks for specific size of screens and such.

No need to mess around with the meta elements.

While <meta> elements and @media rules can be used to indicate the type of behaviour an Author wants in regards to the font-sizes used by their project. It is the end-user’s Accessibility settings, and their choice of Web-browser and Operating System, that decides what actual font-size(s) are used and if automatic zooming occurs (on a mobile device).

eg. you might include "width=device-width, initial-scale=1" in your project, and use CSS to set the default font-size to 12px, and the end-user’s settings / device might still decide to show the text using a different font-size.

I don’t understand. I am viewing on my mobile and all other pages and apps have decently sized fonts. This is the only app that appears so enlarged. Also the font on the page outside of the frame in which the code was embedded has a decent size. Why would that be the case?

oh yes, will wait to see! Thanks a lot!

What Manon and Greyelf said are true.

What Harlowe provides in the header, <meta content="width=device-width, initial-scale=1" name="viewport">, is important for any CSS to render properly on mobile.

That said, in Harlowe (by default), story prose is very large on mobile.

What I use in Story# Stylesheet is…

:root { 
	font-size: 24px;
}

tw-story {
	font-size: 1rem;
}

@media screen and (max-width: 600px), screen and (max-height: 600px) and (orientation:landscape) {
	:root {
		font-size: 16px;
	}
}

Harlowe uses font-size: 1.5em and we override it with 1rem. However, by default most devices use a font-size of 16px so with 1.5em, that equals 24px. 24px tall lettering on mobile is very large so we set the default size to 16px for mobile, but leave it at 24px for desktop and tablets. With mobile phones (that I know of), the screen size is under 600px wide in portrait orientation. However, we also have to compensate for landscape mode with mobile so the part where we change the root font size to 16px is a little complicated.

The benefit of changing the root font size and using rem units is that, if you use rem for most everything (like padding, margins, header sizes, etc.) changing the root font size will scale everything in proportion. You don’t have to change multiple styles; just the root font size. The only things I wouldn’t use rem for are borders, lines, shadow offsets, etc. Use px for that finely tuned stuff.


I recommend using rem units instead of em. Unfortunately, there are cases where em will compound its size. So if you have a <div> with 2em and then another <div> with 2em inside it, the inner one will be 4em. Use rem and things will always be based on the root font size regardless of nesting multiple styled tags. Many web developers don’t know this about em. Using em will work fine most of the time, but when it doesn’t, it’s just plain annoying.

For example, in the passage I can write…

<div>TESTING<div>TESTING</div>TESTING</div>

…and the CSS can look like…

div { font-size: 2em; }

…and the result will look like…
image
…not what most would expect, I would say.


Anyway, let us know if that works for you and good luck on your project! :slight_smile:

Thanks a lot! The size on mobile decreased. It’s still a bit larger on the mobile than I would like but I can keep it like this. Thanks again!

Sorry, wrong thread.

I wish I had used these tools. With sugarcube’s
bevy of embedded open/close tag notations, it is a nightmare to write and debug without text highlighting.

1 Like

Change the font-size in the root to something smaller, say, 14px or 12px (instead of the current 16px).