Monthly Archives: October 2012

The war in the west

Posted on by

Just got back from the book launch for “Tiree: War among the Barley and Brine“.  Organised by An Iodhlann and the Islands Book Trust.

Mike Hughes, one of the authors, gave a talk and there were ex-service men connected with Tiree and their families present.  One man was the son of the pilot of one of the two Halifaxes which crashed into each other over the airfield on a cloudy day – a father he had never met as his mother was only 4 months pregnant at the time.

I hadn’t realised that it was from Tiree that the weather reports came in that set the timetable for D-Day.  The meteorological squadrons are unsung heroes of the war, flying far out into the Atlantic, in conditions where all other planes were grounded, to get the long-range weather data that is so easy to gather now-a-days from satellites.  Sadly the airman who had made the crucial weather observations for D-Day did not survive the war dying in that same Halifax accident over Tiree.

Neither had I known that Tiree was to be the staging post for the withdrawal of Winston Churchill and the Royal Family had the worst happened and the the German’s invaded Britain.  So, before it withdrew to a government in exile in Saskatchewan, the last outpost of British sovereignty would have been … Tiree.

First version of Tiree Mobile Archive app goes live at Wave Classic

Posted on by

The first release version of the Tiree Mobile Archive app (see “Tiree Going Mobile“) is seeing real use this coming week at the Tiree Wave Classic. As well as historical information, and parts customised for the wind-surfers, it already embodies some interesting design features including the use of a local map  There’s a lot of work to do before the full launch next March, but it is an important step.

The mini-site for this Wave Classic version has a simulator, so you can see what it is like online, or download to your mobile … although GPS tracking only works when you are on Tiree 😉

Currently it still has only a small proportion of the archive material from An Iodhlann so still to come are some of the issues of volume that will surely emerge as more of the data comes into the app.

Of course those coming for the Wave Classic will be more interested in the sea than local history, so we have deliberately included features relevant to them, Twitter and news feeds from the Wave Classic site and also pertinent tourist info (beaches, campsites and places to eat … and drink!).  This will still be true for the final version of the app when it is released in the sprint — visitors come for a variety of reasons, so we need to offer a broad experience, without overlapping too much with a more tourism focused app that is due to be created for the island in another project.

One crucial feature of the app is the use of local maps.  The booklet for the wave classic (below left) uses the Discover Tiree tourist map, designed by Colin Woodcock and used on the island community website and various island information leaflets.  The online map (below right) uses the same base layer.  The map deliberately uses this rather than the OS or Google maps (although final version will swop to OS for most detailed views) as this wll be familiar as they move between paper leaflets and the interactive map.

   

In “from place to PLACE“, a collection developed as part of Common Ground‘s ‘Parish Maps‘ project in the 1990s, Barbara Bender writes about the way:

“Post-Renaissance maps cover the surface of the world with an homogeneous Cartesian grip”

Local maps have their own logic not driven by satellite imagery, or military cartography1; they emphasise certain features, de-emphasise others, and are driven spatially less by the compass and ruler and more by the way things feel ‘on the ground’.  These issues of space and mapping have been an interest for many years2, so both here and in my walk around Wales next year I will be aiming to ‘reclaim the local map within technological space’.

In fact, the Discover Tiree map, while stylised and deliberately not including roads that are not suitable for tourists, is very close to a ‘standard map’ in shape, albeit at a slightly different angle to OS maps as it is oriented3 to true North whereas OS maps are oriented to ‘Grid North’ (the problems of representing a round earth on flat sheets!).  In the future I’d like us to be able to deal with more interpretative maps, such as the mural map found on the outside of MacLeod’s shop. Or even the map of Cardigan knitted onto a Cardigan knitted as part of the 900 year anniversary of the town.

     

Technically this is put together as an HTML5 site to be cross-platform,, but … well let’s say some tweaks needed4.  Later on we’ll look to wrapping this in PhoneGap or one of the other HTML5-to-native frameworks, but for the time being once you have bookmarked to the home page on iOS looks pretty much like an app – on Android a little less so, but still easy access … and crucially works off-line — Tiree not known for high availability of mobile signal!

  1. The ‘ordnance‘ in ‘Ordnance Survey‘ was originally about things that go bang![back]
  2. For example, see “Welsh Mathematician walks in Cyberspace” and  “Paths and Patches – patterns of geognosy and gnosis”.[back]
  3. A lovely word, originally means to face East as early Mappa Mundi were all arranged with the East at the top.[back]
  4. There’s a story, going cross browser on mobile platform reminds me so much of desktop web design 10 years ago, on the whole iOS Safari behave pretty much like desktop ones, but Android is a law unto itself!.[back]

Death by design

Posted on by

