[Humanist] 24.381 iPad apps by/for us

Humanist Discussion Group willard.mccarty at mccarty.org.uk
Mon Oct 4 22:15:42 CEST 2010

                 Humanist Discussion Group, Vol. 24, No. 381.
         Centre for Computing in the Humanities, King's College London
                Submit to: humanist at lists.digitalhumanities.org

  [1]   From:    Desmond Schmidt <desmond.schmidt at qut.edu.au>              (37)
        Subject: RE: [Humanist] 24.379 iPad apps by/for us

  [2]   From:    Timothy Hill <timothy.d.hill at gmail.com>                   (72)
        Subject: Re: [Humanist] 24.379 iPad apps by/for us

        Date: Mon, 4 Oct 2010 07:47:14 +1000
        From: Desmond Schmidt <desmond.schmidt at qut.edu.au>
        Subject: RE: [Humanist] 24.379 iPad apps by/for us
        In-Reply-To: <20101003202947.1B9FA881C0 at woodward.joyent.us>

Hi Patrick,

>There are two advantages to content being independent of the application
>code that will process it:

>1) Developers can improve code for an application without fear of
>breaking with the content format.

>2) Content can be delivered to any platform (open or otherwise) for
>which an application has been developed.

I guess you are talking about XML but XML is not in itself a format. Once you 
get down to the nitty-gritty of defining a data format within XML (for example)
several practical problems arise which prevent these ideals from being fully 

1) Developer A implements the standard with extensions of his/her own to 
enable application-specific behaviour that he/she thinks appropriate. 
Developer B implements the standard with his/her own extensions: 
result is incompatibility. This happened for example with the portlet standard 
JSR 168. Each vendor extended it to suit their requirements and the result was 
incompatibility. So they rewrote the standard as JSR 286, which hardly anyone 
has yet implemented. Another example can be seen in the differences between 
browsers and interpretations of HTML, CSS and Javascript, even though in this 
case it is strongly constrained by a practical need for interoperability. Another 
example is TEI itself, as recognised within the Guidelines: "no predefined 
encoding scheme can possibly serve all research purposes".

2) I can't see how humanists will ever have the resources to develop 
applications for their own needs that are customised for several platforms. 
Maybe they can develop something that works on all such as Java or a 
commandline tool or a web application. (But even there absolute consistency 
is not possible). So for example developing twice, once for Android and once 
for iOS would be a cost that most developers in our field wouldn't contemplate, 
even with a standard format.

3) There's much more to a GUI application than its data format. I don't see how 
you can standardise those bits. Sooner or later these application-specific 
parts will impinge upon the data format and demand that it be extended. How, 
for example, can a word-processor format be "independent" from the GUI that 
implements it? Take your example of MS Office, why is it that we have two office
XML standards: ODF (originally Sun) and OOXML (Microsoft)? This is just the 
canonisation of a commercial rivalry that we as developers are supposed to 
participate in under the guise of "open" standards.

        Date: Mon, 4 Oct 2010 09:34:29 +0100
        From: Timothy Hill <timothy.d.hill at gmail.com>
        Subject: Re: [Humanist] 24.379 iPad apps by/for us
        In-Reply-To: <20101003202947.1B9FA881C0 at woodward.joyent.us>

>> > My original point was that if a target audience uses the iPad and/or the
>> > iPad offers capabilities that your application requires, or both, then
>> > develop for the iPad. Neither one of those are "ethical" questions.
>> Ah, but it's not that simple, is it - because the 'target audience' is
>> to an extent determined by the applications developed for the iPad.
> Actually it is. But for the confusion between applications and the
> content for applications.

Confusion or no, the point stands: it is idle to imagine that the
tablet marketplace is sufficiently stable that one can decide what
platform(s) to develop for simply on the grounds of an established
user base. The intense competition surrounding the number and
desirability of apps available for iOS and Android indicates that
Apple and Google understand the interdependence between content
provision and eventual market share extremely well. So should we.

As for the confusion itself, it appears to have arisen from the fact
that you take me to be discussing, albeit in a muddle-headed way,
applications and application content, when I was in fact careful to
couch my points in terms of 'platform' and 'content' - using the terms
in a context-dependent way such that their referents will vary
depending on which part of the solution stack is being discussed. This
shifting use of the terms can of course breed confusion (things that
are in one context the 'content' can in another be the 'platform'),
which is why I supplied examples (Microsoft's dominance of the desktop
market, with the various Windows operating systems as the 'platform'
and business/office software as the 'content', and the Browser Wars,
with the different browsers as 'platform' and HTML pages as 'content')
which I'd hoped would clarify matters. Evidently, however, this didn't
work, as Willard's subsequent post seems to indicate that he took my
use of 'platform' to be referring to the bottom of the solution stack
(hardware + OS), while you took me to be referring to applications
near the top.

So, to obviate further confusion on that score: by 'content' I meant
'the focus of user interaction', and by 'platform' I meant 'the
technical context that allows these interactions to take place'. The
distinction is admittedly a crude one, as Willard points out - but
it's vital for some engineering questions, and it's one that marketing
people understand very well. To take an example closer to home: when
Apple takes out a full-page spread advertising the fact that, no
matter what your need, there's 'An App For That', I understand them to
be marketing their platform (iOS) in terms of the great content (the
apps themselves) it gives you access to; and when Amazon tells you
that you can read 700 000 titles using the Kindle for iPad app,
they're again promoting their platform (this time, an app) with
reference to the content (files encoded in Kindle AZW format) that
exists for it.

The point of employing 'platform' and 'content' in this (hardly
idiosyncratic) fashion is that (a) it does justice to the
multi-layered nature of application development and design; and (b)
once you start doing justice to this multi-layered nature, it becomes
clear that 'openness' is a criterion that potentially applies all the
way down the solution stack, and not just (as you seem to suggest) the

This latter is a point that Apple clearly understands very well - as
indicated, as I pointed out in an earlier post, by its attempts to
close off as many layers as possible, whether by trying to define the
HTML 5 spec avant la lettre or by forbidding developers from compiling
non-ObjC files into ObjC applications. Such behaviour is, as you
rightly point out, ultimately self-defeating, at least taken in broad
perspective. It is also, manifestly, a repeated corporate pattern.

> BTW, you mention Android in a later post in this thread. I don't recall
> it "dropping" from the conversation but what is it that you want to say
> about it?

I also mentioned it in an earlier one. As did Constantinescu Nicolaie
and David Postles. For what I wanted to say about it, I refer you to
my post in this thread of 22 September, published to the list on the

Timothy Hill
Centre for Computing in the Humanities
King's College London

More information about the Humanist mailing list