Proposal for a standard plain text format for iOS documents

Since the last times we visited the matter of working with documents on iOS, I have read with great interest more write-ups of people describing how they work on the iPad, because of course it is always good to hear about people being able to do more and more things on the iPad, but also because (as John Gruber so astutely noted) Dropbox almost always seems to be involved. I don’t feel that Dropbox solves the external infrastructure problem I raised in my first post on the matter, I consider Dropbox external infrastructure as well, if only because it requires you to be connected to the Internet to merely be able to transfer documents locally on your iPad (and that’s not a knock on Dropbox mind you, this is entirely the doing of restrictions Apple imposes).

I am going to concede one advantage the current de facto iOS model of documents in a per-app sandbox plus next to that an explicit container for document interchange, which is that it forces apps to actually consider support of interchange document formats. With the Grand Unified Model, and whatever we call the model Mac OS X now uses since Snow Leopard, applications would first only concern themselves with creating documents to save the state of the user’s work for them to pick it up later, without concern for other applications; and when the authors of the applications would come to consider standard formats, or at the very least creating an interchange format without data that are of no interest to another app (e.g. which tool was selected at the time the image was saved) or would amount to implementation details, they would realize that other applications had managed to slog through their undocumented document format to open it, and as a result the authors did not feel so pressured to support writing another document format. The outcome is that the onus of information interchange falls only on the readers, which need to keep adding support for anything the application that writes the document feels like adding to the format, in the way it feels like doing so.

However, with the de facto model used by iOS, apps may start out the same way, but when they want to claim Dropbox support, they have damn well better write in there documents in a standard or documented interchange format, or their claims of Dropbox support become pretty much meaningless. I am not sure the tradeoff is worth it compared to the loss of being able to get at the original document directly as a last resort (in case, for instance, the document exchanged on Dropbox has information missing compared to the document kept in the sandbox), but it is indeed an advantage to consider. An issue with that, though, is that as things currently stand there is no one to even provide recommendations as to the standard formats to use for exchanging documents on iOS: Dropbox the company is not in a position to do so, and as far as Apple is concerned document interchange between iOS apps does not exist.

So when I read that the format often used in Dropbox to exchange data between apps is plain text, while this is better than proprietary formats, this saddens me to no end. Why? Because plain text is a lie. There is no such thing as plain text. Plain text is a myth created by Unix guys to control us. Plain text is a tall tale parents tell their children. Plain text is what you find in the pot at the end of the rainbow. Plain text is involved in Hercules’ labors and Ulysses’ odyssey. Perpetual motion machines run on plain text. The Ultimate Question of Life, the Universe and Everything is written in plain text.

I sense you’re skeptical, so let me explain. Plain text is pretty well defined, right? ASCII, right? Well, let me ask you: what is a tab character supposed to do? Bring you over to the next tab stop every 4 spaces? Except that on the Mac tab stops are considered to occur every 8 spaces instead (and even on Unix not everyone agrees). And since we are dealing with so-called plain text, the benefit of being able to align in a proportional context does not apply: if you were to rely on that, then switch to another editor that uses a different font, or switch the editing font in your editor, then your carefully aligned document would become all out of whack. Finally, any memory saving brought by the tab character has become insignificant given today’s RAM and storage capacities.

Next are newlines. Turns out, hey, no one agrees here either: you’ve got carriage return, line feed, the two together (and both ways). More subtle is wrapping… What’s this, you say? Editors always word wrap? Except piconano, for instance, doesn’t by default. And Emacs, in fact, does a character wrap: by default it will cut in the middle of a word. It seems inconsequential, but it causes users of non-wrapping editors to complain that others send them documents with overly long lines, while these others complain that the first guys write lines with an arbitrary limit, causing for instance unsightly double-wrapping when used on a window narrower than that arbitrary width.

And of course, you saw it coming, comes the character encoding, we have left the 7-bit ASCII world eons ago. Everything is Unicode capable by now, but some idiosyncrasies still remain: for instance as far as I can tell out of the box TextEdit in Mac OS X still opens text files in MacRoman by default.