Wonderful image and set of slides describing some of the reasons multitasking is a myth and how the interfaces we design may be literally killing people (during a mobile outage in Dubai cat accidents dropped by 20%).

Thanks to Ian Sommervile for sharing this on twitter.

Offline HTML5, Chrome, and infinite regress

Posted on by

I am using HTML5’s offline mode as part of the Tiree Mobile Archive project.

This is, in principle, a lovely way of creating web sites that behave pretty much like native apps on mobile devices.  However, things, as you can guess, do not always go as smoothly as the press releases and blogs suggest!

PhotobucketSome time I must write at length on various useful lessons, but, for now, just one – the potential for an endless cycle of caches, rather like Jörmungandr, the Norse world serpent, that wraps around the world swallowing its own tail.

My problem started when I had a file (which I will call ‘shared.prob’ below, but was actually ‘place_data.js’), which I had updated on the web server, but kept showing an old version on Chrome no matter how many times I hit refresh and even after I went to the history settings and asked chrome to empty its cache.

I eventually got to the bottom of this and it turned out to be this Jörmungandr, cache-eats-cache, problem (browser bug!), but I should start at the beginning …

To make a web site work off-line in HTML5 you simply include a link to an application cache manifest file in the main file’s <html> tag.  The browser then pre-loads all of the files mentioned in the manifest to create the application cache (appCache for short). The site is then viewable off-line.  If this is combined with off-line storage using the built-in SQLite database, you can have highly functional applications, which can sync to central services using AJAX when connected.

Of course sometimes you have updated files in the site and you would like browsers to pick up the new version.  To do this you simply update the files, but then also update the manifest file in some way (often updating a version number or date in a comment).  The browser periodically checks the manifest file when it is next connected (or at least some browsers check themselves, for some you need to add Javascript code to do it), and then when it notices the manifest has changed it invalidates the appCache and rechecks all the files mentioned in the manifest, downloading the new versions.

Great, your web site becomes an off-line app and gets automatically updated 🙂

Of course as you work on your site you are likely to end up with different versions of it.  Each version has its own main html file and manifest giving a different appCache for each.  This is fine, you can update the versions separately, and then invalidate just the one you updated – particularly useful if you want a frozen release version and a development version.

Of course there may be some files, for example icons and images, that are relatively static between versions, so you end up having both manifest files mentioning the same file.  This is fine so long as the file never changes, but, if you ever do update that shared file, things get very odd indeed!

I will describe Chrome’s behaviour as it seems particularly ‘aggressive’ at caching, maybe because Google are trying to make their own web apps more efficient.

First you update the shared file (let’s call it shared.prob), then invalidate the two manifest files by updating them.

Next time you visit the site for appCache_1 Chrome notices that manifest_1 has been invalidated, so decides to check whether the files in the manifest need updating. When it gets to shared.prob it is about to go to the web to check it, then notices it is in appCache_2 – so uses that (old version).

Now it has the old version in appCache_1, but thinks it is up-to-date.

Next you visit the site associated with appCache_2, it notices manifest_2 is invalidated, checks files … and, you guessed it, when it gets to shared.prob, it takes the same old version from appCacche_1 🙁 🙁

They seem to keep playing catch like that for ever!

The only way out is to navigate to the pseudo-url ‘chrome://appcache-internals/’, which lets you remove caches entirely … wonderful.

But don’t know if there is an equivalent to this on Android browser as it certainly seems to have odd caching behaviour, but does seem to ‘sort itself out’ after a time!  Other browsers seem to temporarily have problems like this, but a few forced refreshes seems to work!

For future versions I plan to use some Apache ‘Rewrite’ rules to make it look to the browser that the shared files are in fact to completely different files:

RewriteRule  ^version_3/shared/(.*)$   /shared_place/$1 [L]

To be fair the cache cycle more of a problem during development rather than deployment, but still … so confusing.

Useful sites:

These are some sites I found useful for the application cache, but none sorted everything … and none mentioned Chrome’s infinite cache cycle!

  • http://www.w3.org/TR/2008/WD-html5-20080122/#appcache
    The W3C specification – of course this tell you how appCache is supposed to work, not necessarily what it does on actual browsers!
  • http://www.html5rocks.com/en/tutorials/appcache/beginner/
    It is called “A Beginner’s Guide to using the Application Cache”, but is actually pretty complete.
  • http://appcachefacts.info
    Really useful quick reference, but:  “FACT: Any changes made to the manifest file will cause the browser to update the application cache.” – don’t you believe it!  For some browsers (Chrome, Android) you have to add your own checks in the code (See “Updating the cache” section in “A Beginner’s Guide …”).).
  • http://manifest-validator.com/
    Wonderful on-line manifest file validator checks both syntax and also whether all the referenced files download OK.  Of course it cannot tell whether you have included all the files you need to.