Friday, 20 July 2012

Don't blame HTML5 for bad engineering

There's recently been quite a lot of anti-HTML5 based app publicity, usually surrounding reports like this that the Facebook mobile apps are being rewritten as fully native for performance reasons.

I am reminded off two sayings, one old and one more recent, although I've not heard either of them for a long time.

A bad workman blames his tools is the first one, and it only takes an experienced eye to look at the Facebook app for Android to recognise that it hasn't been thought through, is sloppily written, and at best badly tested.

There's no language in which you can't write a bad program, or words to that effect, used to be an adage when programming languages actually looked different from each other. A good programmer can craft a great app in pretty much anything while a bad programmer can manage to ruin all the good intentions in any programming model.

Listing all the things wrong with the current Facebook apps would take more time than I'm prepared to invest in it, but there are some clear areas that have not been addressed. One is error handling, especially on communications, another is handling back which sometimes heads off to interesting pastures new, and finally interaction between push notifications, alerts and the news feed which all get hideously muddled. None of these are related to HTML5 and JavaScript being slow - they are architectural difficulties that need addressed at a fundamental level.

HTML5 may not be perfect, but it has huge potential. Just as the formal definition of the environment hasn't been completed, the engineering disciplines around using it have not firmed up yet. An HTML5 app has a lot of moving parts which need co-ordinating, and the tools don't have a lot of static checking yet. I have a nasty suspicion that the name HTML5 makes people think that designers can create stuff using it, but it really needs hard-core software engineers at least until the tools mature. You wouldn't want us, the engineering, doing the graphic design so why should the designers do the engineering?

Thursday, 19 July 2012

UX crimes that should be extinct by now

Over the last few days I've been tripping over a bunch of very basic user experience problems with websites and mobile apps that should have died out years ago. It's all basic stuff yet it seems that too many people want to learn the hard way. Surely after all this time with the web these crimes against on-line society should have vanished!

Numeric Error Codes
I was utterly astounded to be told that error NZX005 occurred while I was trying to login to the Hertz Android app. Turns out this means that the password was wrong. Surely in this day and age we can do better than that? Actually the whole app is as bad as Hertz's airport service is good.

Click and Pay
I've recently found several sites, including LinkedIn, offer functionality which requires you to enter data only to find that when you click the Apply button or equivalent you are taken to a payment page. The whole area should be greyed out and clearly labelled as premium content, not dragging the user into expending effort that is wasted.