This is, simply, a mess. There is not one, but many plain text formats. So what can we do?

The proposal

Goals, scope and rationale (non-normative)

The most important, defining characteristic of the proposal for Standard Plain Text is that it is meant to store prose (or poetry). Period. People might sometimes happen to use it for, e.g. source code, but these use cases shall not be taken into considerations for the format. If you want to edit makefiles or a tab separated values file, use a specialized tool. However, we do want to make sure that more specialized humane markup/prose-like formats can be built above the proposal, in fact for instance Markdown and Textile over Standard Plain Text ought to be able to be trivially defined as being, well, Markdown and Textile over Standard Plain Text.

Then, we want to be able to recover the data on any current computer system in case of disaster. This means compatibility with existing operating systems, or at least being capable of recovering the data using only programs built in these operating systems.

And we want the format to be defined thoroughly enough to limit as much as possible disagreements and misunderstandings, while keeping it simple to limit risks of mistakes in implementations.

Requirements

Standard Plain Text files shall use the Unicode character set, and be encoded in UTF-8. Any other character set or encoding is explicitly forbidden.

This seem obvious, until you realize this causes Asian text, among others, to take up 50% more storage than it would using UTF-16, so there is in fact a tradeoff here, and compatibility was favored; I apologize to all our Japanese, Chinese, Korean, Indian, etc. friends.

Standard Plain Text files shall not contain any character in the U+0000 – U+001F range, inclusive, (ASCII control characters) except for U+000A (LINE FEED). As a result, tabulation characters are forbidden and the line ending shall be a single LINE FEED. Standard Plain Text files shall not contain any character in the U+00FF – U+011F range, inclusive (DELETE and C1 range). Standard Plain Text files shall not contain any U+FEFF character (ZERO WIDTH NO-BREAK SPACE aka byte order mark), either at the start or anywhere else. All other code points between U+0020 and U+10FFFF, inclusive, that are allowed in Unicode are allowed, including as-yet unassigned ones.

Standard Plain Text editors shall word wrap, and shall support arbitrarily long stretches of characters and bytes between two consecutive LINE FEEDs. They may support proportional text, but they shall support at least one monospace font.

These requirements shall be enforced at multiple levels in Standard Plain Text editors, both at the user input stage and when writing to disk at least: pasting in text containing forbidden characters shall not result in them being written as part of a Standard Plain Text file. Editors may handle tabulation given as input any way they see fit (e.g. inserting N spaces, inserting enough spaces to reach the next multiple of N column, etc.) as long as it does not result in a tab character being written as part of a Standard Plain Text file in any circumstance.

Standard Plain Text files should have the .txt extension for compatibility. No MacOS 4-char type code is specified. No MIME type is specified for the time being. If a Uniform Type Identifier is desired, net.wanderingcoder.projects.standard-plain-text (conforming to public.utf8-plain-text) can be used as a temporary solution.

Clearly this is the part that still needs work. Dropbox supports file metadata, but I have not fully investigated the supported metadata, in particular whether there is a space for an UTI.

Appendix A (non-normative): recovery methods

On a modern Unix/Linux system: make sure the locale is a UTF-8 variant, then open with the text editor of your preference.

On a Mac OS X system: in the open dialog of TextEdit, make sure the encoding is set to Unicode (UTF-8), then open the file. Being a modern Unix, the previous method can also be applied.

On a modern Windows system (Windows XP and later): in the open dialog of Wordpad, make sure the format to open is set to Text Document (.txt) (not Unicode Text Document (.txt)), then open the file. Append a newline then delete it, then save the file. In the open dialog of Notepad, make sure the encoding is set to UTF-8, then open the latter file.

The reason for this roundabout method is that Wordpad does not support UTF-8 (Unicode in its opening options in fact means UTF-16) but supports linefeed line endings, while Notepad does not support linefeed line endings. Tested on Windows XP.

Patents

Patents and their application to software have been in the news lately: Lodsys and other entities that seem to have been created from whole cloth for that sole purpose are suing various software companies for patent infringement, Android is attacked (directly or indirectly) by historical operating system actors Apple, Microsoft and Oracle (as owner of Sun) for infringing their patents, web video is standardized but the codec is left unspecified as the W3C will only standardize on freely-licensable technologies while any remotely modern video compression technique is patented (even the ostensibly patent-free WebM codec is heading towards having a patent pool formed around it).

