UseGIS News Update 12-12-2011

News, views and tidbits that have caught our eye at UseGIS over the last week.

The AA

Our latest project is a maps-based walking iPhone app for the Automobile Association (The AA).  This will allow people to download and view over 1750 of the best walks in Britain, along with 1:50,000 and 1:25,000 scale Ordnance Survey mapping.  Once downloaded, both the walks and the mapping will be stored on the iPhone so that they can be accessed even when the phone has no connectivity – ideal when you are out and about on a walk and have no signal!  The App is due for release early in the New Year.

iPhone vs Android – which pays best?

While we are in the subject of smartphone apps, here is an interesting article by Rory Cellan-Jones on Android and the economics of apps. We also believe that there’s more chance of being able to charge for an iPhone app than an Android variation – the whole ethos of Apple is to give the user a fantastic experience and people who buy iPhones are more likely to pay for an app because they tend to have more disposable income. However, if you’re target audience tends to purchase Blackberrys, then there’s really no reason to develop an app for either the iPhone or an Android device – not initially anyway.

Google MapsGL

Have you noticed the latest version of Google Maps yet? Named “Google MapsGL”, Google have harnessed  “the power of Web Graphics Library (WebGL) to create far richer visuals and animations.”

“WebGL is a new technology that brings hardware-accelerated 3D graphics to the browser without additional installed software. With WebGL your maps experience is much better with 3D buildings, smoother transitions between imagery and the ability to instantly “swoop” into Street View without a plugin.”

Not all browsers or computers can handle WebGL at the moment, but we’re excited about the future possibilities for displaying maps over the internet. Kudos to Google for taking the step.

Bath Spark

Last week saw our first Bath Spark event as we attended the Xmas Meetup.  It was a great evening and we were impressed by the large number of people from such a varied range of tech industries.  One of the most interesting topics of conversation was a proposed tech and creative co-working hub based at the Guild Hall in Bath.  A dedicated place in the city where tech people can co-work and meet up is a great idea and certainly a project that we support.

Being located in both Bath and Exeter, we get to meet and mingle with two sets of tech communities. This week it’s the turn of the Exeter Web Developers to have their Xmas Meetup, so we’ll be popping along for more socialising and festive drinks…it’s tough, but someone’s got to do it!

UseGIS News Update 02-12-2011

Welcome to a roundup of UseGIS news, views and tidbits that have caught our eye this week.

Our friends over at Cassini Publishing have just launched three historical Ordnance Survey map series of Ireland, originally published from as early as 1833.  This is the first time that two of these Irish map series have been made available in over 100 years. The three map series available are the First Edition Six-Inch or “Townland” maps surveyed between 1829 and 1843, the One-Inch First Edition and also the One-Inch Second Edition maps that chart the development of Ireland from the mid 19th Century through to the early 20th Century. We were contracted to reproject these map series from their original projection systems (Bonne and Cassini projections) to the current day Irish Grid and also integrate them into the Cassini Publishing map generation system.

We’ve also been hard at work this week implementing an update to the TrailZilla website.  This latest update has seen an improvement in the website responsiveness and an increase in the speed of retrieving and plotting map pins.  We’ve also added new customised registration forms for various affiliates (e.g. the AA and the Mountain Leader Training Association) which also provide access to special offers on Ordnance Survey mapping.  If you like outdoor activities or are just looking for a decent walk to burn off the excesses of the festive season, head over to TrailZilla to find a trail near you.

Over the years we’ve used many different design patterns in our PHP projects – there always seems to be a different “flavour of the month”.  However, this week we’ve been making greater use of PHP dependency injection and have to admit that our classes are more decoupled and the code is cleaner and easier to test and follow. If you want a good introduction to dependency injection, then this documentation offered by Symfony is a good starting point.

