Optimizing your website for the Wii

I got myself a Wii last year, and in the process of trying to optimize this blog for it (yes, the Wii has a browser), I learned a number of things that I think will be interesting to share with you…

The Device

I hardly need to introduce it, but here goes: the Wii is a home game console from Nintendo whose main interaction mechanism is a combination gamepad, light gun and motion sensor called the Wiimote. A nice thing Nintendo has in common with Apple is that they are not afraid to try and experiment with new user interaction mechanisms, and besides these games where the Wiimote was very well used, it’s also a pretty good way to browse the web.

Don’t dismiss the Wii as a web machine. It has sold a ton of units and (more importantly) done so in plenty of non-techy homes where you couldn’t find a PC, Mac or iPad. That doesn’t necessarily translate into an audience, but that’s got to count for something, right?

The Browser

The Wii browser is “Opera-powered”, in other words it’s running some mobile/embedded version of Opera. While Opera is a minor browser on the desktop, Opera is a major player in embedded and mobile, providing customized variants of its browser to be preinstalled in a number of devices; Opera is estimated to have its software preinstalled on more than a hundred million devices sold per year

The browser used be a (cheap) paying option, but it’s now free; the user just has to get it in the store for 0 points and it will install as a channel, directly available when the Wii is launched. As we’ll see, the Wii browser is quite good, with a few caveats. Note that the browser is not Opera Mini (PDF) (I’ve always liked how John describes it), as websites do see the IP of my router (and not that of the proxy).

The Display

While the Wii can display over a TV (or computer display as I do, thanks to the Wii2HDMI) of any size, at best the resolution will be 480p, and this has quite an impact, in particular on text legibility.

The Outcome

Before I go any further, let me add the caveat that what I do here is not so much web design as it is “making sure my writing displays correctly with a suitable user experience”. With that in mind, here is what I found out.

Typefaces

One of the “joys” of web design has always been the differing sets of typefaces available depending on the target OS; and while there are correspondences (like the usual Helvetica/Arial, Geneva/Verdana, etc.) some typefaces in Windows have no Mac equivalent, and the converse is true as well. But web designers have always been able to rely on the so-called “web safe fonts”, right? Well… Imagine a platform that would not have all these typefaces. No Helvetica, or anything of the sort; but it goes further, there is no Courier or equivalent, you read that right, no Courier. And I hear you thinking, that can’t be, this is pretty much the last resort typeface, but that’s right: there is no Times either.

The Wii browser only has one typeface, and it’s not any of the web safe ones.

This is disappointing, but understandable when you consider the Wii is pretty much an embedded device, with limited memory and permanent storage. Remember that moderns fonts, especially their cache, take quite a bit of memory; and add to this that the Wii has to also embed at least one Japanese/Chinese font. On the other hand, this means there is no need to worry about making sure to pick the right typeface or add it in the fallback list, as whatever you do that typeface will be used instead anyway. Well, I need to mention that image replacement does work, as well as fonts rendered with Flash (more on Flash later); web fonts do not work. Also, the Wii browser typeface does have bold, but no italics: yes, this means your <em> inflections are lost; to me this is a grave sin, much worse than the lack of alternative fonts. In a <pre> the spacing is adjusted so that the text is monospaced (though not in a <code>); it looks a bit funky, but e.g. structure of ASCII art is preserved.

This typeface is a pretty legible sans-serif screen font, nothing special. A particularly recognizable characteristic of this font is the not-quite-horizontal bar in the lowercase “e”.

Legibility

Given the resolution the Wii supports, when it shows a page at full width the text is pretty much illegible, so like the iPhone the Wii renders a page in a viewport (800 pixels wide for the Wii) and allows the user to zoom inside that area: the user does so by way of +/- buttons on the Wiimote; this is not as fun as pinch-to-zoom, but very easy and discoverable. The problem however is when text runs to the entire browser width, in which case the user has no choice but to pan left and right (which he does with the directional pad) because he can’t have the beginning and end of a line on screen at the same time (I’m looking at you, OC ReMix). Fortunately, having too long lines is a bad idea in the first place as it makes it difficult to find the beginning of the next line, so blog themes either have a fixed width with a reasonable width like 500 pixels maximum, or have one or two side columns which reduce the main column width to something that can comfortably be zoomed to, and are therefore already suitable. Still, something to keep in mind.

Some sites direct the Wii browser to their mobile version which is a bad idea (at least for the examples I’ve seen), as the viewport remains 800 pixels wide (I have not investigated to know whether it is actually possible for sites to change the viewport of the Wii browser), and as the text runs to the full width, this mobile site is less usable on the Wii than the full site.

Depending on the display, it may be more or less comfortable for the user to read text for a long time, but from a distance of 3 meters of the computer display the Wii was displaying to, I could read quite a bit without being tired.

Layout

The Wii browser support for CSS is very good; I’m no CSS buff, but every site I could come across rendered correctly (and it’s quite unlikely many of them took this particular browser into account), so CSS support must be at least on par with the current lowest common denominator, which is nothing to sneeze at on such a device. So everything should just work, and as far as I can tell in this area you shouldn’t need to worry about the Wii if you already take IE 6 or 7, Safari, Firefox, Chrome and Opera into account.

Navigation

In the Wii browser the user can click links by pointing the Wiimote at the screen like a light gun, where the location pointed to will be represented by a hand; so yes, in the Wii browser there is a pointer, and hover-based interaction will technically work. I say “technically” because the accuracy isn’t great and in particular the pointer shakes a lot, so the user can easily hover out and “lose” a menu he was trying to drill down into, so don’t rely on hover-based navigation.

Text can be input with an on-screen keyboard, though it is tedious and error-prone, due to the shaking. Users will find it easier to navigate in subcategories to find what they want rather than input a search term, and don’t expect them to ever leave a comment.

Miscellanea

The Wii browser has Flash support, including video and sound, interestingly enough. I hear it’s Flash Lite, and likely corresponds to some older version of Flash, but it works if you don’t ask too much of it. For one, in most sites which rely on Flash for everything including navigation, I quickly got “out of memory” errors (embedded device, remember), at which point you can only try and reload the page (which will result in the same error again), so these sites are literally unusable on the Wii. Second, while games do work, in a way, don’t think you can do an end run around Nintendo Wii certification/WiiWare with Flash games, as performance is horrible for anything moderately complex. All that said, it will render ads, YouTube videos, Twitter and other widgets, text for Flash text replacement, it will play simple games in real time, and you can watch Homestar Runner to your heart’s content.

One can also connect a USB keyboard to the Wii and use it for text input in the browser; I can use my Apple keyboard on the Wii without problem. More interestingly, key press events do reach Flash and Javascript (which is more than I can say for the iPad, where you can use a Bluetooth keyboard but Javascript can’t get key press events, the keyboard is reserved for text input), for instance this allows playing Light Bot, which is entirely pointer-based except you need to hit space between each level… This is only of limited interest, as users with access to a keyboard likely have access to a computer in the first place.

Since there is no filesystem, users won’t be able to download any file. The browser is not even capable of just playing an mp3 file put for download, so use Flash for audio and video media. The browser cannot read PDFs either; I don’t think it can load anything other than HTML pages and images files.

So… is it worth it?

Is the Wii browser worth taking into account? It has issues, but it is quite modern and capable by most aspects, so it’s at least worth checking if your site renders correctly in it and fixing any obvious problem. Then further work can be justified depending on your audience

Tomorrow, we’ll see how to make your site shine in Lynx.