Many in the software industry consider it obvious that not only a reform is needed, but that software patents should be banned entirely given their unacceptable effects; however I haven’t seen much of a justification of why they should be banned, as often the article/blog post/editorial defending this position considers it obvious. Well, it is certainly obvious for the author as a practitioner of software, and obvious to me as the same, but it’s not to others, and I wouldn’t want engineers of other trades to see software developers as prima donnas who think they should be exempted from the obligations related to patents for no reason other than the fact it inconveniences them. So here I am going to expose why I consider that software patents actually discourage innovation, and in fact discourage any activity, in the software industry.

Why the current situation is untenable

Let’s start by the basics. A patent is an invention that an inventor, in exchange for registering it in a public office (which includes a fee), is given exclusive rights to. Of course, he can share that right by licensing the patent to others, or he can sell the patent altogether. Anyone else using the invention (and that includes an end user) is said to be infringing the patent and is in the wrong, even if he came up with it independently. That seems quite outlandish, but it’s a tradeoff that we as a society have made: we penalize parallel inventors who are of good faith in order to better protect the original inventor (e.g. to avoid copyists getting away with their copying by pretending they were unaware of the original invention). Of course, if the parallel inventor is not found to have been aware of the original patent, he is less penalized than if he were, but he is penalized nonetheless. The aim is to give practitioners in a given domain an incentive to keep abreast of the state of the art in various ways, including by reading the patents published by the patent office in their domain. In fields where the conditions are right, I hear it works pretty well.

And it is here we see the first issue with software patents: the notorious incompetence of the USPTO (United States Patent and Trademark Office)1, which has been very lax and inconsistent when it comes to software patents, and has granted a number of dubious ones; and I hear it’s not much better in other countries where software patents are granted (European countries thankfully do not grant patents on software, for the most part). One of the criteria when deciding whether an invention can be patented is whether it is obvious to a practitioner aware of the state of the art, and for reasonably competent software developers the patents at the center of some lawsuits are downright obvious inventions. The result is that staying current with the software patents that are granted is such a waste of time that it would sink most software companies faster than any patent suit.

Now, it is entirely possible that the USPTO is overworked with a flood of patent claims which they’re doing their best to evaluate given their means, and the bogus patents that end up being granted are rare exceptions. I personally believe the ones we’ve seen so far are but the tip of the iceberg (most are probably resting along with more valid patents in the patent portfolios of big companies), but even if we accept they are an exception, it doesn’t matter because of a compounding issue with software patents: litigation is very expensive. To be more specific, the U.S. patent litigation system seems calibrated for traditional brick and mortar companies that produce physical goods at the industrial scale; calibrated in the sense of how much scrutiny is given to the patents and the potential infringement, the number of technicalities that have to be dealt with before the court gets to the core of the matter, how long the various stages of litigation last, etc. Remember that in the meantime, the lawyers and patent attorneys gotta get paid. What are expensive but sustainable litigation expenses for these companies simply put most software companies, which operate at a smaller scale, out of business.

Worse yet, even getting to the point where the patent and the infringement are looked at seriously is too expensive for most companies. As a result, attackers only need to have the beginning of a case to start threatening software developers with a patent infringement lawsuit if they don’t take a license; it doesn’t matter if the attacker’s case is weak and likely to lose in court eventually, as these attackers know that the companies they’re threatening do not have the means to fight to get to that point. And there is no provision for the loser to have to pay for the legal fees of the winner. So the choice for these companies is either to back off and pay up, or spend at least an arm and a leg that they will never recover defending themselves. This is extortion, plain and simple.

So even if bogus patents are the exception, it is more than enough for a few of them to end up in the wild and used as bludgeons to waylay software companies pretty much at will, so the impact is disproportionate with the number of bogus patents. Especially when you consider the assailants cannot be targeted back since they do not produce products.

