NHS Scotland Open Desktop Initiative

This article is written in response to the Question and Answer phase
of the NHS Scotland Open Desktop Initiative.
From the initiative's abstract:

NHSScotland is currently in the process of developing a set of standards to
support the development and building of the NHS Scotland Open Desktop.

the wish to have support for a wide variety of hardware (such as tablets,
PDAs, laptops as well as desktops) automatically defines and constrains
the types of software that can be deployed. fortunately, there do
happen to exist software architecture(s) that meet the requirements,
and work across a vast and wide range of OSes and hardware dating back
at least 10 years.

firstly, it is assumed (please clarify! ok, yes, please treat this
as a question) that there is absolutely no desire to develop multiple
versions of the exact same front-end software.

if this is *not* part of the requirements, it would be incredibly wise
- and logical - to add this into the requirements. with the obvious
proviso, a long way down the paragraphs, that "if it is completely
impractical to only have one GUI front-end then more than one must be
developed, and that the multiple GUIs must provide as best as practical
the exact same functionality". in the case of 320x240 LCDs on PDAs,
that's clearly impractical to expect to be able to fit a GUI which is
designed for 1920x1080 HD screens.

so, devices clearly have different purposes, and yet within the boundaries
of those purposes, it can be reasonable to expect the software to work
across a wide range of *independent* hardware devices. for example: if
some software is designed to run on hand-held devices, then yes it should
be designed to run across anduhroid, ipphone, ittablet, blackbuberries,
openmookows and so on - i.e. the software should adapt to input devices
as well as screen types and sizes, with the minimum of fuss and the
absolute minimum of software development.

there really is only one way to ensure that these requirements are met,
and that's to mandate that all applications be web-based. whilst many
free software people would object to that, as a free software developer
i'd have to say "tough". the alternatives are things like QT4. it should
tell you a lot that QT4 has been abandoned by its new owners, Nokia.
from personal experience, i have found QT4 to be absolutely brilliant
yet completely overwhelming in its demand for computing resources.
also, there is a down-side: a QT4 application which is compiled for
say a PDA with an ARM processor will *not* work on a Desktop PC: it
requires re-compilation! so you cannot have "just one version" - you
have to have multiple versions.

