Mobile Apps

Other Sites

Between Worlds

As a teacher of app related programming, I felt somewhat obligated to translate my first app basically just for the experience. A friend of a friend spoke French and was generous enough to help so that seemed like a good idea.

It really wasn’t. I didn’t think it through.

The translator of your app needs to know three languages, not two: source, destination and geek. A sound base in geek gives them the context for translation. It means they know what what release notes are, what version numbers mean and that “bug” does not refer to an insect. For my own app, I needed a tabletop role-playing game geek as well, so that they had the correct context for what initiative was, what flanking meant and what “3d6+2” meant.

If you don’t have a fluent geek, a preferably a fluent geek familiar with your app’s niche, you can never be quite sure if they completely understand what you mean, no matter how you explain it. It’s simply not possible for you to check their work, after all.

It is also not enough for a translator to simply know the source and destination languages. They must be literate in both. The greater the writing skills of the app developer, the more necessary this becomes.

The reason is mostly in the marketing materials. Well written app blurbs are more than just instruction and description. They are advertising, an opportunity to draw the user into buying your app, and the clever use of language helps this immeasurably. If your translator cannot see the subtleties of flow and rhythm in what you have written, then they cannot duplicate it. It may contain the same information in the same order but it may lose its punch, its personality and its pulling power.

Finally, some easy advice I have heard from too many places to remember: Do not, whatever you do, whatever the temptation, use Google Translate. Get the translation done by a native speaker or don’t bother. Otherwise, your translation will be at best embarrassing and, at worst, unintentionally insulting.

Rumour has it that Apple is going to release a 7" iPad towards the end of the year. My first thought on reading this was an automatic "Apple would never fragment the platform to a third resolution so quickly". Then I got thinking that perhaps they wouldn't have to. What if they kept the same resolution of the iPad but increased the DPI?

There are some limits, though. Currently the iPad has a slightly lower DPI than the original iPhone did (132dpi compared to 163dpi). This means that the icons, text and controls all appear slightly bigger on the iPad. The problem is if it goes too far the other way - if the DPI gets too high - then the icons, text and controls will become too small to be usable.

But we do know that the DPI on the original iPhone is perfectly acceptable. That works just fine. So, what would happen if Apple made an iPad with the same 1024x768 resolution as the current model but which had the same 163dpi as the original iPhone? Would that equate to a 7" display?

If the screen is going to be 1024 pixel tall at 163dpi, then the height of the screen has to be 6.28" (1024 ÷ 163 = 6.28). Similarly, the width of the screen will be 4.7" (768 ÷ 163 = 4.71).

Now we have the width and height, we need the diagonal distance from one corner to the other. Pythagoras, take it away...

Diagonal distance = √ 6.282 + 4.712

= √ 39.43 + 22.18

= √ 61.61

= 7.84 inches

There you have it. If Apple releases an iPad with exactly the same resolution as the existing model (for compatibility) but with the original iPhone's pixel density (for usability), we would get a 7.84" screen.

So here we have the Karate Kid remake, removing - or to be fair, renaming - all of the old characters, changing the setting and then editing out the karate and replacing it with kung-fu. Not just using kung-fu and saying it was karate. They explicitly based the movie on a completely different martial art to the one in the title.

I also hear a rumour they're going to remake Shaolin Soccer, in which a washed up group of Tai Chi practitioners take up cricket bats and enter the Ashes series.

You can never be too cynical about Hollywood. The closest you'll get is being right.

Over at Posterous, Sachin Agarwal is predicting that Apple wants to kill the Finder and the file system metaphor that goes with it. He's right (and I agree) - up until the point where he says it's coming in the next version of MacOS X.

It's not coming for MacOS X at all.

Consider that the last time Apple enacted such a radical shift - from the command line to the GUI - the users mostly ignored it. Apple's customers continued buying the Apple II (making it the computer with the longest production run ever) and by the time the rest of the world caught up with the GUI, Apple had been left behind with some crumbs of market share.

Forcing a new paradigm on to users in the next MacOS X update would be even worse. It would cause revolt from uses who are jarred by the change and by developers who have to overhaul their applications like nothing they've ever done before. People would jump to Windows in droves. I would, as well. I believe in dumping the Finder but no one is ready yet.

And, really, why bother? They only have 10% of the market anyway. Even if their customers embraced it wholeheartedly, ten percent is a niche, not a revolution.

This time, Apple's being smarter than they were with the Macintosh. The revolution is sneaking up slowly from behind with new categories of devices. Apple isn't going to yank the Mac GUI out from under us but rather insinuate it into our lives via the steadily advancing iPhone OS. They've gradually moved from a cool phone, to a software platform, to a portable touch based computer and did so by giving the customers and developers new opportunities rather than taking away the old. If all goes to plan, Apple's customers will gradually transition to the iPad and related devices by choice rather than by force, and the Mac OS will have withered away to a niche.

All modern web browsers can now zoom a webpage. That is, you can scale it up or down and all the text, graphics, white space, movies and so on will scale with it. In an era where screen sizes range from 3.5 inches all the way up to 30 - with stops at 10", 15" and the low twenties - being able to adjust the size of an entire webpage is important. It's also wonderfully liberating for a webpage designer to know that they can design a site for the low end - say, a 1024x768 resolution screen - and still have it large and readable on big 24" desktop screens.

There is a problem, though. Although the text fattens up smoothly and crisply as you zoom the webpage, the graphics get all blocky and slightly blurry as the browser tries to fill in gaps between pixels with information it doesn't have. You can always make the website huge and trust people to zoom out rather than in but... Haha, no. No one would do that. Having a website that goes off the edge of the screen is just slipshod. Unattractive, unappealing and likely your undoing. No chance.

There is a trick, though, that allows resolution independent graphics which scale smoothly. Actually, I copied it from Apple. They make resolution independent icons for MacOS X simply by making them really, really big and then shrinking them to fit later. The same idea works in webpages. You can double the size of an image and halve it again in the HTML code. Here's an example using a picture...

Zoom in on the webage and the picture should stay crisp, clear and smooth. This is because the image is actually a reasonably massive 569x861 (click the picture to see it full size) but the HTML code which displays it sets the size to half that, like so...

<img src="article_images/cher-desilva.png" width="284" height="430">

The browser shrinks the image down smoothly and then, if you zoom the webpage, it can scale up to twice the size without any blockiness or pixel guesswork.

There's an obvious downside: file size. The larger version of the image is a bigger file and slower download. In the case of the picture, about three times the size (15KB for small vs 45KB for large). However, I also used it on the logo for this website and, being monochrome, even the double sized version, even saved as a 24-bit PNG, it still barely scrapes 10 KB. A logo which appears on every page is worth the extra care, I think. Glad as I am that it's a svelte 10KB, I'd still accept the tradeoff at 20KB and probably still be tempted at 30.

It's worth trying, at any rate, but check the numbers before you commit.

I haven't found any problems in any modern browsers but if you do come across some visual glitch, I'd very much like to know.