Developer ID might not seem restrictive, but it is

I need to talk about Gatekeeper and Developer ID.

In short, I am very uncomfortable with this previewed security feature of Mountain Lion. Apple is trying to assure that users are only going to be safer and that developers are still going to be able to do business as usual, but the Mac ecosystem is not limited to these two parties and this ignores pretty much everyone else: for these people Gatekeeper is going to be a problem. Enough so to make me consider switching.

I don’t mean to say it’s all bad, as Apple is set to allow more at the same time as it allows less. Indeed, with Developer ID Apple is clearly undertaking better support of apps from outside the Mac App Store, if only because they will have to maintain this system going forward, and I can only hope this support will improve in other areas (such as distribution: disk images are long past cutting edge). But while Apple gives with one hand, it takes away with the other, as Mountain Lion will by default (at least as of the current betas, though that seems unlikely to change) reject unsigned apps and apps signed by certificates other than Mac App Store and Developer ID ones; of course most people will not change that default, and so you will have trouble getting these people to run your code unless you get at least a Developer ID from Apple, and while better than requiring you to go through the Mac App Store this requirement is quite restrictive too.

The matter is not that with Developer ID apps will now be exposed to being blacklisted by Apple; honestly, speaking as a developer I personally do not mind this bit of accountability. Maybe there are going to be issues with this power now entrusted to the hands of Apple, such as the possibility of authorities (through executive branch bullying, or with a proper court order) asking Apple to neutralize an app perceived as illegal, but if this ever happens I believe the first incidents will cause this eventuality to be properly restricted by law.

No, the matter, as I wrote to Wil Shipley in an email after his proposal, is that many people who are important to the Mac platform are going to be inconvenienced with this, as getting a Developer ID requires a Mac Developer Program membership.

  • Sysadmins/IT people, to begin with, often need to deploy scripts, and either those don’t need to be signed, and they become the new malware vectors, or they do (Apple could define an xattr that would store the signature for a script) and then any company deploying Macs needs to enter the Mac Developer Program and manage a Developer ID that IT needs to be able to access day to day (that is, not just for releases, like in a software company) and so could leak, just so that the company can service its own Macs internally.

  • Then we have people using open-source tools that Apple doesn’t provide, such as lynx, ffmpeg, httrack, mercurial, etc., and who likely get them from projects like MacPorts; maybe we have an exception for executables that were built on the same machine, but how is it enforced then?

  • Student developers have historically been very important to the Mac platform, if only because many current Mac developers started out as such. If entering the Mac Developer Program is required to distribute Mac apps in the future, it’s a threshold that many will not clear, and as a result they will not get precious feedback from other people using their code, or worse they will not choose Mac development as a career as they could have if they had been encouraged to do so by people using their software (for instance, Jeff Vogel wasn’t planning on making Mac games as a career, but he quit grad school when Exile started becoming popular). At 99$ (per year), it seems silly to consider the cost of the Mac Developer Program as an obstacle, especially when compared to the cost of a Mac, but you have to consider the Mac likely benefitted from a student discount and was possibly entirely paid by the family; not so for the Mac Developer Program. Regardless, any extra expense will, rationally or not, cause it not to be taken by a significant portion of the people who would have otherwise tried it, even if it would have paid for itself eventually.

  • Many users will tinker with their apps for perfectly legitimate reasons, for instance in order to localize it and then submit the localization to the author, or in the case of games to create alternate scenarios or complete mods. It’s something that I am particularly sensitive to, as for a long time I have both enjoyed other’s people’s mods and conversely tinkered myself and shared with others: I have created mods, documented the formats to help others create mods, extracted data from the game files, gave tips and tricks and development feedback on other people’s in-progress mods, I was even at some point in charge of approving mods for a game to the official mods repository, and I created tools to help develop mods (more on that later). The user modding tradition is very strong in the Ambrosia Software games community, going back to Maelstrom nearly 20 years ago, and that’s merely the one community I am most familiar with. However, tinkering in such ways typically breaks the app signature; an app with an invalid signature will currently run on Lion (I know it if only because my Dock currently has an invalid signature), but it will likely change with Mountain Lion as otherwise Gatekeeper would be pointless (an important attack to protect against is legitimate apps that have been modified to insert a malicious payload and then redistributed). So we will have to rely on developers excluding files that could be desirable for users to tinker with from the signature seal… well, except that the developer will then need to make sure the app cannot be compromised if the files outside the seal are, and I’m pretty sure it’s impossible to do so for nibs for instance, so app developers will not be able to simply leave the nibs out of the seal so that users may localize them; they will need to roll out systems like the one Wil Shipley developed for localizations, completely out of the realm of Apple-provided tooling.

  • Power users/budding developers will often create small programs whose sole purpose is to help users of a main program (typically a game, but not always), for instance by interpreting some files and/or performing some useful calculations; they typically develop it for themselves, and share it for free with other users in the community of the main program. It’s something I have done myself, again for Ambrosia games, and it’s a very instructive experience: you start with an already determined problem, file format, etc., so you don’t have to invent everything from scratch which often intimidates budding developers. However, if it is required to register in the Mac Developer Program to distribute those then power users will keep those to themselves and they won’t benefit from the feedback, and other users won’t benefit from these tools.

(Note that Gatekeeper is currently tied to the quarantine system, and so in that configuration some of the problems I mentioned do not currently apply, but let’s be realistic: it won’t remain the case forever, if only so that Apple can have the possibility of neutralizing rogue apps even after they have been launched once.)

In fact, a common theme here is that of future developers. Focusing solely on users and app developers ignores the fact that Mac application developers don’t become so overnight, but instead typically start experimenting on their spare time, in an important intermediate step before going fully professional; it is possible to become an app developer without this step, but then the developer won’t have had the practice he could have gotten by experimenting before he goes pro. Or worse, he will have experimented on Windows, Linux, or the web, and gotten exactly the wrong lessons for making Mac applications—if he decides he wants to target the Mac at all in the end.

Because of my history, I care a lot about this matter, especially the last two examples I gave, and so I swore that if Apple were to require code to be signed by an authority that ultimately derives from Apple in order to run on the Mac, such that one would have to pay Apple for the privilege to distribute one’s own Mac software (as would be the case with Developer ID), then I would switch away from the Mac. But here Apple threw me a curveball, as it is the case by default, but users can choose to allow everything, but should that matter, since the default is what most people will ever know? Argh! I don’t know what to think.

In fact, at the same time I am worrying about the security of the whole system and wish for it to be properly secure: I know that any system that allows unsigned code to run is subject to the dancing bunnies problem; and maybe the two are in fact irreconcilable and it is reality itself I am having a problem with. I don’t know. Maybe Apple could allow some unsigned apps to run by default, on condition they have practically all the sandboxing restrictions to limit their impact. The only thing is, in order to be able to do anything interesting, these apps would at least have to have access to files given to them, and even that, combined with some social engineering, would be enough for malware to do harm, as users likely won’t treat these unsigned apps differently from regular desktop apps, which they consider “safe”. Maybe the only viable solution for distribution of tinkerer apps are as web apps (I hear there is work going on to allow those to access user files); I don’t like that very much (e.g. JavaScript is not very good to parse arbitrary files), but at the same time users do tend to take web apps with more caution than they take desktop apps (at least as far as giving them files goes, I hope), and any alternate “hyper sandboxed” system that would be introduced would have to compensate the 15+ years head start the web has in setting user expectations.

