Numbers Aren't Always Numbers on iOS

A weird bug was brought to my attention yesterday concerning the Pivot comic from back at the end of May. If you read them regularly, you will remember that it was the one that had some frogs and a speech balloon spinning around (like a record, baby). The frog spinning was just an animation but the speech balloon rotation was an effect produced by changing the CSS transformation scaleX between 1 and -1. It creates the illusion that the balloon is rotating on a horizontal plane.

Based on a timer, I simply add or subtract a fraction of the scale value every few milliseconds. It worked fine on most platforms, but on iOS Safari there was an anomaly for small values very very very close to zero. A number like -0.000000000000005793976409762536, for example.

Because of the way numbers work in JavaScript, converting a number like that to a string value that can be used in a CSS property ends up looking like "-5.793976409762536e-16". And that's what Safari doesn't like. Apple even investigated it and everything. The official response was that it doesn't parse as a valid transform value. To fix it, I just call .toFixed(5) on the number before I put it in the CSS scaleX property. Five decimal places is plenty of precision, and it ensures that I never get the e thing in there.

But technically, I think it should have worked the way it was. According to the W3C specification, the value of scaleX (and other transforms as well) should be a real number - which can be expressed with the exponent notation. Okay, I realize the CSS Transformations is just a draft...so I guess I'll go easy on Apple this time (even though 75% of the editors are Apple employees!).

But interesting tie-in...today's comic also focuses on speech balloons. Well, technically on a sub-category of speech balloons - thought balloons. Have you ever thought about the history of speech balloons? Neither had I, before this evening. However, it turns out that balloons or bubbles showing the words spoken in a painting or drawing can be traced back hundreds of years.

Before the 18th century, speech was often indicated by strips or bands coming out of people's mouths, such as the one depicted here:

This was difficult to read, and rather limiting. By 1896, what might be considered modern speech balloons had started to be used with The Yellow Kid in the comic Hogan's Alley. The Yellow Kid is considered to be the first American comic strip character because of his recurrent appearances in the strip. Within a few years, other comic authors adopted the style and here we are today.

Hopefully, someday people will look back at the innovative things I've done with web comics and say how I introduced such pivotal devices to visual story-telling. It could happen. Help me out by reading and sharing today's comic:

Amphibian.com comic for 19 June 2015

Just How Mobile?

I'm sure you're familiar with the Native App vs. HTML5 debate. There's a lot to be said in that one. As a developer, I would much rather make a single HTML5 web app instead of native apps for both iOS and Android.

However, I know that such a course of action would very likely be a bad idea. Don't get me wrong, I love HTML5. But I've seen very few cases where an HTML5 solution is on par with a native app solution. There are some exceptions, and it very much depends on what your particular app is doing.

But HTML5 is getting better. I fully except that someday mobile apps will do things in mobile browsers that are quite impressive. That day is not today.

One place in particular that shows the mobile web's shortcomings is in games. There are many examples of good HTML5 games that are playable on the desktop browsers, but I have trouble finding good ones that play well on mobile browsers. Even very simple games just get awkward on mobile devices.

So if you decide to go native, you'll have to make apps for both iOS and Android. But what if you decide that your particular app is simple enough that you can do it in HTML5? You might want to consider making two web apps, one for desktop and one for mobile. Oh, "that's silly" you say. Everyone knows that you just use responsive design and make one web app.

Or do you?

I read this article, in which the author makes the case that your mobile use cases might be so different from your desktop use cases that it makes more sense to make a second web application just for mobile users. I'm certainly a big fan of understanding your requirements (and use cases) well before developing your software.

Here's the article. Give it a read.

Is responsive design killing mobile?

Think about it.

Amphibian.com comic for August 13, 2014