Friday, 21 June 2013

BRIEFING: ThoughtWorks' QTB on Mobile and the “shattered future”

Some notes from last night’s ThoughtWorks' Quarterly Briefing on Mobile and the “shattered future”

Session 1 : Giles Alexander
Mobile Lead (Europe) at ThoughtWorks

Talked about move from

Clients -> Apps -> Products

Clients are the old world desktop thick clients that started to get replaced but apps and everyone needed an app on their phone. But now increasingly the world is multi-screen and product is across devices, these are just ways of getting to product. It's not just a case of laptops, smartphones and tablets. Also have to consider other input types/devices like siri, Google glass. there are multiple channels and accessibility is important.

Is Google glass just Segway for your face? e.g. Siri is a bit of a gimmick, not used for regular/serious use, is Google Glass the same?

Couple of examples: is a property listings site that started in print media. Business suited the internet well then along came mobile. While developing the app they realised that their asset wasn't the website, it was the property listing DB. The website was just a channel. The natural next step was to do widgets that could be used on other people properties - all just a channel back to their main asset the DB.

Instagram – the app is not the product, social network is but phone form factor isn't great for that. Instead of developing the Android app they could've gone for a desktop web app around the social network side, this could then have been integrated and packaged up with picture taking app into a new iPad app - gain a new way of using product and two new markets.

What is next?

Is payments the next big mobile thing? Giles told an anecdote about being in San Francisco and seeing a Google Wallet NFC reader. He asked what is was and then how often people used it, the answer to the first question was every couple of weeks someone asks that and then about every 4 weeks they use it. Google with Wallet has the technology and channel but no product. Compare this with Apple and iTunes where it has product but not the channel or technology. As a side note aside from people selling NFC solutions I’m not hearing a lot of love for it from the techology industry and nothing at all from actual users, e.g. see for an example of tech press reaction.

If you are in a pub (or other social setting :) with people with same phones it means nothing, it doesn't open up any extra functionality. Why not? Potential here for direct phone to phone functionality? Apple AirDrop is a move in this direction with wifi direct a potential channel that could open up "next big thing in mobile"

in the Q&A session W3C was talked about especially how around HTML5 they have moved from trying to predict and shape the future with standards to distilling down after the fact the best practices. Like a clean-up operation linking up the technology into a coherent whole. (and yes they will always lag behind as a standards body)

Session 2 : Chris Cheshire
Product Designer at ThoughtWorks

Not many notes here as mainly visual presentation going through agile product design process. Interesting example task around designing a log in screen and then getting feedback from neighbour - all within 60 seconds.

couple of points I did pick out are:

·         Growth leads to opportunity
·         Constraints lead to focus

(the constraints here being around mobile form factor - screen size, input methods etc.)

Went through the Build -> measure -> Learn -> build and repeat cycle from the lean start-up world. Pointed out that "build" doesn't have to be code. Design can be sketch for UI. quote of the evening for me was in this section:

 "lo-fi deliverables, with high quality thinking"

Session 3 with Giles Alexander and Jill Irving (front-end web deisgner) going through some highlights in ThoughtWorks Tech Radar.

HTML5 storage (trial)

* either local or session storage
* For replacing cookies - gets around EU cookie legislation and no back and forth with server - allows more data to be stored - so richer experiences are possible, e.g. in a SPA

Responsive Design (trial)

Although trail in the radar, a few cons on this one were illustrated by Jill's work on the Chime For Change project (

* huge development time
* type of application (may not always be appropriate)
* Limitations with automated testing - still very new
*Lack of tooling - again still new

Calatrava -  (asses)

* mobile web framework
* gives  you some patterns built in

SMS & USSD as a UI (adopt)

* feature phones still important (about 48% of global market) especially for example in Africa or South America.
* example project was the "M-pesa" money system in Kenya, 1/2 GDP of Kenya goes through the system. No paper and limited infrastructure needed.

Browser-based templates (asses)