The same way, the very same cost of the Mac Developer Program which is a problematic threshold for many is also the speed bump that will make it economically unviable for a malware distributor who just had its certificate revoked to get a new one again and again.

This is why, paradoxically, I wish for iOS to take over the desktop, as by then iOS will likely have gained the possibility to run unsigned apps, and users having had their expectations set by years of being able to use only (relatively) safe iOS App Store apps will see these unsigned apps differently than they do apps from the store.

Anyway, nothing that has been presented about Mountain Lion so far is final, and important details could change before release, so it’s no use getting too worked up based on the information we know today. But I am worried, very worried.

iOS lacks a document transfer system, as well

This is a follow-up of sorts to iOS lacks a document filing system, though it stands very well on its own.

I’ve never bought into the Free Software movement premise that, if only for all software we used we had the freedom to get its source code, the freedom to modify it as much as wanted, and the freedom to redistribute the modified version, then all would be good as we would be safe from investing in some system, then getting stuck with the vendor not providing the updates or bug fixes we want, without any recourse. I mean, this premise may be true, but in practice, while not always taken to these extremes this encourages software which is user-hostile and governed by the worst kind of meritocracies, so I am deeply skeptical the tradeoff is worth it for user-facing software.

However, I care a lot about a related matter, which is the transferability of documents (rather than source code). I consider it a fundamental freedom of the computer user that he be able to take the data he created out of the application he created it with, so that he may be able to use it with another application. This involves a number of things, in particular it’s better if the format is as simple as possible for the purpose, it’s better if it is documented, it’s better if the format has a clear steward for future evolutions, better yet if that steward is a standards body or consortium1. But the most important capability the user needs to have is the ability to take the raw file out of the application that created it. It is necessary, none of the other capabilities make any sense without it, and even in the worst case (undocumented, overcomplicated format) it is often sufficient given enough developer effort, especially if the aim is to extract an important part of the data (e.g. text without the formatting). This is the freedom zero of user data. Plus, if the user has this last resort ability, the app will tend to make sure it is at least not too complicated to do so, so as to improve the experience.

But on iOS, the user may not have even that. An app is entirely free to never allow export of user data (and thanks to the sandbox, other apps are not even allowed to get at the internal storage as a last resort). Or it could only allow export of, say, the flattened image, while the working document with layers remains detained by the creating app. On the Mac, on the other hand, not only can the user get at the underlying storage, but if an app wants to allow its documents to be moved in space (to another machine), then it necessarily has to save them in files and therefore allow them to be moved to another universe (another app). Meanwhile, on iOS iCloud document storage actually makes the situation worse, because now an app can allow its documents to be moved in local space (another of the user’s devices) without exposing itself to having the documents moved to outer space (a device belonging to someone else) or to another universe.

The sandbox is bad enough already for document transferability; in order to compensate what Apple should have done from the moment the iPad was available is have a real system for an app to offer one of its documents for sharing, the system would then handle making an email out of it, offering it to another app, or putting it on iCloud, etc.; then Apple should have strongly recommended this system be used in place of any ad-hoc document sharing (e.g. the app manually creating an email with a document attached). You might say this is precisely the kind of generic cover-all solution Apple is trying to get rid of, but I never said it would have to be a user-visible system. Rather, there would be specific ways for the user to initiate the various transfers; then in order to get the document out of the app, the system would call a callback on the app for it to give the document file path, without indicating what the system would be about to do with the document. And the kicker: iCloud would exclusively rely on this callback for documents to be provided to it, without any other way for the app to take advantage of iCloud document storage. So to have the “iCloud” feature, the app would have to (truthfully) implement this callback, and therefore would have no choice but to also allow its documents to be shared or transferred in this case.

Ownership of your creations is one advantage native apps have and that Apple could play over web apps (where the situation is so appalling it’s not even funny), but Apple hasn’t made a good job in this area so far. I hope it will change, because it will only matter more and more going forward.


  1. The two (Free Software and Free Data) are not entirely unrelated, though they are not as related as open source advocates would like you to think: source code is often a poor documentation for the file format; conversely, some of the best formats by these criteria, such as the MPEG4 container format or PostScript, have come from the closed-source world.

iOS lacks a document filing system

Since the beginning of 2010 when the iPad was released, there has been no end of debates over whether it is suitable for creating content, or whether it is primarily a “content consumption” (ugh) device (as if the choices were thus limited…). I am resolutely of the opinion that the iPad is an easel that very much supports serious creative endeavors given the right environment.

I unfortunately had (as you may have noticed) to qualify that last statement. Besides a few colleagues at work, two examples of iPad-using people that I base this statement on are the Macalope and Harry McCracken. And these examples have something in common: in all three cases, once the work is done, the documents are sent, handled, stored, etc. by either a corporate server, or a publishing CMS, or some other similar infrastructure. Here the iPad only needs to make a good job of storing the document for the time necessary to complete it; once done and sent, the document can even be removed from the device.

Let us contrast that with another situation. My father is a high school teacher; for the last 25+ years he has been working using computers, preparing teaching notes, transparent slides to project, diagrams, tests and their answers, student average note calculation documents, etc. on his Macs (and before that on an Apple ][e). He shares some of these with his colleagues (and back) and sometimes prints on school printers, so he is not working in complete isolation, but he cannot rely on a supporting infrastructure and has to ensure and organize storage of these teaching material documents himself. He will often need to update these when it’s time to teach the same subject one year later, because the test needs to be changed so that it’s not the exact same as last year, because the curriculum is changing this year, because the actual class experience of using them the previous year led him to think of improvements to make the explanation clearer, because this year he’s teaching a class with a different option so they have less hours of his course (but the same curriculum…), etc. Can you imagine him using solely an iPad, or even solely an imaginary iOS 5 notebook, to do so? I can’t. Let us enumerate the reasons:

  • Sure, one can manage documents in, say, Pages. But can one manage hundreds of them? Even with search this is at best a chore, and it’s easy to feel lost as there is no spatial organization; and search could return irrelevant results and/or not find the intended document because of e.g. synonyms.
  • If one remembers a document, but not the app which was used to create it, it’s hard to find it again, as the system-wide search in iOS cannot search in third-party apps (at least it couldn’t when this feature was released in iPhone OS 3.0, and I am not aware of this having changed), so one has to search each and every app where this document could have been made.
  • In some cases, for a project for instance, it is necessary to group documents created by different apps: sometimes there is no single app that can manage all the different media for a single project. On iOS these documents can only exist segregated into their own apps with no way to logically group them.
  • If there is a screwup, as far as I am aware it is not possible to restore a single document from backup, in fact it does not seem possible to restore a single app from backup, only full device restores, which may not be practical as it likely means losing work done elsewhere.

iOS needs a document filing system, badly.

The worst thing is, with the exception of file transfer in iTunes (which pretty much only shifts the issue to the computer, with some more overhead), the situation is the exact same as it was in iPhone OS 2.0 when third-party apps first became possible. iCloud solves exactly none of these problems: it is great to simplify working between your different devices, but it brings nothing to the single-device case. This has nothing to do with the hardware limitations of any iOS device, this is entirely the doing of the iOS software; in fact, while this is acceptable for the iPhone, I feel this gap already limits the potential of the iPad unnecessarily; and regardless of how you think it will happen (my take, which I will elaborate in a later post: Mac OS X is the new Classic), it is clear Apple has Big Plans for iOS, but it is hard to take iOS seriously for any device used for work if Apple hasn’t even shipped a first version of a document filing system, which is quite a design task and will require multiple iterations to get right for most people.