But at the very least, these issues appear to be fixable. The patent litigation system could be scaled back (possibly only for software patents), and, who knows, the USPTO could change and do a correct job of evaluating software patents, especially if there are disincentives in place (like a higher patent submission fee) to curb the number of submissions and allow the USPTO to do a better job. And one could even postulate a world where software developers “get with the program” and follow patent activity and avoid patented techniques (or license them, as appropriate) such that software development is no longer a minefield. But I am convinced this will not work, especially the latter, and that software (with possible exceptions) should not be patentable, for reasons I am going to expose.

Why software patents themselves are not sustainable

The first reason is that contrary to, say, mechanical engineers, or biologists, or even chip designers, the software development community is dispersed, heterogeneous, and loosely connected, if at all. An employee in IT writing network management scripts is a software practitioner; an iOS application developer is a software practitioner; a web front-end developer writing HTML and JavaScript is a software practitioner; a Java programmer writing line of business applications internal to the company is a software practitioner; an embedded programmer writing the control program for a washing machine is a software practitioner; a video game designer scripting a dialog tree is a software practitioner; a Linux kernel programmer is a software practitioner; an embedded programmer writing critical avionics software is a software practitioner; an expert writing weather simulation algorithms is a software practitioner; a security researcher writing cryptographic algorithms is a software practitioner. More significantly, every company past a certain size, regardless of its field, will employ software practitioners, if only in IT, and probably to write internal software related to its field. Software development is not limited to companies in one or a few fields, software practitioners are employed by companies from all industry and non-industry sectors. So I don’t see software developers ever getting into a coherent enough “community” for patents to work as intended.

The second reason, which compounds the first, is that software patents can not be reliably indexed, contrary to, say, chemical patents used in the pharmaceutical industry for instance2. If an engineer working in pharmacology wants to know whether the molecule he intends to work on is patented already, there are databases that, based on the formal description of the molecule, allow to find any and all patents covering that molecule, or allow the knowledge with a reasonably high degree of confidence that the molecule is not patented yet if the search turns up no result. No such thing exists (and likely no such thing can exist) for software patents, where there is at best keyword search; this is less accurate, but in particular cannot give confidence that an algorithm we want to clear is not patented, as a keyword search may miss patents that would apply. It appears that the only way to ensure a piece of software does not infringe patents is to read all software patents (every single one!) as they are issued to see if one of them wouldn’t cover the piece of software we want to clear; given that every company that produces software would need to do so, and remember the compounding factor that this includes every company past a certain size, this raises some scalability challenges, to put it lightly.

This is itself compounded by the fact you do not need a lot of resources available, or to spend a lot of resources or time, to develop and validate a software invention. To figure out whether a drug is worth patenting (to say nothing of producing it in the first place), you need a lab, in which you run experiments taking time and money to pay for the biological materials, the qualified technicians tending to the experiments, etc. Which may not work, in which case you have to start over; one success has to bear the cost of likely a magnitude more failures. To figure out whether a mechanical invention is worth patenting, you need to build it, spend a lot of materials (ones constitutive of the machine because it broke catastrophically, or ones the machine is supposed to process like wood or plastic granules) iterating on the invention until it runs, and even then it may not pan out in the end. But validating a software invention only requires running it on a computer that can be had for $500, eating a handful of kilojoules (kilojoules! Not kWhs, kilojoules, or said another way, kilowatt-seconds) of electrical power, and no worker time at all except waiting for the outcome, since everything in running software is automated. With current hardware and compilers, the outcome of whether a software invention works or not can be had in mere seconds, so there is little cost to failure of an invention. As a result, developing a software invention comparable in complexity to an invention described in a non-software patent has a much, much lower barrier of entry and requires multiple orders of magnitude less resources; everyone can be a software inventor. Now there is still of course the patent filing fee, but still in software you’ve got inventions that are easier to come up with, as a result many more of them will be filed, while they impact many more companies… Hmm…

Of course, don’t get me wrong, I do not mean here that software development is easy or cheap, because software development is about creating products, not inventions per se; developing a product involves a lot more (like user interface design, getting code by different people to run together, figuring out how the product should behave and what users want in the product, and many other things, to say nothing of non-programming work like art assets, etc.) than simply the inventions contained inside, and developing that takes a lot of time and resources.

