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.

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?