so, again, we come back to web-based applications as being "the only"
truly ubiquitous GUI development environment around that fulfils the
requirements. there's no "installation" required - just point the
web browser at the app, and (as long as it's been written properly)
"it just works".

this is probably why someone had the bright idea of writing ActiveX
components. TheyJustWork(tm). (trouble is, you're now stuffed, and tied
to that proprietary OS, but that can be fixed). so, it's the right idea,
but poor execution.

what are the alternatives (that still work across multiple platforms)?

well, java is out. it's an absolute dog. and, as we're seeing, there
are some serious issues regarding its licensing. and some patent wars
surrounding it. We Don't Like Oracle.

also - adobe flash is out. apart from "it's also proprietary", the
apple ittablet will support flash "When Hell Freezes Over", according to
Mr Jobs Himself. then, there's the issue that flash on various android
(and other) tablets either doesn't exist, or is too slow, or doesn't work,
or causes the device to lock up. maybe Mr Jobs Himself has a good point
about banning flash from the ipphone and the ittablet...

also - mandating a particular version of HTML or even a particular
browser is equally as bad as mandating a particular OS or platform.
it's not even OK to specify HTML5 as a minimum requirement, because
HTML5 is not available (by default) for w32 platforms except version 7.
unless you force people to install that chrome-browser-in-IE6-browser
plugin, which would itself be very bad (it's monstrously large). plus,
it's actually unnecessary (even for 2D Graphics animations) to mandate
a particular version of HTML (see below).

that leaves javascript. whilst it's been around for a heck of a long
time, its potential has been drastically underestimated. although it
is massively distasteful to some, there do exist software development
environments that take away all the hard work. here are a few:

* GWT http://code.google.com/webtoolkit/
* Pyjamas http://pyjs.org
* extjs http://www.sencha.com/products/extjs/
* node.js http://nodejs.org/
* jquery http://jquery.org/

the list above is roughly in order of sophistication and/or "elegance"
and or "time-saving-ability". it's worth specifically mentioning that
both GWT and Pyjamas are designed to take away the differences between
web engines. many applications have to have these stupid, stupid logic
decisions "if browser equals IE6 then do X, else if browser equals
mozilla but not mozilla 3.6 then do Y, else if browser equals ..." you
get the picture - and yet it's smacked into the faces of the developers
and makes application development and maintenance a complete nightmare.

GWT and Pyjamas take all that stupidity away. even an entirely new
hardware platform or entirely new OS can be added which the developers
did not know existed, and *without* requiring any modifications to the
original source code of the application (just a recompile) the application
stands a very high chance of "just working", period.

Pyjamas itself it is worth specifically mentioning that, in cases where
javascript becomes too top-heavy (which can happen, especially for very
large and compex GUIs), it is possible to run the "Desktop" version.
this "Desktop Version" is conceptually similar to Adobe AIR and to
Microsoft Silverlight (but without the proprietariness, and without
a whopping great development environment that requires money to buy.
and a license).

and, like the Javascript Version (pyjs), the "Desktop Version" (pyjd)
is actually available for multiple platforms as well: Windows (all
versions dating back even to Windows 2000), Apple (tablets as well as
laptops and desktops), Android (all versions), GNU/Linux (all versions),
GNU/FreeBSD (all versions) - about the only modern platforms the Desktop
version isn't available for is for Blackberry OS and Symbian, because
they're proprietary.

so, the summary is that yes, it is possible to have source code for a
GUI which will work across a near-unlimited range of platforms, with
absolutely no modifications required to that source code in order to
support that near-unlimited range of platforms. (you just have to pick
java or python as the source code language, and GWT or Pyjamas, in order
to fulfil those requirements).

even if you do not pick GWT or Pyjamas, mandating that applications
must be web-based applications (even for stand-alone applications)
makes a massive amount of sense, for the following reasons:

* dividing an application into a client-server architecture is "clean",
and allows separate teams to work on each part. if one team (GUI team)
mess up, or if the GUI turns out to be too slow, the efforts of the
other team (the server-side part) have not been wasted.

* dividing an application into a client-server architecture, especially a
web-based one, magically simplifies the development of the application.
it is no longer necessary to write complex multi-threaded GUIs, because
the web browser engine automatically takes care of that. server-side
responses also can do complex work and return the answer later, without
impacting the front-end responsiveness (within reasonable limits, and
there are techiques for dealing with that).

* if an application is designed to be stand-alone, and the client-server
application turns out to be too big for the device (e.g. a hand-held PDA
or ultra-low-cost tablet) then all is not lost: the server-side component
can be run on a larger web service, and the web-based GUI front-end
can still be run on the PDA. this has the down-side, of course, that
the PDA or ultra-low-cost tablet is now dependent on having a network
connection to the web service, but that's better than not being able to
meet the requirements.

* applications can automatically be designed to be multi-user.

* security is taken care of by design of the back-end service, and by
use of Internet W3C Standards in the implementation of that service.

* different front-end GUIs can be written to meet the capabilities
of different devices (for an extreme example, see the BBC's web site,
especially iplayer which works across multiple widely disparate systems).

* different front-end GUIs can be written to meet different users'
abilities (for an extreme example, see the BBC's web site "text only"
version).

* the division into front and back end means that both can be implemented
with completely different software. the back-end can be written in PHP,
Java, .NET, javascript (yes, javascript, running server-side! i didn't
say it was a good idea), python, c, c++, c# - absolutely anything.

* the division into front and back end basically means that Internet
and Industry Standard communication techniques can be used (based
on AJAX), such as REST, JSONRPC (highly recommended), XMLRPC (not
really recommended: it's too top-heavy) and so on. the use of these
communications techniques and standards are the basis for APIs which
can themselves be made mandatory standards. a good example is the
facebook developer API, or the opensocial framework API: these are
web services where HTML has been turned into a "Remote Procedure Call"
system. designing a Software Service around RPCs has well-documented
and well-understood advantages (including faster web page response time
when the techique is used in web applications).

now, if you pick this route, it's probably a good idea to specify
that the back-end source code must be platform-independent, must be
fully functional across all server platforms, must be easy to install
across those multiple server platforms, and must not require or depend
on proprietary software libraries or components unless absolutely
unavoidable, and even then, the cost of having those proprietary software
libraries and components converted to Free Software (by whatever means,
including buying the source code from the proprietary company or just
buying the proprietary company) must be taken into account in the Total
Cost of Ownership (TCO) and in the Contract Bidding Process.

that'll throw a spanner in the works of anyone trying to sneakily tie
things in to a proprietary system :)

it also instantly rules out certain choices of programming language
and platforms (because it's just too damn difficult to install across
multiple platforms), and that's not a bad thing. the absolute last
thing in the world that you want to happen is for the software to be
written, costing millions, and then in the 5 years in which the software
is written and maintained, the hardware platform becomes obselete (or
worse, attacked due to security vulnerabilities) and costs a hundred
times more to maintain than the software cost to write.

in other words, the frameworks shouldn't be limited to a specific list,
but examples should be given: Django, ColdFusion, Ruby on Rails and so on.

i'd say that the following wikipedia page was a reasonable starting point,
and to exclude anything that's not platform-independent. for example,
MonoRails (castleproject.org) apparently can work on Mono as well as .NET
1 and .NET 2, but that is actually not a good sign (because Mono is such
a large, awkward and unproven technology in the Free Software Community).
but, it at least means that ASP.NET cannot entirely be ruled out - it just
should not be placed high on the priority list as a "platform-independent
platform of choice".

http://en.wikipedia.org/wiki/Comparison_of_Web_application_frameworks

so, to summarise: it should be mandatory that even for stand-alone
applications, all new applications be ubiquitous web-based client-server
architecture, with the GUI designed to use nothing more than HTML,
CSS and Javascript (no matter how extensively), and that the back-end
server portion to use well-known, well-established and proven
platform-independent Free Software Web Server Frameworks.

within this there is a massive amount of wiggle-room, yet it will actively
result in software working across multiple widely disparate platforms,
save on the cost of software development as well as maintenance, and
make deployment an absolute no-brainer in the majority of situations.
and, within a Web Service, APIs can be standardised and thus, around
that standard, the tasks of developing or maintaining either the
back-end or the front-end (or multiples thereof) can be contracted
separately (or even multiply) to ensure reliable delivery of quality
service.