Selecting from a choice of one
How many people, do you suppose, have more than one account with Scottish Gas? Not many, I'd wager. Yet the vast majority, those customers with only one account, still have to explicitly select that single and only account before putting in a meter reading. For the hard of programming, there's a simple construct that is quite reliable that starts something like if (noOfAccounts > 1) {... which can be used to suppress things like that.


Hiding validation errors
Too many sites do this to name and shame them all. You've made some small mistake in entering a form, press submit and nothing happens. You try again, still nothing. After some hunting around, perhaps scrolling up or down, you notice a tiny piece of red text saying that there was a problem with one of the fields. Make it obvious, fools!

Galleries with jumping next/previous links
I like photos and often look through photo galleries. All too often when the photos aren't the same size the next/previous buttons jump up and down forcing you to hunt around for them instead of admiring the images. Fixing the size of the frame really isn't that difficult you know.

Horizontal scrolling
Much beloved of photographers for their portfolios, all too many galleries expect you to somehow guess that the other hundred luscious images are off to the right. Or the left. Even before Apple foisted the minimalist vanishing scrollbar on the world this was a really annoying design style.

No progress indicator
Another one from photo galleries - it's really nice to know if you are on image one of ten or one of ten thousand.

No wait indicator
One of my old favorites - show some kind of wait indicator if an operation even has the slightest possibility of taking more than half a second. All too many mobile apps forget to do this. I suspect it's because designers don't allow for real network latencies and do their testing using wifi on the same network segment as the back-end systems. We don't live in a perfect work, so don't design for one.

Fake data
This is common on search-based sites like travel and jobs. You find something interesting looking, click on it, and it vanishes, expires, or turns out to be buried in another site, the home page of which you are redirected to without any specifics. This is perhaps the worst offense of all as it's dishonest instead of stupid.

Can we please try and make these errors go the way of the dodo soon? Please?

Wednesday, 18 July 2012

WAC Who?

At the end of the Mobile World Congress this year there was the usual distribution of stuff that nobody wanted to take home. The day before a dude was going round distributing black T-shirts like he couldn't get rid of them fast enough. They had a red logo on them that looked like WAG. On closer inspection the logo is actually WAC for Wholesale Applications Community.

This might as well have been called YAUOIDTF (Yet Another Useless Operator Initiative Doomed To Fail) as it's unstated objective was to overtake the App Store models of Apple, Google et al. You don't need to be an industry expert to realise that a committee of 48 large, competitive organisations are never going to agree to anything useful. Just look at BONDI, OMTP and JIL if you need proof.

The only good news out of this is that the development that was done has been acquired by a good company: apigee. Some bits and pieces are being picked up by GSMA and W3C who are further proof of the snail like progress of non-commercial standardisation. More information over at Rethink.

And of course we still have our T-shirts.

Tuesday, 17 July 2012

MyTracks - Better location

I recently wrote about how location services still have a long way to go. While this is still true, today I've seen at least some of the obvious stuff fixed, although it is far from perfect.

Google engineering has an absolute obsession with math and stats, well into the obsessive-compulsive range in my view. I'm assuming this explains why the open-source Google MyTracks app applies at least some smoothing maths to tracking unlike, say, MapMyRun which had me flying from spot to spot by taking location data too literally.

MyTracks isn't perfect. It shows me jumping from one side of a river to another, but then it doesn't know there's a river there. It also claims that I left the house at 22km/h, a speed that might not quite catch Usain Bolt but is way beyond anything I can achieve. Even my heuristic approach to such algorithmic matters would spot that an immediate speed of roughly twice the average run speed is probably wrong and correct it.

The app is also missing a few simple UX things - eg starting a few seconds after you press go to allow you to put the phone away - but it is free and works pretty well. I'm assuming that if you're not running along the bottom of a steep-sided valley it will probably work very acceptably.

In my case I can knock off a few hundred meters from the logged distance and get something that's close enough for my needs.

Monday, 16 July 2012

Jelly Bean first impressions

In case you hadn't realised, Android release names are in alphabetical order. Jelly Bean is, therefore, the successor to Ice Cream Sandwich. The names are more fun than version numbers which often don't make a lot of sense in any case. And I find them a lot more appealing than Apple's pretentious big cat series for OSX.

My second Android device came from Vodafone in the disguise of being a genuine Google Experience Device (GED) but turned out to have been mucked about by Vodafone and updates came out very slowly and in one notable case, totally broken. They had actually forgotten to include the dictionaries: no autocomplete, no correct, nothing that needed words worked. And they didn't bother to fix it either; couldn't care less and didn't even acknowledge the problem.

For this reason I splashed out on a Samsung Galaxy Nexus direct from Samsung when it came out, with unadulterated Ice Cream Sandwich on it. This has proven worth the money as it is a great device and the OTA Jelly Bean update arrived last week, well ahead of operator-provided devices.

So how is Jelly Bean? Nice - it is faster, a number of small glitches that most people wouldn't notice have been fixed, Google Now looks like it can be useful, and there's a pile more transitions, transparency and artful design changes that make it pleasant to use.

The installation was particularly painless and pretty - nice graphics to show it's working and no interaction required. It might be my imagination, but photo unlock works more often than not now.

On the other hand I have noticed one app that has been affected by the upgrade: Yahoo! Weather no longer shows the name of the city for which it is displaying the weather. Everything else seems to be powering along nicely.

Slick would be the word if I had to pick just one to describe the upgrade.

Thursday, 28 June 2012

Glass to the Future

Having to wear glasses most of the time doesn't seem quite so irksome after the launch of Google Glass yesterday. Watch the promo skydiver video if you've not already seen it, or the concept video of day-to-day life with the glasses.

While the skydiving is a bit like a streaming helmet cam, the concept video is particularly important as it represents a different way of doing stuff that we actually do today by taking out our phones, unlocking them and then interacting. Not sure about muttering at your glasses to make them do things, but we've already seen a huge transformation in people's public interaction with technology.

I'm sure there will be a wave of lookalike social products for sharing, photos, location and the like, but frankly those are going to be covered by Google in the base product. That leaves a huge open space for some really exciting new stuff to happen, things we've not even thought of yet. 

In Neal Stephenson's highly entertaining book Snow Crash there are a group of people who are permanently wired up to stream information into the US Library of Congress. This is exactly what Glass can do - constantly stream all environmental data to the grid. This raises the interesting question of what you can do with it all. After all, I'm sure that it is possible to piece together people's lives from Instagram uploads but I suspect that the result is dull and useless.

Exciting as the Glass platform unquestionable is, the real excitement will come from the new apps that can make sense of the flood of data. Or stop the flood: even current camera phones cause infosec experts nightmares. It's one thing to ask people to leave their phones at the door of secure areas, but glasses are pretty fundamental. 

PS Snow Crash inspired me to write my own cyberpunk novel Network Sleeper.

PPS While it is annoying that Glass preorder is only available to US-Based developers, at least this was stated clearly up front. Far too many new products from Google and others have been launched to a global fanfare only to find out that they only work in the US, or in extreme cases, just the Bay Area.



Sunday, 24 June 2012

Location Still Off The Mark

Location continues to roll into more and more services. Perhaps people are getting used to it, or maybe it's just that there are more and more back-end systems that deliver location information. However there's a problem: the location is all too often annoyingly wrong. 

Let me site a few examples. I live on the edge of Edinburgh city center, yet Facebook systematically puts posts entered at home as being in Granton, which is the docks area and not particularly close. I have found no way to override this setting to something meaningful, like jumping up to city level and simply putting Edinburgh.

I love Path as a means of sharing considered photos with a small circle of friends and family. However it occasionally shows me arriving into completely random places, including Las Vegas and some strange place in rural China. I'm mystified where those came from.

And then there is MapMyRun which is supposed to track where you run. Normally I don't carry any tech with me when I run as I like the escape, but I thought it would be interesting to see what the result was. I was initially pleased to see that I had run much further than I'd expected. The pleasure turned to perplexment when I checked times, and then to irritation when I looked at the map. The tracked waypoints jumped around like crazy beans, as you may be able to see in the screen shot. Surely the coders of this app could work out that I could not have suddenly jumped 700m out and back in a few seconds. I can understand that they can't tell that I would have had to swim a river to achieve it, but even Usain Bolt couldn't have made that detour in the available time.

I've previously talked about the pointlessness of most location systems. Since then things have progressed and there are far more people using location regularly in the UK to make it more valuable. However it's got to be accurate. The quoted examples are just some of the issues I've seen recently. I still often find that the location I'm in does not show up at all or only on searching from it. 

Often the list of locations presented in mobile apps is cached from last use which is at best desperate and at worst deeply stupid. But I can understand why, as acquiring location is still very slow. So I think we need to invent a location-based equivalent of cache time-to-live, perhaps distance-to-live. Any significant movement will wipe the cache content.

And I'd like need an equivalent of the Google Maps zoom control: I can scroll out from the name of a café up to country level depending on what I'm doing.

Location has clearly a long way yet to go yet.