The news that this week saw the 30th anniversary of the BBC Microcomputer has left some of us here at UseGIS towers staring wistfully into the middle distance, while others now realise just how old they really are!  For many of us the “Beeb” offered the first experience of home computing and taught us the essentials of programming. Rob admits to still dreaming of playing Elite and blasting Thargoid ships into millions of pieces with a military laser.

Next week is the Bath Spark Xmas Meetup and we’ve been lucky enough to get tickets.  It will be our first Bath Spark event and have heard nothing but rave reviews, so we’re looking forward to meeting new people and talking tech over a few drinks.

AnDevCon – San Francisco – Day 2

The most interesting thing that came up today was the vast number of devices that Android developers have to potentially deal with. 286 (and counting) devices now use Android in one flavour or other (and I do mean “flavour” – with a choice of OS releases named after Google’s favourite desserts such as “gingerbread” or “ice cream sandwich”).

The number of devices itself isn’t that interesting, but the variety of screen resolutions and densities, and the ideas and techniques on how to deal with them in one, easy way, is. Android has “layouts” that define rules which say when to change, for example, a 3 column layout on a tablet, into a 2 or 1 column layout when the same page is shown on a smaller screen. But I can’t help feeling that this is just another way to solve the same problem that we’ve had for many years in the web arena, which is only now being solved with the introduction of CSS3.

CSS3 is the way to go for anyone wanting to allow users to view the same web page on multiple screen sizes. In the past, before smart phones came along, web sites tended to be designed for a minimum screen size of, say 800 x 600. As time progressed and technology improved (i.e. screens got bigger) web sites started to support resolutions of 1024 x 768 – but very few  sites use much more of the real estate available to them on bigger resolution screens. Instead, the designers preferred to keep the width the same and simply centred the content and added flexible margins either side.

Now, in defence of this approach, I’d like to say that the main reason for doing this is that eventually, it gets much harder for the human eye to follow the flow of content if the space it takes up goes too far across the screen. One of the reasons we have serif-based fonts, short paragraphs  and multiple columns of text in newspapers is to aid the eye in being able to easily read it. Equally, if there are too many columns used for an article you end up with the same problem. I think this is down to the fact that the eye is good at focussing on information in portrait. So, with the advent of widescreen monitors, which are really designed to allow us to watch movies on our computers, we have to fill this extra width either with multiple columns of unrelated content, or blank margins.

Anyhow, getting back to CSS3 and the present day, what does all this mean now that we’ve got to support much smaller resolution screen sizes?

Well, smartphones have all sorts of tricks up their sleeves to help us to view existing web content – the iPhone certainly has a great way of allowing you to double-tap on a portion of the screen to zoom into that area – making it easier to read. But that’s only part of the solution.

CSS3 introduces @media tags that act in a similar way to the layout controls available in Android. These allow you to specify CSS rules that should only be applied when the screen (or printer for that matter) that the page is being viewed on supports certain resolutions. This allows you to decide what to show and where to show it. This means that the same web page can be rendered in a completely different way depending on the screen resolution – from the largest Apple Cinema display (2560 x 1440) down to the smallest Sony Ericsson Xperia X10 mini Android phone (240 x 320). As long as the device has a modern browser that can render CSS3 properly, you only ever need one set of rules.