Now let us add the possibility of a company getting a software patent so universal and unavoidable that the company is thus granted a monopoly on a whole class of software. This has historically happened in other domains, perhaps most famously with Xerox who for long held a monopoly on copying machines, by having the patent on the only viable technique for doing so at the time. But granting Xerox a monopoly on the only viable copying technique did not impact other markets, as this invention was unavoidable for making copying machines and… well, maybe integrated fax/printer/copying machine gizmos which are not much more than the sum of their parts, but that was it. On the other hand, a software invention is always a building block for more complex software, so an algorithmic patent could have an unpredictable reach. Let us take the hash table, for instance. It is a container that allows to quickly (in a sense formally defined) determine whether it already contains an object with a given name, and where, while still allowing to quickly add a new object; something computer memories by themselves are not able to do. Its performance advantages do not merely make programs that use it faster, they allow many programs, which otherwise would be unfeasibly slow, to exist. The hash table enables a staggering amount of software; for instance using a hash table you can figure out in a reasonable time from survey results the list of different answers given in a free-form field of that survey, and for each such answer the average age of respondents who picked that answer (as an example). Most often the various hash tables uses are even further removed from user functionality, but are no less useful, each one providing its services to another software component which itself provides services to another, etc. in order to provide the desired user functionality. Thanks to the universal and infinitely composable nature of software there is no telling where else, in the immensity of software, a software invention could be useful.

Back when it was invented, the hash table was hardly obvious, had it been patented everyone would have had to find alternative ways to accomplish more or less the same purpose (given the universal usefulness it has), such as trees, but those would themselves have become patented until they was no solution left, as there are only so many ways to accomplish that goal (given that in software development you cannot endlessly vary materials, chemical formulas, or environmental conditions); at that point software development would have become frozen in an oligopoly of patent-having companies, which would have taken advantage of being the only ones able to develop software to file more patents to indefinitely maintain that advantage.

Even today, software development is still very young compared to other engineering fields, even to what they were around the start of the nineteenth century when patent systems were introduced. And its fundamentals, such as the hardware it runs on and its capabilities, change all the time, such that there is always a need to reinvent some of its building blocks; therefore patenting techniques currently being developed risks having enormous impact on future software.

But what if algorithmic inventions that are not complex by software standards were not allowed patent protection, and only complex (by software standards) algorithms were, to compensate for the relative cheapness of developing an algorithmic invention of complexity comparable to a non-algorithmic invention, and avoid the issue of simple inventions with too important a reach? The issue is, with rare exceptions complex software does not constitute an invention bigger than the sum of individual inventions. Indeed, complex software is developed to solve user needs, which are not one big technical problem, but rather a collection of technical problems the software needs to solve, such that the complex software is more than the sum of its parts only to the extent these parts work together to solve a more broadly defined, non-technical problem (that is, the user needs). However this complex software is not a more complex invention solving a new technical problem its individual inventions do not already solve, so patenting this complex software would be pointless.

Exceptions (if they are possible)

This does leave open the possibility of some algorithmic techniques for which I would support making an exception and allowing them patent protection while denying it to algorithms in general, contingent on a caveat I will get into afterwards.

First of these are audio and video compression techniques: while they come down to algorithms in the end, they operate on real world data (music, live action footage, voice, etc.) and have shown to be efficient at compressing this real-world data, so they have more than just mathematical properties. But more importantly, these techniques compress data by discarding information that will end up not being noticed as missing by the consumer of the media once uncompressed, and this has to be determined by experimentation, trial and error, large user trials, etc. that take resources comparable to a non-algorithmic invention. As a result, the economics of developing these techniques is not at all similar to software, and application of these techniques is bounded to some, and not all, software applications, so it is worth considering keeping patent protection for these techniques.