* Instead of generating on server and sending to client send a template and JS engine to render.
* Makes SPAs more responsive
* less data, you're operating more on a service level
* Mentioned a couple of frameworks in this area icanhazJS ( and mustache (

Javascript as a platform and MV* frameworks (trial)

* to be honest not too sure what pros cons were but angular.js ( was recommended (think term data lining came up?) and backbone.js is on hold, as it was first in this space starting to see issues with it.

SASS (adopt)

* SASS - - was used on the Chime For Change project
* becoming de facto standard?
* speed in development was increased compared to hand written CSS3 used on projects either side of Chime for Change
* Powerful when used with Compass (Rails framework -
* Twitter Bootstrap ( was mentioned as being on hold - mainly as it enforces layers of transformation whether you need them or not.


Good event and an interesting topic, especially good hearing some context on the tech radar items from people using them. The only downside was travelling to/from London as I work in sunny Brighton, so I didn't get to spend as long talking and networking after the sessions as I would've liked - it was a school night after all!

Wednesday, 19 June 2013

On pets and projects

While watching the Little Cat Diaries the other day, the experiment comparing cats and dogs behaviour to an earlier experiment with children stuck me. In the original experiment the children were pleased to see parents who left then returned to the room as they saw them as a provider of security.

They repeated this experiment first with dogs, who used their owners as points of reference and providers of security. The cats however, were different. They showed more interest in the stranger present in the room if anything. The conclusion was that the cats saw their owners as providers of resources.

I like to think we can make a (fanciful?) analogy here with project managers and the team. Formal command and control processes guide project managers into becoming dog owners. I would suggest that agile techniques put them in the position of herding cats and therefore "merely" providing the resources needed to achieve the team goals.

Be interested to hear peoples thoughts on this, first time I've tried a pet/project management analogy.

Edit 18/02/2015: Since writing this I think it could apply to many knowledge work scenarios with the process owners or management figures as the pet owner type.

Monday, 17 June 2013

On research and application

I am currently lucky enough to be working on a project where the developers are looking into what they can learn from academic computer science and spiking various options to explore the solution space. This got me thinking to how relatively rarely you see this, in my experience programmers tend not to read industrial journals in the same way that say civil or electrical engineers might. 

One thing that I would expect to see more in agile literature are Grice's conversational maxims (Grice 1975)

Maxim of Quantity:

  • Make your contribution as informative as is required for the current purposes of the exchange.
  • Do not make your contribution more informative than is required.
Maxim of Quality:

  • Do not say what you believe to be false.
  • Do not say that for which you lack adequate evidence.
Maxim of Relation:

  • Be relevant.
Maxim of Manner:

  • Avoid obscurity of expression.
  • Avoid ambiguity.
  • Be brief (avoid unnecessary prolixity).
  • Be orderly.
For me these are very good guidelines when producing user stories. I'm not sure if it is wishful thinking but I'm sure I have seen a reference to Grice's Maxims in relation to writing good user stories, but I can't find it now so any help in tracking down an example would be greatly appreciated.

Another piece of research that we can look for lessons in producing good user experiences is the work of Cherry (1953). This was a great favourite to quote at university in our HCI classes, so has stuck in my mind. Here Cherry introduced the cocktail party problem; you can see similar examples in the mix of fonts, colours and style present in poorly designed brochures, presentations and web sites across the corporate world - as parodied by

I am sure that there are plenty more examples of more research that isn't more widely known, I did consider talking about deep structure but Chomsky's papers on the subject aren't as easy to read for a non-linguist as Grice. I will be on the look out for papers in fields such as linguistics, psychology and knowledge management that I can learn interesting lessons.

Further Reading

On a slightly tangential note which kind of research is best for industry? applied or pure? Shaun Coffey has written a couple of good blog posts on this
Another set of interesting blog posts are Linguistics for software developers I,II and III at The World of Yesterday.


Cherry, E. C. (1953). "Some Experiments on the Recognition of Speech, with One and with Two Ears". Journal of Acoustic Society of America 25 (5): 975–979.
Grice, H. 1975, 'Logic and Conversation', Syntax And Semantics, 3, pp. 41-58, MLA International Bibliography

Should we design better products for older people?

This week I've been having a bit of think about products for an older audience, prompted by this tweet by Tom Peters ("The red bull...