GeoLinks!

June 11, 2009 | Comments

For several completely unrelated reasons, I've spent a lot of time looking at and thinking about maps this week.

  • GeoNames, a database of places (as used by Dopplr)
  • Vodafone have a cute map, Twitter-driven (obviously) of who's going on holiday where, this summer;
  • A mind-expanding article on augmenting photographic data, courtesy of pitch/yaw/roll, GPS and OpenStreetmap;
  • First person UIs - who'da thunk that a simple compass opens up so many possibilities? I note that whilst JSR179 has included compass support in the location APIs, compasses were the bit that most implementations of the standard failed to include for a long time...
  • The Google static maps API - handy when you're targeting platforms that don't let you do all the usual Googly JavaScript stuff;

Sprint 39 retrospective

June 07, 2009 | Comments

We had our planning day for sprint 40 last Wednesday, including a retrospective on the previous sprint.

What we learned:
  1. If you take data from third parties, be sure to budget time to sorting out problems with it;
  2. Keeping a team shielding from interruptions might be harder than you think;
  3. Be disciplined about discussing implementation of user stories at the last appropriate moment - it's worth it;

Joh ran a quite nice format where we split into our three teams (Anjuna and Tonberry, our two production teams, plus Mocha - everyone else). Revisiting the objectives from the previous sprint, we'd had three things we wanted to do:

  1. Don't overplan (we've done this quite a lot in the past);
  2. Ensure no interruptions come to the team other than through the myself, the Scrum Master (the previous two sprints, Tonberry had been fielding all sorts of stuff coming from a range of people, and I'd not been shielding them from this adequately);
  3. Propose an approach for automated testing; we do this at a UI level for MIDlets (as well as elsewhere) but it's sometimes seemed quite burdensome for the team;

On the "not overplanning", there was general agreement that we'd not repeated our previous errors. On the automated testing, we'd failed to do anything, though one of the folks with stronger feelings on this was on holiday, so I wasn't too fussed about this - I want to include him in any conversation.

But on the interruptions, we had a worrying difference of opinion. Management folks (including myself) had felt this sprint much better in this regard - we knew there were 2 urgent pieces of work which had come in mid-sprint (a client being messed about by another partner who needed us to do some urgent work to route around issues caused by said partner, and some urgent bugs in a previously released piece of software), but the team felt there was way more than this - and had (as we asked) kept a list of these items.

In a way, I found it more worrying to discovery my view of what was happening was out of sync, than to have seen problems and been aware of them. So this time around we're keeping a *muuuuch* closer eye on things. The team are alerting me instantly when an interruption occurs, and keeping a record of the impact of it: there's a difference between someone popping in to say "hi, how's it going", and someone slyly asking if you could just do a bit of analytics for them on the side...

Elsewhere, we had agreement across teams that we need to return to a practice we established 6 months ago, then dropped: meeting to discuss specifics of a story just before work on it begins. This one seems to already have paid off - a quick chat about a trivial detail on Friday morning unearthed some fairly serious issues, just in time.

Third-party dependencies were, as ever, another issue: in particular, getting hold of data or graphical assets in a form that's suitable for use. A difficult one, this - if we're working for a non-technical client then it's not fair to expect them to understand, say, the issues around character set choices when exporting CSV files from Excel. But equally in these situations, we need to allocate time and effort to managing problems which might arise.

ScrumFest

June 07, 2009 | Comments

ScrumFest is coming to Brighton! 8th and 9th July, at The Werks in Hove. Well worth checking out if you're interested in this sort of thing, also take a look at the WelfareCSM workshops Tobias Mayer is running just beforehand, with the dual aims of introducing Scrum to organisations beyond the software world, and getting training to folks who wouldn't otherwise be able to afford it. Lovely.

Mobile Web Summit 2.0 Slides

June 07, 2009 | Comments

I've put the slides from my talk at Mobile Web Summit 2.0 online - they're here, if you're after them.

My talk was looking at case studies of three mobile apps, two of which we'd done (Puzzler and the Ghost Detector), and one being the mighty Smule (which I've written about before). The main point I was making is that - as I was chuffed to hear Dan mention in his opening talk on day two - "all interesting mobile apps have some sort of social element". That said, this needn't involve all the classic paraphernalia of "social media" - i.e. conversations, contact management, or identity - and assuming that to be doing something social, you have to be building a branded Facebook, or a blogging platform, seems a little... crude. Audiences can be connected in more subtle ways, and as the examples of the league tables we launched for Puzzler, and the opt-in rate for Ghosty both show, these can lead to measurable increases in both uptake and loyalty.