Other techniques which are worth, in my opinion, patenting even though they are mostly implemented in software are some encryption/security systems. I am not necessarily talking here of encryption building blocks like AES or SHA, but rather of setups such as PGP. Indeed these setups have provable properties as a whole, so they are more than just the sum of their parts; furthermore, as with all security software the validation that such techniques work can not be done by merely running the code3, but only by proving (a non-trivial job) that they are secure, again bringing the economics more in line with those of non-algorithm patents, therefore having these techniques in the patent system should be beneficial.

So it could be worthwhile to try and carve an exception and allow patents for these techniques and others sharing the same patent-system-friendly characteristics, but if attempted extreme care will have to be taken when specifying such an exception. Indeed, even in the U.S.A. algorithm patents are formally banned, but accumulated litigations ended up with court decisions that progressively eroded this ban, first allowing algorithms on condition they were intimately connected to some physical process, then easing more and more that qualification until it became meaningless; software patents must still pretend being about something other than software or algorithms, typically being titled some variation of “method and apparatus”, but in practice the ban on algorithm patents is well and truly gone, having been loopholed to death. So it is a safe bet any granted exception, on an otherwise general ban on software patents should it happen in the future, will be subject to numerous attempts to exploit it for loopholes to allow software in general to be patented again, especially given the important pressure from big software companies to keep software patents valid.

So if there is any doubt as to the validity and solidity of a proposed exception to a general ban on software patents, then it is better to avoid general software patents coming back through a back door, and therefore better to forego the exception. Sometimes we can’t have nice things.

Other Proposals

Nilay Patel argues that software patents should be allowed, officially even. He mentions mechanical systems and a tap patent in particular, arguing that since the system can be entirely modeled using physical equations, fluid mechanics in particular, the entire invention comes down to math in the end like for software, so why should software patents be treated differently and banned? But the key difference here, to take again the example of the tap patent he mention, is that the part of math which is an external constraint, the fluid mechanics, are an immutable constant of nature. On the other hand with algorithm patents all algorithms involved are the work of man; even if there are external constraining algorithms in a given patent, due to legacy constraints for instance, these were the work of man too. In fact, granting a patent because an invention is remarkable due to the legacy constraints it has to work with and how it solves them would indirectly encourage the development and diffusion of such constraining legacy! We certainly don’t want the patent system encouraging that.

The EFF proposes, among other things, allowing independent invention as a valid defense again software patent infringement liabilities. If this is allowed, we might as well save costs and abolish software patents in the first place: a patent system relies on independent infringement being an infringement nonetheless in order to avoid abuses rendering the whole system meaningless, and I do not see software being any different in that regard.

I cannot remember where, but I heard the idea, especially with regard to media compression patents, of allowing software implementations to use patented algorithm inventions without infringing, so that software publishers would not have to get a license, while hardware implementations would require getting a license. But an issue is that “hardware” implementations are sometimes in fact DSPs which run code actually implementing the codec algorithms, so with this scheme the invention could be argued to be implemented in software; therefore OEMs would just have to switch to such a scheme if they weren’t already, qualify the implementation as software, and not have to pay for any license, so it would be equivalent to abolishing algorithm patents entirely.


  1. I do not comment on the internal affairs of foreign countries in this blog, but I have to make an exception in the case of the software patent situation in the U.S.A., which is so appalling that it ought to be considered a trade impediment.

  2. I learned that indexability was a very useful property that, in contrast to software patents, some patent domains did have, and the specific example of the pharmaceutical industry as such a domain, from an article on the web which I unfortunately cannot find at the moment; a search on the web did not allow me to find it but turned up other references for this fact.

  3. It’s like a lock: you do not determine that a lock you built is fit for fulfilling its purpose by checking that it closes and that using the key opens it; you determine it by making sure there is no other way to open it.

A few things I would have liked to read about in John Siracusa’s Lion review

Yesterday we saw a few things that John Siracusa didn’t mention in his Snow Leopard review but that I think could have been in talked about in there. Today we will do the same with his Lion review.

The same disclaimer applies: John can’t know everything or mention everything, so do not construe anything I say here as being any sort of criticism of his work, much to the contrary in fact.