Now you may be wondering: does it really matter for working on iOS to depend a corporate, publishing, design studio, etc. infrastructure? Most people working on computers already work in the context of such an infrastructure. I think that yes, it does matter. Even if we admit that people working outside such an infrastructure are the exception rather than the rule, there are many of them, enough to prop up a competing platform (potentially the Mac) that would cater to their needs. Plus, sometimes such an infrastructure (e.g. in small businesses) may be unreliable, so it is a good idea to have a fallback. Moreover, it’s not really a good idea for Apple to make iOS dependent on such an infrastructure, as then Apple will not be able to control aspects of the experience it likely cares about, and will not be able to define, for instance, the modern notion of how to encapsulate user creations (I can imagine Apple getting past the concept of documents themselves and introducing something new), or how document typing information is represented. Whereas if iOS devices had a document filing system worthy of its name, but could also still be used in such an infrastructure as they can today, then Apple could define the rules and external infrastructure would follow the lead. Currently, iOS devices are more akin to terminals when it comes to working on them; not quite VT-100 or Chromebooks, but you get the idea.

When I see the absence of a user-visible traditional file system in iOS being lauded as some sort of brilliant new move, I’m scratching my head. It is a bold move, for sure, and not having something does represent accomplished work in the sense that it is a design decision, but honestly not having this feature is the easy part, creating a worthwhile replacement is the hard part, one that Apple has not shown even an interest in tackling. Moreover, the absence of a user-visible filesystem is nothing new. Indeed, back in the 80’s when computer GUIs were developed, two philosophies emerged for dealing with documents: a document-centric approach, where documents are at the center and applications are but tools which can each be used for a specific task on these documents, and an application-centric approach, where applications are the focus and documents only make sense within their context. The Apple Lisa, for instance, was document-centric: users would tear down from a stationery to create a document, which could then be operated on by tools. By contrast, the Macintosh (and everything it then inspired) was mostly application-centric. In this context, iOS merely is purely application-centric. Precedents of such systems exist, and include game consoles with memory cards for instance.

And was it really necessary to forego the filesystem in its entirety in the first place? Admittedly, it has become more and more complicated over the years, with documents being diluted by an ever increasing number of non-document files visible to the user, especially after the Internet and Web came to be. And, okay, even the Macintosh Finder at the origin did represent applications and system files along with user documents, and thus was not really a document filing system. However, was it really necessary to throw out the baby with the bathwater? It would have been feasible for iOS to feature a clean filesystem view with most everything invisible and various enhancements (like virtual folders and virtual filenames) so that it would only feature documents (in fact, I think the Mac OS X Finder in 2001 should have shown only the inside of the home folder, with applications launched from a Launchpad-like mechanism, but I guess a few things like the need to support Classic prevented that anyway). But maybe filesystems as users know them had truly become fatally tainted, and maybe it was indeed necessary to take a clean break from the past; in the end it doesn’t really matter either way, however it is not a good thing to forego something and put no successor for so long.

In the end, I am afraid Apple is not taking this aspect of the computing experience seriously, and is neglecting it. They ought to take it seriously, because it will matter, I think it will matter a lot in fact.

I explored a related aspect of document management in a followup — February 21, 2012

~ Reactions ~

Jesper (who, unbeknownst to me, had already touched some of these points, such as the specific notion of a document filing system) expands on the matter, also theorizing why the iOS group makes iOS be that way.

Unfortunately my knowledge of Magyar is exactly zero (and Google Translate is a bit hit and miss), but I’m sure Benke Zsolt is saying very interesting things.

I am honored that Lukas Mathis would link to me, but if I am mentioning it as a reaction it is because of the slightly overstated, but pretty good comparison he added.

A word about SOPA

The tech media is abuzz with news of a project called “SOPA”, and so I learned that the people of the United States of America, represented by their senators and representatives, are considering new legislation aimed at combatting digital piracy. It is not my position to criticize the decisions of the sovereign people of the USA over their domestic affairs. However, I urge the people of the USA and their representatives to seriously consider the impact of the proposed legislation over their international commitments before taking their decision.

For one, while filtering DNS entries for ISPs in the USA might seem it would only have a local impact, it would in fact seriously undermine the very infrastructure of the Internet, which is recognized to be a global infrastructure not belonging to any nation in particular.

Then, the broad and not too strict criteria for classifying a site in the proposed legislation mean rights holders in the USA would be given powers of enforcement much greater than they had in the past. Moreover, some rights holders have used existing tools in the past, such as DMCA takedowns, to target and block sites that were not engaged in intellectual property infringing activities, but rather in activities like parody, which is protected by free speech. Finally, adding to this the lack of any due process means that innovative sites from outside the USA would be exposed to a lot of risk of being blocked from a complaint by a competitor based in the USA, or being unable to collect money from USA citizens, with little recourse if this were to happen, which could be considered an impediment to free trade by the WTO.

People of the USA, I thank you for your attention and wish to send you my most friendly salutations.

Steve

I wasn’t sure I should write something, at first. Oh, sure, I could have written about the fact I didn’t dress specially thursday morning or didn’t bring anything to an Apple Store, as I thought for Steve I should either do something in the most excellent taste or nothing, and I couldn’t think of the former (and so I kicked myself saturday when I went to the Opera Apple Store to buy a Lion USB key, saw them, and thought “Of course! An apple with a bite taken out of it… dummy!”). Or I could have written about the fact he was taken from his families at a way too early age. Or about the fact, except for this one (and variants of this one, though one would have been enough), I was appalled by the editorial cartoons about the event (“iDead”? Seriously?). Or about a few obituaries I read or heard where the author put some criticism along with the praise (which by itself I don’t mind, honestly, he was kind of a jerk), but put in a way that suggested the good could be kept without the flaws, while for instance in an industry where having different companies responsible for aspects of the user experience of a single device is considered standard practice, being a control freak is essential to ensure the quality of the user experience that has made Apple a success. Or about how his presence in the keynotes during his last leave of absence (while on the other hand he stepped back from presentation duties during the previous one), and his resignation merely 6 weeks ago, both take on a whole new meaning today.

But at the end of the day, what would have I brought, given the outpouring of tributes and other content about Steve Jobs, many from people more qualified and better writers than I am? Not much. However, I read a piece where the author acknowledges the impact Steve Jobs had on his life, and I thought I should, too, pay my dues and render unto Steve that which is Steve’s, if only to help with the cathartic process. I hope it will contribute something for his family, his family at Apple, his family at Disney/Pixar, and the whole tech and media industries in this time of grief.