We had fun in the panel session afterwards too, where I got to trot out a theory I've been nurturing around mobile advertising: on the web, the aim of advertising has been to drive users to useful web services, where they can get something useful done. On mobile, applications are a more appropriate destination for advertising.

Why? Mobile web sites tend to be more limited. There are a few really "sticky" ones (itsMy and Flirtomatic, I'm looking at you), but most destinations for mobile advertising are ad-supporting microsites with little long-term value for a visitor. As such, applications are a more natural and worthwhile destination for mobile advertising: give your prospective customers something genuinely useful they can carry with themselves and see value from again and again, rather than expecting them to return to a microsite.

If you're sceptical, I'd encourage you to look at iPhone app store statistics - the average free app is being run 80 times. This might not mean it's a great place to run advertising, but I'll wager that's roughly 80 times more traffic than most mobile microsites get...

MobileDesign, 4th June 2009

June 04, 2009 | Comments

Barriers, Robert Hamilton, Google

Why we need to be open in the way we design and do things. People think mobile is open. (asks how many people have SIM cards).

If mobile was created by Internet folks, there'd be no SIM card - you'd just login from anywhere, on multiple devices, like on the web.

SIM is supposedly great for identity, but is that really necessary for security purposes, given what most people buy using username and password over iTunes, Amazon, etc?

(Shows picture of a ticket gate in Japan)

There's no barrier here. It only closes when someone tries to get in without a ticket - it presumes innocence. This saves electricity, wear and tear, and avoids penalising people who aren't doing anything wrong.

Japanese built a transport network to move people, not to create queues. Don't hinder people who are trying to use your service correctly.

Consider ebay: you're buying from a total stranger. That's fine. Drop £10 in a bar. You'll usually be given it back. This is the world we live in, and it's the world we create.

Put barriers in the way and you force out a different sort of product. Twitter didn't consider "people might want to make Tower Bridge tweet" - they're just open, and people use them in interesting new ways.

"Build a climbing frame, not a cage" - it's the same structure, just a different mental model of what you do with it.

Look at app stores: some people pick winners (e.g. Apple). The web wasn't built this way. Another example: network operators wanted to charge 10c per lookup. People didn't want to pay, so it sat there. Google decided this was fundamentally useful to users and have released a location API, Google Gears, WebKit, etc.

Our philosophy: build things people want to use. Google Wave is a bit weird - we want other people to come onto this.

Q: Where does Gears for Mobile fit?

A: We're more about standards in the browser than getting Gears out there. We're now getting geolocation APIs in W3C standards. Gears got us in there, but has done its job now.

Q: How do you see widgets fitting into the web?

A: Define widgets. The Palm Pre is all widgets - the dialler is written in Javascript. Widgets have a place because users don't think about using a browser. Showing things in a browser isn't the end use case of everything. They let users build their own climbing frame, rather than going to a full web experience. Widget platforms will become browsers.

Q: Should I be worried that all my passwords are the same?

A: SIM is solving a problem that doesn't exist.

Q: Why not do away with passwords?

A: You still have to authenticate. You have to have reasonable barriers for privacy and reputation. Larry says "the internet is too anonymous". If you can authenticate more easily then this might be addressable. The SIM is not the answer.

Q: Should I have to login to execute a google search? Even creating a username is an intolerable overhead.

A: No.

Q: I agree with the philosophy of open. It's great for users, but lots of businesses aren't making money from it. So what's the future of it?

A: It's a truism that people will pay for good things. We don't have micropayments. It's hard to do things at that level. We had 10c payments with AOL but got rid of it. It's easy to do it with a good product. Small app developers will do well. There were lots of mom'n'pop shop writing Newton apps and doing quite well. If you don't have to do distribution, you can make a living selling things for $5. Recurring payments is a key one - most of us are too lazy to hit cancel on that.

Symbian? What's that? Barbara Ballard

Nokia has 6% penetration in the US, maybe lower.
60% of US subscribers now text, but email a lot via Blackberry - because we like email. But we do more mobile web than European. In the 90s we stayed online all day using dialup, so email was always available... but not 2-way SMS or operator interop.

RIM put together an ecosystem for email as sophisticated as Apple's for music: consumption, servers, Exchange integration, fast setup, works well on 2G. Some US people call any candybar phone with a keyboard a Blackberry.

By comparison, it takes 77 clicks to set up email for Nokia.

Until recently BB had no Javascript, CSS or stylesheets activated.

30% of US iphone users were carrying a second device last year, frequently RAZRs (still). The whole federal government carry BBs. So our mobile web world is Blackberry, iPhone, RAZR...

So, Internet vs Telco: a framework for understanding company behaviours. Not here to slag operators, most problems are a result of silo thinking.

When SV and Bay area companies approach Little Springs, they want iPhone stuff. It used to be they wanted to run anywhere. Nowadays, if it's not Android/Palm/iPhone it's irrelevant. But Internet thinking like this misses 96% of other devices.

Telco thinking: Sprint is not a bad telco from a UX experience, hiring UX since 2007. AT&T hired their first one in 2007!

Telcos tend towards device-specific design... which made it expensive to get content providers involved. They're big on customisation and feature phones. They don't do anything to support smartphones, much - smartphones are the bastard stepchild generating 50% of data revenues. Content providers have to support everything, though, back to 4 years ago.

Hybrid thinking, now: thematic consistency. Not the same web everywhere; tweak slightly for devices. Avoid accesskeys on QWERTY phones. Add padding around buttons for touch devices. Dynamic number of results (5 on RAZR, more on others).

One or more versions (of page, sub-site, or site). Graceful degradation. Page "tweaks".

Q: How's Android affecting the US market?

A: It's on the 4th largest operator. We're expecting to see more.

Q: What about device APIs for things like WRT or Qt?

A: I'm anxiously awaiting data in large enough volumes for me to play with it.

Q: What about applications?

A: If the dev teams are silo'd, I give them separate specs. If they're more sophisticated, I use this approach. With J2ME Polish they can do 1 build a day (seems slow - Ed.).

Gestural Interactions, Younghee Jung & Joe Macleod

Joe: air-kissing is a headfuck.

YJ: We don't remember our first encounter with human beings, but we do remember our first interactions with computers. How do we interact with technology more naturally.

(shows photo of electronic cats)

YJ: Technology is poor at mimicking natural expressions. Verbal communication is only a fraction of how we talk.

JMcL: We fight over videoconferencing suites at work. We have good ones, but they're no better than iChat.

YJ: I pick up new body language easily.

JMcL: The gesture of fingers on lips travels well...

JY: ...but some are very specific.

(I had difficulty taking useful notes of what was an excellent presentation containing oodles of gestures).

Modelling the mobile experience, Bryan Rieger

Started out doing lots of animation, motion graphics. Worked with Buxton. Getting into Processing more recently.

"My journey playing cognitive connect the dots through a road in hell"

Wireframes are "layout, behaviour and flow" - that's a lot of stuff to be putting in a document.

Let's just deal with flow... you've written a wireframe for a screen. What happens next - you imagine what happens and your mind interprets, filling in the blanks.

What happens between the "frames" in wireframes?

Clients require more detail... too much detail.

End up in UML. Bryan shows a standard UML diagram for a light bulb. Standards require literacy. Now we're shipping huge wireframes and literary references... which are hard to manage, get less feedback, are never updated, are hard to change...

So it's too much. So we build a prototype.

Paper is lovely but limited. Requires interpretation, is hard to share. This leaves us with HTML/Flash/Python/Java - requiring programming. HTML works well for web projects tho.

Prototypes are challenging - need development resources, get hijacked by development, fail to find right level of abstraction, unwillingness to iterate from dev team, and suddenly: development is happening in design.

Iterations are opportunities for design. But what's the software equivalent of the cutting room floor?

Demos beautiful little modelling tool.

(Thoughts: is it an issue of trust? wireframes are a tool for communication. within a team, face to face communication is high bandwidth, warm, works well. if a small team can work together and do it... we're ok. Problems come when we need to communicate or validate outside the team. In particular i've seen this when you're haing a client sign off... or when QA is involved to validate your work (whether external or internal))