First, since Lion requires a 64-bit Mac, I was wondering whether built-in executables actually were 64-bit only, as it would cut short any attempt to run this release of Mac OS X on anything older than its baseline requirements (some earlier releases of Mac OS X could be massaged to do so, to an extent). As it turns out, most executables do have a 32-bit slice, with the exception however of the Finder, which therefore prevents Lion from meaningfully running on a 32-bit machine.

Then, the specific system requirements for AirDrop made me wonder what was the deal here, and whether there was any relationship with Wi-Fi Direct. Unfortunately, I do not know much here (besides that there is indeed a relation), so John covering this would have been all the more welcome. Ah well.

The addition of the AVFoundation APIs (originally released on iOS) to Mac OS X raises an important question that I haven’t seen addressed: what about QTKit? Does it turn out not to be the way forward (even though QTKit is pretty recent), or are they meant to integrate, or is QTKit more for a certain class of needs and AVFoundation for others, or something else altogether? I have no idea, and that’s one of the of the first things (admittedly, as an iOS multimedia app developer, I am a bit biased) I wanted to know. Maybe in the next review John will make a return to covering video technologies at length…

Lastly, I’ve been very intrigued by the rise of SSDs (though I don’t use one myself) and the impact on how storage devices are abstracted, and so a word about Lion support for TRIM would have been nice. Apparently Apple is quietly and selectively enabling it for some drives, but this comes from sources which aren’t very authoritative, while on the other hand with John this would have been coming, not from the horse’s mouth, but pretty much the next best thing.

Make your site shine in lynx (for some value of “shine”)

Yesterday I presented my findings about the Wii browser. Today we shall do the same with Lynx.

Lynx is a text-mode browser which renders on terminals. While it will work on a VT-100, it will greatly benefit from a color terminal. I have found Lynx to be useful when browsing the web from low-bandwidth and/or high-latency settings. For instance, from my student room in a few occasions getting at the wider web would fail, but I could connect to school machines just fine, so I logged by ssh to my school account. Unfortunately, while I could tunnel an X window connection a graphical browser used in such a way was pretty much unusable, but Lynx worked very well.

At this point I need to note that I am not doing web design by any stretch, rather I try to make sure my writing can be read without hassle on such a target.

So first, Lynx has a number of limitations coming from the display device. For one, there is only one font, determined by the terminal or terminal emulator, and it’s not possible for Lynx to change it. Furthermore, font rendering is pretty primitive, don’t expect proportional text, varying font sizes or (God forbid) kerning or ligatures. There is no italics either, though Lynx will try and make sure italics and bold are highlighted in some way through the use of color, the same goes for <code>. The same way, in order to emphasize <h#>, Lynx renders them flush to the left, while paragraphs are indented.

Lynx is also Unicode-aware and will understand and convert between the different encodings and render to UTF-8 if the terminal supports it (which is common for terminal emulators nowadays). So don’t get the impression that text-mode and terminal mean straight quotes and simple hyphens. All in all, despite the limitations Lynx will render your text and at least the meaning of your text formatting as best as it can.

Besides your text itself, however, it is important to remember that Lynx is a text-mode browser. Besides no images (so don’t forget the alt text!), this means it will not attempt to interpret your site layout and try and render it with box drawing characters or anything of the sort; instead, your text will be rendered in the order it appears in the HTML source, so if you have a side column (like navigation) whose content is after the main writing in the HTML source, it will appear after your writing in Lynx (which may be what you want). This also means that you should avoid having too much navigation boilerplate at the top: what appears as an unobtrusive 30 pixel high row of buttons/menus in a graphical browser will show as a laundry list of links, with menus unrolled, that the user has to scroll through at the start of every single page.

Also, Lynx will render your content as white text on black, and will not try to apply your color scheme. Lynx seems to ignore any styling information, this means you need true separation of content and presentation; for instance the boxes I use around additions I make later on to a post do not render at all and this information is lost (it’s not too bad in this case), so try and avoid such constructs. Lynx does not support Javascript either.