A good example of this in action is The Boston Globe (http://bostonglobe.com).

AnDevCon – San Francisco – Day 1

AnDevCon (#andevcon) stands for Android Developer Conference and it brings together hundreds of like-minded companies and individuals to learn about the latest ideas, news, tools and techniques being used in the Android and (to a lesser extent) mobile world. The current gathering (AnDevCon II) is the second get-together and is being held in San Francisco between the 6th and 9th of November. Whilst it’s a long way to come, I really don’t think that there’s anything quite like it in the UK, or Europe for that matter. This is the second such event I’ve attended (the first was for iPhone developers called iPhoneDevCon, which was held in Boston in April)  – and I thoroughly recommend them if you get the opportunity.

The format for the first day is half- and full-day workshops to allow you to delve deep into topics and since we work on various mobile platforms, I decided to to attend two half-day workshops on making apps easier to use and making them look “sexy”.

It’s surprising how much I learnt on these workshops. Some of the ideas were backed up with real statistics too – based on the top apps in the various app stores out there. For example, of the top apps in iTunes:

• 94% are useful because they’re mobile
• 56% use touch meaningfully
• 3% use video3% use the camera meaningfully
• 4% use tilt meaningfully
• 11% use GPS15% are multi-player

What I found more interesting was that:

• 4% of these apps, use 2 of these features
• 0% use 3 or more

[Stats courtesy of #jasonNmark]

So, it’s easy to see that you need to keep your app relevant to the mobile space and as simple as possible – not packing in too many features – if you want it to be successful.

One thing that was effectively demonstrated during the workshops was that it’s better to test your app as soon as possible – especially by other people or stakeholders. This should happen as soon as you have something to show. Again, it seems obvious, but I must admit I have a tendency to “hold on” to what I’m doing until I think it’s almost done. But even though I could be doing exactly what’s required, I’m now convinced that it’s always better to get that feedback as soon as possible – just in case. In some situations, this may simply demonstrate that you’re going the right way but it could also highlight potential problems – and the earlier these come to light, the easier it should be to resolve.

Using Google Maps to Solve an Historical Problem

We have been working closely with Cassini Publishing now for several years and created their award-winning MapMaker historical map browser product and also their automated map production system.  So, we were the natural choice to help them with their new Ancestry Maps website.

Ancestry Maps, which is a joint venture between Cassini Publishing and Ancestry.co.uk, is a new take on the successful MapMaker product.  Historical maps dating from 1805 to the present day are available for England, Scotland and Wales at a variety of scales and detail.  You can enter a place name or postcode, view a large sample map centred on your requested location and then purchase and download the final high quality map.

The Problem

Although the historical map is correctly centred on the chosen place name or postcode, users wanted the ability to be more precise about how the map is positioned by being able to centre the map on a specific street, building or landmark.

This is especially important when dealing with the more detailed large scale historical maps such as the Ordnance Survey 1:10560 and 1:2500 scale maps.  At these scales, individual streets and buildings are clearly visible and easily identifiable and so it becomes more obvious when your map isn’t positioned exactly where you want it.

Users also wanted to be able to position the maps in relation to current day features that often don’t exist on the historical maps, as the landscape of the UK has changed so much over the last 206 years.

The Solution

The solution was to let the user select a new centre point for the historical map by choosing a point on a current day map.

In order to use the Google Maps API v3 to show the current day map, the centre point of the historical map is converted from UK National Grid coordinates to latitude and longitude.  The Google map is then opened in a modal dialog so that the user does not need to navigate away from the historical map sample page.

The user can use any of the Google map layers, including Street View, to zoom and pan and centre their map precisely where they want it.  Once they are happy with the positioning, the new Google map centre point is converted from latitude and longitude to UK National Grid coordinates and a new historical map sample is automatically generated.

A neat, simple solution to what was potentially a complex problem!

Easy to use?

It shouldn’t be that difficult to make an application easy to use.

After all, as members of the human race, developers should all instinctively know when a widget or piece of functionality that they’ve just written is easy to use by others, right?

Well, it seems that’s generally not the case.

We’ve seen many, many instances where an application just doesn’t, in our opinion, work how it should.

One such situation just happened here at UseGIS Towers when an update to Adobe CS5 was being downloaded.

The process itself was reasonably self explanatory – the toolbar icon had the number 3 next to it, which indicated that 3 updates were available for install. Clicking on the icon allowed us to choose the “Updates” option. But as the updates were being downloaded the application insisted on showing the download time left in minutes and, more annoyingly, in decimal minutes.

Now, we do possess some mathematical skills here, so we could work out (even in our heads) that 1.9 minutes left actually meant 1 minute, 54 seconds – but why do we have to??? Since when did anyone use decimal minutes to describe a duration?

All I can think is that someone at Adobe got very lazy the day they wrote the download application – they couldn’t be bothered to multiply the decimal fraction by 60 to work out the number of seconds. And what’s possibly worse, the person who tested it (I am assuming that it was tested by someone else here, after all, we are talking about Adobe) must have thought it fun to have it that way too!

Sure, the duration is “correct” in that it’s not technically wrong. But is it user-friendly?

Usable Augmented Reality

If there’s one thing that can add a “wow” factor to your app, it’s probably Augmented Reality. You may not have heard of that phrase before, so, for the uninitiated, I’ll briefly explain:

Augmented Reality (or AR for short) is a technique where data is superimposed on top of the image shown by your phone’s (or tablet’s) camera, and where that data moves along with the camera’s view as you move the device around. Some apps make the superimposed data appear to be fixed to a specific location in the camera’s view -so  if you move the camera to the left, the data moves to the right -  appearing to stay in the same location – thus augmenting that view of reality. Some apps also augment the view with information or symbols that tell you something about particular features around you  such as the direction to the nearest bank.

The key to making AR work is the ability to know what direction and orientation the device is, where it is precisely in the world, and how these things are changing in real-time. It’s only possible to know these things when your mobile device includes an accelerometer, a compasses, a gyroscope and a GPS chip – something that the latest iPhone and Android devices now include as standard. Of course, the device also needs to have a camera!

Data

Once you have all the necessary hardware at your disposal, you then need to have the data that you want to show, together with its location. The latter is becoming easier and easier to obtain since most things in the world have a locational element to them and determining that can be as easy as clicking on a Google map to obtain a latitude/longitude.

As a developer wanting to offer AR in your app, you then need to write some code to do some number crunching that can take readings from all the hardware components, work out the direction that the camera is looking at, work out whether the data you want to show should appear in the view and then display it. All this in itself is hard, but I would go on to say that there’s one more thing that’s probably more challenging than that – usability.

Usability

To improve your app’s usability, you must consider the following:

• How do you show the data effectively on the screen?
• What if the user is pointing their device where you have no data?
• What if there’s too many features to show at once?

All of these questions need to be addressed if your app is to be usable.

AR in the Royal Ascot app

We addressed some of these issues when we put an AR feature into the Royal Ascot app.

In this case, the data we needed to show represented the locations of restaurants and bars for people to visit whilst at the racecourse. As the user walked around, they could see where things were in relation to their current position.

The fact that the user needed to be at the racecourse really meant that there was no need to show the features if the user wasn’t actually there – so the first thing we did was to only show the venues within 500m of the user’s position.

However, since the venues were in close proximity to each other it became apparent that in a lot of situations there were still too many features to display in the view at the same time – so much so that you couldn’t really see everything you needed to.

So, as well as plotting the venues in distance order – nearest on top, farthest underneath, we added the ability to allow the user to adjust the distance within which the venues were shown – down to 50m. This meant that restaurants and bars further away could be “filtered” out of the view, thus de-cluttering the display.

Showing the Venue Names

Each venue’s name also needed to be clearly shown. So we used the same “bubble pins” as used on the map in the app. This also helped to maintain a standardised style throughout the app.

However, on our first trial of the system all the pins were being positioned along the horizon in the camera view.

This was originally intended and in development it seemed to be a logical decision, but in action, in the field so to speak, we found that it was actually quite difficult to see what each pin was meant to be “pinned” to – the pin was obscuring the venue it was meant to be referring to!

So, we quickly decided that the pins needed to appear towards the top of the screen – above the horizon and above the venue in question.

Lessons Learned

This made for a much more user-friendly experience. But if there’s one lesson to be learned from this experience it’s the fact that, as with all development, you can never do enough testing. With AR especially, until you get out and actually try the app in anger, in real-life situations, you can never really understand how it will work.