I was quite literally raised with Apple computers; from an Apple ][e to the latest Macs, there has always been Apple (and only Apple) hardware in the house, for which I cannot thank my father enough. As a consequence, while I had no idea who Steve Jobs was at the time, he was already having a huge impact on me. Not because I think he designed these computers all by himself, but because, by demanding seemingly impossibly high standards from the ones who designed them with him, or in the case of later Macs, by having made enough of a mark at Apple that the effect was (almost) the same, he ensured a quality of user experience way beyond that of any competitor, which allowed my young self to do things he wouldn’t have been able to do otherwise, and teaching him to expect, nay, demand similar excellence from his computing devices.

Then I started learning about him when he returned to Apple in 1997, from a press cautiously optimistic that the “prodigal son” could get Apple out of trouble, then how he spectacularly did so. I indirectly learned from him (in particular through folklore.org) that it requires a great deal of effort to make something look simple, that there is never good enough, merely good enough to ship this once (because on the other hand, real artists ship) and that the job of the software developer is to be in service of the user experience, not to make stuff that is only of interest to other software developers and remain in a closed circuit.

Imagining my life had Steve Jobs not made what he made is almost too ludicrous to contemplate. Assuming I would even have chosen a career in programming, I would be developing mediocre software on systems that would be as usable a mid-nineties Macintosh, if that, and would have very little of the elegance (come on: setting aside any quibble about who copied whom, do you think Windows or any other operating system would be where it is today were it not for the Mac to at the very least compete with it and make it do one better in the usability department?). And the worst thing is that I would have been content with it and considered it as good as it gets, and it would have been the same for almost all of my peers.

It’s thus safe to say that as far as my influences go, Steve Jobs is second only to my closest family members. By envisioning the future, then making it happen through leadership, talent and just plain chutzpah (for good or ill, it doesn’t seem to be possible to make people believe in your predictions of what the future will be made of, other than by actually taking charge and realizing it), he showed us what computers (and portable music players, and mobile phones, etc.) could be rather than what most people thought they could be before he showed us. And by teaching a legion of users, multiple generations of developers, and everyone at Apple to never settle for great but always strive for the best, he has ensured the continuation of this ethic for a few decades, at least (this is, incidentally, the reason why I am not too worried about the future of Apple, Inc.).

Thank you Steve. Thank you for everything. See you at the crossroads.

First Impressions of the Mac App Store

I try to be original in the subjects I tackle, but if you are a Mac user, there is no escaping the Mac App Store, which is probably the most important thing to happen to the Macintosh platform since Mac OS X, at least. It remains to be seen whether it will be in a good or a bad way, but for now, I’ve given it a test drive.

Trial Run

After uneventfully updating to 10.6.6 and launching the Mac App Store application, I decided to buy Delicious Library to catalog my growing collection of webcomic books (it’s not as big as the one Wil Shipley pimps in the Delicious Library 2 screenshots, but I’m getting there), and of course to get a feel of how the Mac App Store works for a paid application download, not just a free one. This was when I encountered the first issue:

Screen Capture of a Mac App Store dialog in French, with text being cut off in the middle

“effehargements”? I’m afraid I don’t know that word

Gee, are things starting well… I mean, did localizers get so little time to give feedback on the size of user interface elements that this couldn’t be fixed for release? Any other explanation I can think of would, in fact, be worse. I’m not going to focus on that too much since it’s likely to be fixed soon, but it’s a bad first impression to make.

After logging in with my Apple ID as instructed, I was unsurprisingly told I had new terms to accept. Less expected is the fact these terms are an extension of the iTunes Store terms and conditions; apparently the commercial relationship users of the Mac App Store have is an extension of the one most of us already have with iTunes, not an entirely new one or an extension of the Apple Online Store ones. The main reason, I guess, is that they can use the credit card already associated with your iTunes account, and any iTune Store credit you may have; plus, that way the Mac App Store benefits from the iTunes Store infrastructure (servers and stuff).

Of course, by the time I was done reading the terms, my session had expired; it’s as if they weren’t expecting you to read them… I’m noticing this everywhere, though, it’s not just Apple. So I logged in again, accepted the terms, and bought Delicious Library. As widely reported, the application then moved to the Dock with a nice, if slightly overdone, animation (sure, have an animation, but they may have used a simpler one), where it showed a progress bar while it downloaded, up until the download was complete, at which point it jumped once, and stayed in the Dock (while, behind the scenes, it had been put in the Applications folder). This may seem gratuitous, but to me this is indispensable for the buying/downloading experience, as opposed to the disconnected experience of downloading software on the Web.

I then tried out Delicious Library, entering a few books, etc. (unfortunately, I do not have a webcam attached to my Mac pro, so I had to enter the ISBNs by hand). I’m not going to get into a review of Delicious Library here, I just checked that the application was working correctly.

Then, I checked something I had been wondering about. Even though the Mac App Store will only work on Mac OS X 10.6.6 onwards, this is not necessarily the baseline for the apps bought on the Mac App Store themselves: apparently, they can support earlier releases of Mac OS X, including Leopard. Obviously, they cannot be bought from there, they have to be transferred from a Snow Leopard Mac where you bought them. But I was wondering how the computer authorization process (documented in various articles, like Macworld’s hands on, read just above “Work in progress”) would work on a Leopard machine where the Mac App Store cannot be installed.

So I took the Delicious Library application, and moved it to my original MacBook, which remains on 10.5 for a variety of reasons (I don’t have another Mac with Snow Leopard on hand, to test on pre-Mac App Store 10.6.5, unfortunately). When I connected my MacBook to the network (for the first time in the year), there was no update, which would have been necessary to add such support. And when I tried to run Delicious Library, this is what I got:

Delicious Library crash report, listing an “unknown required load command 0x80000022”

Uh oh, Wil

This error is, in fact, not related to the Mac App Store at all, it seems instead that the application relies on some other Snow Leopard-only feature, probably by mistake. Apparently, this build was never tested on Leopard. I double-checked, and the application does declare it can run on Leopard in the Mac App Store application, as well as in its property list (from which the Mac App Store information was probably generated). So, I went looking for a free app that would run on Leopard; Evernote fit the bill, so I downloaded it and transferred it. It ran without problem, however being a free app, it did not need to validate its license on the MacBook or anything of the sort, I would have to test with a paying app. Osmos declares it runs on Leopard (as early as Tiger, in fact, though it’s Intel-only, so not on a PowerPC machine), so I bought it (the things I’ll do for you people) and transferred it. But it didn’t run any better than Delicious Library, though for a different reason (it required a version of libcurl more recent than the one found in Leopard). So, it’s another app that hasn’t actually been tested on the baseline Mac OS X version it claims it supports, great. I stopped the expense there.

Note that a large majority of paid apps actually require Snow Leopard, if their Mac App Store listings are to be believed. I’d wager that none of the paid apps that declare otherwise were actually tested on Leopard, and that all paid apps actually require Snow Leopard and probably 10.6.6 to run correctly; anyone care to confirm otherwise? I have no intent on spending a bunch of money to test that theory.

General Criticism

Besides the events of this run, I want to make more general observations on the Mac App Store. Contrary to the music, movie, book, comic book, etc. industries, where digital distribution is a relatively new phenomenon, people have been selling computer software over the network (not even necessarily the Internet back in those days, think Compuserve, AoL, the numerous BBS…) – and making a living out of it – since the beginning of the nineties, if not earlier. And yet, even after 20 years, for the majority of Mac users the act of buying software still means the brick and mortar store, or at best, a mail-order store like Amazon. There is no household-name software that’s distributed mostly digitally, except for some open-source applications like VLC or Firefox, expander/viewer/reader companion apps, and rare successes like… uhh… I’m sure I’ll think of one eventually.

Welp, while my questioning of whether such software existed was rhetorical at the time, it turns out there is a piece of software that in fact qualifies: Skype; their unusual business model is irrelevant: indisputably, it is commercial software mostly distributed digitally. This goes to show that when you solve a very practical problem with killer tech, you can overcome the barrier between digital distribution and the mainstream Mac market; that being said, it remains a hard problem for anyone else. – May 22, 2012

I’ve said the Mac App Store is probably the most important thing to happen to the Macintosh platform since Mac OS X, and that’s because it promises to provide at last a way to distribute software outside of the brick and mortar stores, that the rest of us will actually use; this, in turn, will allow developers who do not have the means to distribute their products in stores to access the majority of Mac users; of course, virtual or physical, shelf space and attention remain limited, but now we can avoid a hugely inefficient step in the middle.

Since the Mac App Store will set the expectations of Mac users for years to come, how it works, what it allows users, the kind of software found on it, etc., are extremely important, not just for Apple in the short run, but for the health of the platform in many years down the line. To me, the Mac App Store delivers in the main area it was supposed to: provide a great, integrated, end-to-end buying/downloading experience. However, it falls short to a smaller or greater extent in all other areas.

Let’s begin by the design. It’s a straight port of the “App Store” iPad app. Really, couldn’t they have done better? Surely, they could have made better use of the space afforded by the desktop, instead of using the strict iPhone/iPad tabbed design. Why have one entire tab to the updates, couldn’t this be put in a notification area in all modes? And breadcrumbs? Are they forbidden now? But the worst is surely that weird window title bar, with no title, and the stoplight window controls in the center left of the bar; I mean, is space at such a premium that they couldn’t have gone with a traditional unified title and toolbar design? It would have worked very well with the Panic toolbar design! To add insult to injury, these “toolbar tabs that go to the top of the title bar” are actually click-through! Argh! Now not even the top center of a window is safe for clicking (the worst thing is, I was already instinctively avoiding them when clicking to bring the Mac App Store window to the foreground, showing how thoroughly pervasive click-through has already damaged my computer habits).

As I’ve said, the Mac App Store provides a good, more importantly connected experience, from the buying intent to the moment the app is ready to use in the Dock. I’ve heard some complain about this automatic Dock placement, but to me this is not a problem, or to be more accurate this is not the problem with it. If you think about it, this policy actually is the most efficient: as it stands if, in the minority of cases, you don’t want to regularly use the application you just bought, you can just drag it out of the Dock; otherwise, you do nothing. The alternatives are not putting it automatically, in which cases in the majority of cases you are going to fetch the newly bought app from the Applications folder to put it in the Dock (which is more work than dragging an application out of the Dock), or asking you each time, in which case every time you have to read a dialog, choose on the spot, and click; and let’s not mention having a preference. The same goes for automatic placement in the Applications folder. Yes, I know browsers have these kind of options (Downloads folder/Desktop/ask each time), but that’s mostly because of historical reasons, your not necessarily expecting to be downloading something, and the wide variety of things you could be downloading from a browser.

But that’s from the perspective of an experienced user. For user actions, and doubly so when actions are made to happen “automatically” like that, the way to undo the action should be obvious from the way it was done (or shown, animations are very useful for that); I don’t mean the way to reverse immediately if the action was a mistake (the undo command is here for that), but the way the action can be reversed later if so desired. Here the way to “undo” the Dock placement remains reasonably obvious (drag it out of there), but users are going to think it gets rid of the application. Besides the fact this not the case, users will be reluctant to move applications out of the Dock for fear of not being able to find them again, and will keep them all in there. Yeah, I know, Mac OS X Lion and the Launchpad are supposed to solve that, but they’re not there yet, and in the meantime, the Mac App Store is here and users will use it. People do not get confused by however complex the system is underneath (do many even suspect that applications are in fact folders containing the binary and support files? No.), but by “innovations” that purportedly simplify some aspect of the task while leaving some or most of the complexity still visible elsewhere.

Besides the way the Mac App Store application currently works, there are issues with what the Mac App Store enables, or to be more accurate, does not enable.

For long, developers have asked for a way to update their applications as part of the (Apple Menu)→Software Update command, or to get access to the crash reports from their applications that were sent to Apple (though the issue was more that the “send the crash report to Apple” feature gave the expectation that the developer could do something about it or was notified of the issue). But I’ve always felt that this could not be done without Apple and the developer being in a tighter relationship, because of the potential spoofing and security issues that could occur; and now the Mac App Store is that relationship. However, there are Mac App Store improvements that could be given to non-Mac App Store applications (and it’s in the long-term best interest of the Mac platform that this option remains viable); for instance, it’s been a long time since distribution through a disk image was cutting edge, and Installer packages are too interaction-heavy. It’s not possible to have one-click download and installation from the web for obvious security reasons, but couldn’t Apple make available an application packaging method that can be downloaded, then, when double-clicked, would ask something close to the quarantine question, possibly show an EULA (as disk images can do), then install the app in the Application folder, show where it is, and discard the package, without any further interaction? I’m sure plenty other improvements of the sort could be made.

I also take issue with many Apple policies with the Mac App Store. Many of them are the exact same complaints developers have had about the iOS App Store (with the exception, of course, of the inability to distribute applications outside of it; developers can distribute betas and other special versions of the application however they want); while they may seem developer complaints that users shouldn’t care about, most of them disrupt the relationship between users and developers, resulting in a lose-lose situation. These issues are, among others: not inclusive enough (for instance, applications cannot install kernel extensions; why have that facility then?), no customer information whatsoever, user “review” system that gives the expectation developers can give tech support on them even though they can’t, still no “unfiltered Internet access” rating, no support for upgrade pricing, and most of all, no real support for demos/try before you buy.

That last one is the most infuriating. Apple is showing all Mac users a more practical alternative to shrink-wrapped software stores, and the policy is still that you have to buy with your eyes closed, only on the basis of a description, a few screenshots, and “reviews” that… could be better? Frak! And don’t tell me this demo business is confusing, people get to try before they buy in real life all the time: with TVs, consoles, audio systems, etc. in the electronics store; with clothes, shoes, etc.; with cars in their auto dealer, etc, etc, etc. Do I need to go on? I’ve always been suspicious of the “experience optimized for impulse buying” argument for the absence of real demos on the iOS App Store (it seems to me there are already plenty of apps at impulse buy prices, so it would be a good idea to encourage non-impulse buy prices), but here on the Mac App Store it makes no sense at all. Oh, sure, developers can distribute a demo from their web site, but it feels about as disconnected as a broken wire. This, alone, will ensure that I will rarely, if ever, buy again from the Mac App Store; not because I’m going to go out of my way to avoid using it, but because I’ll always be afraid of wasting my money on something useless, as I never buy on impulse. Practically all the downloaded software I own, I bought it after trying it, and I’m not going to start changing that now; that would be going… backwards, back at the time of brick and mortar stores, precisely those the Mac App Store is supposed to obsolete.

By the way, in case you have an iOS device and want to encourage “try before you buy”, there is a simple way: go to the “try before you buy” iTunes badge, to mark this as an iTunes store link featured group, download 10-20 of them that seem interesting to you, and try them out. That’s it, that’s all I’m asking of you: there is bound to be a few that you will like and where you will buy the complete version; this, in turn, will send Apple the message that yes, we do want to try apps before we buy them.

I’m deeply torn about the Mac App Store; not just how it currently is, but the whole principle of it. As it currently is, it works and will be used without a doubt, while having a number of issues and setting a number of bad expectations. While I have no doubt many issues will be fixed, Apple has been pretty stubborn about some of them (I mean, for how long have we been asking for a trial system on the iOS App Store?). And there needs to be life outside the Mac App Store, but Apple seems utterly uninterested in improving anything there.

Kinect User Interaction Design

I don’t own a Kinect or an Xbox 360 (and I don’t intend to buy either), but I’ve recently read very interesting stuff about the user interaction design issues it has raised, even for “just” game menus.

First thing, Penny Arcade’s Tycho (as it happens) reports his initial impressions (fourth paragraph), which are that it’s all over the place. No two games behave the same. (as an aside, it’s not every day you see Penny Arcade writing about usability.)

Second, Ars Technica has a very interesting article about how Harmonix apparently got it right with their game Dance Central. How they did so will not be a surprise to any of us Mac/iPhone nerds: they prototyped, and iterated, and  prototyped, and iterated, and  prototyped, and iterated, and…

While every console or computer game, or at least every game genre, has for obvious reasons its own user interaction rules when playing the game itself, on the other hand you generally expect the rules for menus to be consistent from game to game, including across platforms; game menus even share some conventions with desktop software. But the Kinect is a fundamentally new user input mechanism, for which there is practically no reference (when your best reference is Minority Report, you know you have a lot of work ahead of you). It’s not every day, or even every year, but on average around every decade that you see such a fundamentally new user input mechanism for electronic devices come up; for all time, I count only seven: “buttons, sliders and dials”, keyboard, mouse, gamepad, touchscreen (which only started realizing its potential with multitouch), Wiimote, and Kinect. I’m not counting steering wheels, joysticks and light guns, as these are used on electronic devices only to provide a simulation of the “real” ones, neither do I count remotes, which are just  “buttons, sliders and dials” that operate remotely.

So with such a new, unexplored user interaction continent, you’ve got to wonder why Microsoft didn’t do the job they should have done as the platform owner, by which I mean doing the research Harmonix had to do themselves, sharing the results with the developers of Kinect games, and applying the lessons to their own titles to set the example. If there’s something they should have taken from Apple’s and Nintendo’s playbook, it’s this. Maybe I shouldn’t be surprised given how much Microsoft application themselves are the worst violators of what little user interface guidelines Windows has, but at the same time, isn’t the Xbox from a completely different part of Microsoft?

At any rate, it will be very interesting to see how this will develop in the future.

Raising the Level of Discourse

There has been a worrying trend of late regarding criticism of Apple, and how Apple responds to it.

You’re no doubt aware that Apple has tried to increase and improve its communication in recent years, especially in response to criticism; besides, of course, the open letters from Steve Jobs, we have for instance the outreach of Phil Schiller to the community or the iPhone 4 antenna press conference. This is in itself a good thing; in the worst case at least you know their viewpoint, which furthers the debate, while in previous years you would know absolutely nothing.

The problem, however, is that Apple is often responding to the wrong criticism.

For instance, a lot of time in the iPhone 4 antenna press conference was spent repeating that all phones have their signal reception affected when held, that the iPhone 4 is no worse, that Apple does extensive testing, both in their labs and in the field, including in low coverage areas. This was to counter the allegations from some of the press that was screaming bloody murder at Apple over the “obviously defective” antenna, and accusing Apple of only having used the device in areas of good coverage, while that press had few, if any, hard facts to back these up. But anyone with a bit of sense already suspected or knew that the matter was a bit more subtle, and was following AnandTech’s excellent coverage and testing instead. This is the criticism Apple should have responded to instead; OK, sure, spend the first few minutes addressing the basics and the dumb criticism, but then move on to the specifics of the matter: namely, why they went ahead with such a new and innovative (and thus risky) external/structural antenna design when it could make the problem worse by allowing actual electrical contact (and maybe, additionally, why they didn’t mitigate the risk by adding a layer of insulating coating over the stainless steel). They could have answered in a number of ways. But they did not address that question. And none of the journalists who had the opportunity to ask that question did so.

The point is not to put Steve Jobs or Apple on trial, but to keep them honest. And yet, in this press conference everyone remained at a low level of discourse. I expect there will always be a significant proportion of the tech press that will happily remain at this level, unable to climb higher simply because they try to cover everything under the Sun without the means to cover this immensity with any real depth; I just wish this proportion didn’t seem to be the majority (so we should all encourage outlets that provide quality coverage!). However, I do not forgive Apple for not trying and raising to a higher level.

Something similar happened at the WWDC keynote. During the keynote Steve Jobs took some time to defend the iOS App Store review process (see “The Low Point of the Keynote”), which is okay in itself: the review system has attracted criticism, but there are points to be made in its favor. However, he tried to defend it by telling that 95% of rejections were for three reasons: the app crashes, it uses private API calls, or it doesn’t work as advertised. But it’s meaningless to lump all the rejected apps together; and it’s a fallacy to say that, since an overwhelming majority of the apps in this slightly artificial group fail to meet basic requirements (apps which were most likely coded by novice, careless, or dishonest developers) such that the other reasons are only a small fraction, then the other reasons are only a small problem. But that fallacy was clearly the implication Steve seemed to make; in the best case, that was the wrong criticism to address. Honestly, given the stuff that makes it to the iOS App Store, I’m surprised these reasons don’t account for 99% of rejections. Here again, Apple addressed a straw man; to be fair, some of the press puts a lot of straw men in front of Apple, but that’s not reason for Apple to take the bait.

So in the end, “interaction” between Apple and that press ends up looking like this:

Apple: Does not!
Press: Does too!
– Does not!
– Does too!
– Does not!
– Does too!

And even then, that’s still better than the common case where Apple doesn’t comment, leaving that kind of press feeling “slighted”, and that “the people” are not being “heard”:

Press: Does too! Does too! Does too! Does toooooooo!

This kind of stuff is all the more disheartening as Apple sometimes gets it right. For instance, in his Flash open letter, Steve Jobs not only addressed the obvious, but also addressed the less obvious criticism, by saying that even if they were to support it, current Flash content wouldn’t work well anyway given the lack of a pointer, and if it would require publishers to rewrite their content, why not rewrite it in HTML5? Not to mention Flash itself was designed with the PC in mind, not a touchscreen. And let’s not forget the original open letter, Thoughts on Music, which addressed a lot of points and issues that most people (and most of the press) had not even thought about.

Pretty often, criticism of Apple originates from a legitimate concern, but by the time it gets through the tech press hype machine, it has become an horribly distorted version of the original criticism; and I’m afraid people at Apple get the feeling they are taken to task for reasons that are entirely unjustified, based on this distorted criticism (while the original criticism is lost in the noise), leading them to believe nobody understands them.

Such misunderstandings are not uncommon, even without the distortion machine: for instance in the Ninjawords saga, Phil Schiller answered accusations that Apple required Ninjawords to be censored, by telling that this was something the developer did after an initial rejection, and Apple did not ask the developer to do so. Which was technically true, but as one of the developers pointed out, by having other, uncensored dictionaries in the iOS App Store at the 4+ rating, and at the same time requiring Ninjawords to have a 17+ rating, Apple was in effect putting a lot of pressure for Ninjawords to censor itself, as “who wants to be the only illicit dictionary on the [iOS] App Store?” So while Apple saw A: that they were enforcing the rating on Ninjawords (and while there may be a problem of ratings being inconsistently enforced, from their viewpoint this is none of the developer’s business anyway), the Ninjawords developers saw B: that they were, in effect, being made to censor the application.

A misunderstanding (or many) also probably explains Steve Jobs’ “Some people lie” comment at the D8 conference. Either he refers to cases that no one (or few people) was disputing in the first place, or he refers to developers who went to the press claiming an equivalent of B, while Apple viewed it as an equivalent of A.

Even if Apple feels it is wrongly criticized for, say, doing X, if only they would answer “Of course we do X, it seems obvious to us why, but here are three good reasons for us to do so”, then it would silence the press that made the dumb criticism, while allowing more serious outlets to follow up with “Yes, but then why do you do X even when Y?” Through communication the real issues that are lost in the noise can be revealed.

To improve this state of affairs, I only see one solution.

We need a Penny Arcade of Apple and the tech industry in general.

You have probably heard of Penny Arcade, and know it to be a funny, topical, popular webcomic skewering the video game industry, the video game press, and “gamers” themselves;  something you’d find in a newspaper covering video games if such a thing existed, playing an equivalent role as that of the editorial cartoons in the newspapers (except, you know, actually good and funny). What you may not know is the influence it has on the video game industry in general. In the foreword to their second collection, J. Allard (at the time in charge of the Xbox at Microsoft) describes Penny Arcade as accomplishing much more than the typical webcomic: for him, Tycho and Gabe do nothing less than keep the video game industry honest. Quoting Allard: “PA doesn’t buy it, and they don’t sell it. They tell it like it is. Whether it’s in their strips, their rants, commentary in their books, a direct flame-war, or a well-timed onomatopoeia in an elevator at E3, you can count on their presence if you’re doing something in this industry.” He goes on to mention their other endeavors, like the PAX expo and Child’s Play charity, as what they’ve been able to accomplish that the “industry” overlooked.

Now, J. Allard may have been trying to find the only good thing he could say from his viewpoint about the two guys who are basically lampooning his work and everything he holds dear, and may have come up with this. After all, you don’t (typically) say bad things about the authors of a book you’re being asked to write the foreword of. But there are hints and elements elsewhere (though they are not expressed as well as in that foreword) that confirm this influence to be the case.

It’s certainly counter-intuitive to propose caricature as being the solution to bad communication, a hyping press, and distorted criticism, these seem to be caricatural themselves already! And that’s precisely why caricaturists are needed to point this out. Remember, good satire makes you laugh, then makes you think. Moreover, good satire, having the appearance of just funny pictures/words, spreads subversively, including in the targeted institution (be it Microsoft, Apple, the tech press, etc.), delivering its message from the inside: while these institutions may dismiss criticism they see coming from the outside as attacks, good satire is read by the rank and file, spreading from there. Notice that I don’t think this satire needs to be a webcomic, it could take other forms, though I think a webcomic has the most inherent advantages.

Now before you go ahead and fire up your email client to tell me how about Z is totally the Penny Arcade of Apple and the tech industry and shame on me for not knowing about it, let me preempt most of you by saying that, yes, I know about the Joy of Tech, Mosspuppet, Fake Steve Jobs, PC Weenies, Daring Fireball, the Macalope, Crazy Apple Rumors, the Onion, and the Oatmeal, and I do not think this equivalent is to be found within them. And while Penny Arcade itself sometimes covers tech topics (especially, read this, starting from the third paragraph, and tell me how it couldn’t perfectly be read as though it was about the Mac App Store,  incidentally announced a few days beforehand), it does not do so with enough regularity to play more than a minor role in the tech industry; and I don’t think this will change much.

What should the  Penny Arcade of Apple and the tech industry be? It needs to be good, obviously, and it needs to satirize technology because its author(s) love technology. It needs to be topical. It needs to be regularly published to an extent, so that people keep coming back to it. As you may have gathered, it needs to cover not just Apple, but also its competitors: I rag on Apple, and that’s because I care, but its competitors have their own issues (similar or different), and it’s only fair that all of them be targeted; also, while there is a lot of material you could make about Apple, I don’t think it would be enough to keep, say, a three days a week webcomic running viably. As I said, besides the video game industry Penny Arcade also satirizes the corresponding press and users, so its equivalent would need to target the tech press and tech fans as well. It needs to be popular, but that will happen if it’s actually good. It needs to be subversive, being ostensibly funny while having actual substance.

With all the webcomics and blogs that get created (and often quickly die) all the time, why doesn’t such a thing already exist? I guess because it’s hard. It’s already a miracle that Penny Arcade exists, there are very few like it, and none as good. It’s hard in part because it needs to be topical, which precludes any comic buffer. It’s also hard to be good at doing such a thing. And it’s hard to love technology, while relentlessly skewering technology, the people responsible for this tech, the press talking about this tech, and your fellow tech fans.

In my opinion the closest thing we currently have to a Penny Arcade of Apple and the tech industry is Fake Steve Jobs. Dear Leader mercilessly takes on all the companies in this space, as well as the old dying press, these upstart bloggers, the fanboys, the frigtards, and the clueless. He’s funny, insightful, and oh so good. The main problem is that his subversive power is limited for two reasons: first, the caricature aspect is too salient, by very nature of the character; before you read the first word of a post, you know it’s going to be a satire of some sort. Second, it’s easier for the creator to make his work pretend to be harmless humor using pictures (especially for those looking over your shoulder) than it is with prose, again limiting the subversive aspect; this in turn makes it hard for the message to penetrate Apple and the others from the inside. Hence, Fake Steve is the closest we have, but he is not the Penny Arcade of Apple and the tech industry in my opinion.

Lastly, I want to give a shout out to the Satiritron, which could end up fitting the bill, from the fine folks behind Mosspuppet. It launched while I was writing this post, and it’s too early to tell how it’s going to do in the long haul, but it’s off to a good start so far, and I wish it best of luck and many faithful visitors!

It’s stunning what you learn about your iPhone while in holidays

I should go in holidays more often. You find out interesting things about your iPhone when you go outside the urban environment it was mostly designed for. I’m not ready to talk about the tests I mentioned earlier, but here’s a few other observations I can share…

First, the iPhone, or at the very least the iPhone 3GS which is the model I own, seems to have trouble getting a GPS fix in cloudy weather. If obtaining a location regardless of weather is of any real importance, a dedicated GPS device is still required.

Second, if you’re not going to have access to a power outlet for, say, one week, switch your device to airplane mode, it’s just as efficient and more practical than turning it off. Let me explain. I was for a week in remote parts of the Alps, trekking from mountain refuge to mountain refuge; even those that have some electricity from a generator are unlikely to have power outlets. Furthermore, in that environment you often don’t get any signal, or if you do it’s very weak, so a lot of battery is going to be wasted looking for a signal or maintaining a weak connection. So last year, I simply turned off my iPhone so as to conserve battery for the whole week. However, it was not very practical as I had to wait for it to boot each time I wanted to use it, which wasn’t very fast… So this year, I put it in airplane mode instead of turning it off. This turns off the radios and leaves it consuming apparently very little power; but it was ready much faster when I wanted to check whether there was any signal, or test my application, or show off something, and it still had juice at the end of the week.

Lastly, and this is more for developers: even if your app requires location, you may not always get true north if there is no data connection, so be sure to always handle the lack of true heading and fall back to the magnetic heading. As you know, a compass does not point exactly to the North Pole (in this context also referred to as geographic north), but to a point called the magnetic north pole, located somewhere in Greenland (in fact it is even more complicated than that, but let’s leave it at that). The iPhone 3GS and iPhone 4, both featuring a magnetometer, cannot give you true north using only that sensor any more than a compass can; however, if the device also has your location, it can apply the correction between magnetic north and true north directions at that point and give you the true north; this is well documented in the API documentation. However, while your location is necessary, it is not sufficient! I have observed that if I don’t have any data connection, I only get magnetic north, even if I just got a GPS fix; the device probably needs to query a remote database to get the magnetic north correction for a given point. So if your application uses heading in any way, never assume you can have true north, even if you know you have location; always handle the lack of true north and fall back to magnetic north in that case, mountain trekkers everywhere will thank you.