The user interacts entirely with the keyboard; it’s pretty spartan, but efficient: base commands are space/b to scroll down/up a screenful of text from a page, up/down arrows to navigate links, right arrow to follow a link, left arrow for back (a development tip: you do ctrl-R to reload and refresh the page). Some site navigation options, especially if they are after the content, may not be as discoverable for the user as on a graphical browser, on the other hand users will gladly search, so make sure you have a search box at the top, clearly marked (with text!), they will take it from there.

In the end, don’t neglect Lynx, you might not think of it as useful, until the day you need to check the content a site serves when seen from a machine on which you happen to have a ssh account…

A few complements to John Siracusa’s Snow Leopard review

I always read John Siracusa’s review of the latest Mac OS X release with great interest, and he always delivers. Such is the case again with his review of Mac OS X Snow Leopard, which is of particular interest as for this release Apple teased only “one new feature” (Microsoft Exchange support), and John does a bang up job showing the other, non-obvious new stuff in this release (as obviously the guys writing Mac OS X did not just stop working for nearly two years).

That being said, there are a few things that I either heard about before, or learned about afterwards, that I wish he would have covered in the review. This isn’t necessarily a reproof of his review, as he has to make choices as to what he covers, and he can’t be aware of everything anyway. Nevertheless, here are a few things I wish I could have read about in his review.

QuickTime X

John does of course cover QuickTime X, but there is some more interesting stuff I found out about it.

First, the offloading mechanism he describes, where videos that QuickTime X cannot handle are played in a QTKitServer process, is not sufficient for all cases: there are videos that the new QuickTime Player app cannot even handle and have to be opened by QuickTime Player 7. This is why, when you install QuickTime Player 7 (which is an optional install), video files become owned by a “QuickTime Player Launcher” app (which lives inside QuickTime Player 7), and whenever you open a video this app dispatches the video to the new QuickTime Player, or to QuickTime Player 7 if the former cannot handle it. It’s safe to say that Apple has you covered for this transition.

Second, another feature not supported by QuickTime X at this time is video orientation, which is surprising since it is used by the video recording feature of the iPhone 3GS; as a result, if you have videos recorded in tallscreen from your iPhone, the new QuickTime Player will play them rotated 90°.

Third, contrary to what he implies in page 5: “the most significant new 64-bit-only API is QuickTime X”, 32-bit apps can use the QuickTime X engine; indeed I know of a bug in the traditional QuickTime playback engine, which I can reproduce easily in QuickTime Player 7, but cannot with the new QuickTime Player, whether it is running in 32 or 64-bit mode.

libcache

libcache is an interesting new functionality from the lower levels of Mac OS X. Back in the days of classic MacOS, memory had to be much more explicitly managed, and one of the ways it was done was with purgeable memory buffers which could be freed by the operating system if it needed the memory; a common pattern was loading data from a file in such a buffer, if when coming back to it the application found the data still there, all the better, otherwise it would simply allocate the buffer again and reload the data from disk. The Mac OS X virtual memory system and memory-mapped files advantageously replace this pattern and purgeable buffers are never purged on Mac OS X. However, a use case for which there was no longer a solution is the following: what about data which is computed from other data and cheaper to recompute than to save then reload from disk? An application willing to cache this data either doesn’t, and wastes performance recomputing it each time, or keeps it in memory, and if this data gets paged out to disk when the application then tries to use it again the virtual memory system wastes time reloading it from the pagefile as the application could have recomputed it more quickly instead.

Enter libcache. With libcache programmers can attach data to a cache object and libcache will call a release callback on the data object if memory needs require it. This functionality is also available at the Foundation level, and Foundation also provides an equivalent of the purgeable buffers of old with NSPurgeableData.

This is not too frequent but still a pattern I see with Mac OS X: it generally introduced significantly easier ways of doing common operations, replacing mechanisms from classic MacOS which needed much more manual management, but some special use cases ended up not being well-served by the new Mac OS X way, and Mac OS X ends up rediscovering and supporting these some time later. Grand Central Dispatch, interestingly, is the exact converse: a massively simpler way to leverage functionality (here, multicore processing) that will ensure this functionality will end up being actually used in much more software, improving performance and user experience across the board.

Tomorrow, we’ll see a few more things I wanted to read about in John Siracusa’s Lion review.

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.