Tuesday 4 October 2011

Over The Air 2011: The FT Web app - We've Got a Website for That

Andrew Betts, Assanka @triblondon

  • An app is:
    • responsive design
    • responsive to human interface (mouse, keyboard, touchscreen, TV remote, …)
  • The Daily app is now generating less than 50 tweets a day (and still going down)
    • Down from over 200
  • iPad web app also works on other devices
    • not just tablets – phones too
    • currently only accessibly on iPad
    • works on Android & QNX but not released yet
    • Android imminent, QNX a few months
  • server serves the same code to all devices
    • client does customisation and caches as much as it can
    • so can go offline and still access pages
  • FT web app
    • 8 months with 3 people
    • then additional 4 months with same people to get Android & Playbook


  • flowed columns and flowing text around fixed elements
    • adobe webkit fork has great flow additions - but not available on devices
    • css3 template layouts – but again not supported
    • so have to measure content and cut it into positioned containers using Javascript
  • content balancing
    • always show a whole number of items across the width
    • done by classifying devices into four groups according to screen size
      • small, medium, large, large wide
  • podcast pages
    • want to keep playing audio even when move to another page
    • put audio player at the top of the DOM, so not altered
    • entire app is in a single page – just swap content in and out
  • swiping between sections
    • continuous carousel made out of three divs
    • middle one is always the current
    • outer ones are preloaded as required
    • implemented swipes using touch gestures
    • have to do your own gesture interpretation
      • distinguish between slow drags and flings


  • playbook has remote web debugging
  • WeinRE can do similar, but can’t debug Javascript
  • TouchScroll allows you to keep headers fixed and snap to columns when swiping across
  • web debugging proxies (e.g. Charles)
  • use desktop for layout, but real device for interaction (swiping)


  • people use native apps differently
    • they tap lightly and fast
    • the web browser waits for fast taps in case there’s a double tap to zoom
    • if you don’t want double tap to zoom
    • Assanka made fastclick

offline access

  • launching app offline
    • need to specify URLs in app manifest
    • if you change a single file, all of the manifest needs to be re-downloaded
    • store as little as possible
    • the more you store, the longer your app will take to launch
    • iOS manifest is buggy – you can get name conflicts with other webapps
      • so make sure you give your manifest a custom name
    • development is hell – things get cached the whole time
      • instead, add a comment that changes every minute (for dev)
      • still leaves you time to refresh a few times to check the cacheing
  • manifest is no good for editorial content
    • local storage is much faster than SQLite
    • so if you only access by key then use it
    • you need permission to store > 5Mb
    • strategy:
      • launch app from web, just store <= 5Mb and prompt to save to home screen
      • saved from home screen, immediately ask for 50Mb and never ask again
    • images downloaded from server as base64 encoded strings
      • can combine images into single requests
      • and can then gzip the whole thing
      • stored in local SQLite
      • rendered into DOM as a data: URI
      • base64 transfer also avoids operator image recompression!
  • analytics
    • can’t use Google analytics
    • log user actions into local DB
    • POST the log when requesting updated content
    • on the server, rewrite the log into an Apache format access log

unresolved issues

  • SSL security: no browser chrome, so no browser padlock
    • trusted, because we tell you…
  • Social media integration – OAuth in separate window doesn’t work
    • have to reload completely when return to app
  • offline adverts:
    • not technically hard, but ad server companies don’t know how to deal with them
    • can’t retract the ad
    • can’t measure clicks
    • can’t click through at all…
  • automated QA – selenium doesn’t really work
    • ended up using lots of people and lots of devices


  • Android is by far the poorest web environment when compared with iOS and QNX
    • mainly due to lack of hardware-accelerated CSS transitions
    • so FT have a native Android app which has a single native component – the gallery to enable swiping
    • the rest of the app is HTML/CSS/JS
  • QNX has a native app too, but only to have a home screen icon and to provide distribution


  • upset Apple?
    • probably not – FT are specific market
  • differences between web app and native
    • web has more sections than native ever had
    • web app preloads content, so people swipe more often
    • as a result web app gets much more interaction
  • is not appearing in the app store an issue?
    • yes, but instead making tactical native apps
    • e.g. FT Top 100 Companies – tells users if you want the full edition, go to the web app

Over The Air 2011: OpenBTS - Open Source GSM

Will Rogers, Senior Consultant at Detica

  • Open Base Transceiver Station: http://openbts.sourceforge.net/
  • software implementation of radio towers
  • USRP: universal software radio peripheral
  • written in C++ on top of GNU Radio
  • fairly stable – maintained by Free Software Foundation
  • only acts as an access point – doesn’t simulate entire mobile network
    • another project: OpenBSC does more
  • but, can translate GSM into VOIP – Asterix
  • originally built by David Burgess (Range Networks) and Harvind Samra
    • Range Networks building commercial implementations (e.g. Femtocells)
  • originally designed for:
  • enables GSM network for $1/month per subscriber
  • hardly uses any power
  • range depends on antenna & height
    • Burning Man covered 5km – with a microwave backhaul
  • supports handset registration
    • requires no pre-provisioning
    • get a text with a code – reply and your IMSI gets added to the asterix
  • some branches support USSD (free data)
  • requirements:
    • hardware:
      • can run the whole thing in a VM
      • USB (for USRP 1), or ethernet (for USRP 2)
    • software:
      • most linuxes (Ubuntu well supported)
      • GNUradio
      • Asterix PBX
  • USRP was chosen as it was available, but it’s not really designed for GSM
    • better to have multiple of 13MHz clock
    • daughterboards available for various RF frequencies
    • need to have GSM-specific one
  • resources
  • channels
    • default is one logical channel for control
    • everything else (7) for voice
    • that means 7 simultaneous handset calls at once
      • e.g. 3 on-network conversations + one outbound
    • if you want more then you need multiple BTS units
    • if want SMS then need to steal a voice channel for control
  • SMS messages need routing, so OpenBTS includes smsqueue which forwards messages
  • limitations
    • doesn’t support live handover of calls
    • no data support (GPRS or Edge)
    • no way of supporting roaming or billing
    • 3G/UMTS boxes are available, but not yet open source
      • OpenBSC may get there first
    • doesn’t support encryption
  • use CC/MNC of 001/01 – these are the test values
  • OpenBTS console has various commands
    • timsi lists connected IMSIs and IMEIs
    • testcall creates a UDP connection to the phone
      • you can then send Layer 3 packets
    • sendrrlp sends a request for location (as mandated by US Gov)
      • can provide info about cell tower locations and phone will calculate location itself

Over The Air 2011: Exploding the Gap Between Web and Native

James Hugman - Engineer at Future Platforms @jhugman

  • Web vs Native is a false dilemma
    • the answer is: it depends, or it’s both
  • often a lot of display in UI
  • story of the glastonbury app
    • Orange app for iPhone, Android and Nokia
  • three/four phases of content:
    • before (and before embargo)
    • during
    • after
  • lots of data
    • 3000 bands, 65 stages – timings could change

experimentation & research

  • assumed offline and native UI
  • but native was too expensive for three platforms
  • how do you make native in web technologies?
    • every phone has a different web view
    • Android users don’t like seeing iPhone UX
    • and Android back button can exit app if you’re not careful
    • there is no release cycle of WebKit
      • manufacturers just take the trunk and fix bugs
    • dev and cpu time spent getting UI just right
  • Titanium: write your UI in Javascript, render natively
    • ListViews either don’t look right, or leak memory
    • doesn’t always deal with latest design patterns – can’t override platform-specific behaviours
  • Impact for iOS: javascript talks to OpenGL
    • experimental & proprietary
    • morphed into appMobi’s DirectCanvas
  • game{closure}
    • pre-alpha – HTML5
    • also node.js
    • debug your mobile app and your browser app all in the same browser
  • but Game UI is not platform UI
    • easier to make cross-platform game UI as the UI is brand-specific, not platform specific
  • important to get events passing between rendering and UI logic
    • all frameworks bundle their own Javascript engine
    • Android users don’t like big apps – Titanium hello world is 6Mb!

new platform

  • Kirin requirements:
    • native, platform appropriate UIs
    • minimal download
  • design:
    • native UI
    • JS application logic
    • native platform
  • advantages:
    • raw events processed natively
    • only app-specific events passed through to app
  • “the keyhole”
    • instantiate an invisible web-view
    • build proxies for objects
    • javascript calls into native and the other way
  • modular javascript using CommonJS
    • each screen has its own module (one file each)
  • threading using asynchronous APIs, inspired by node.js
  • native-specific features available as services
    • e.g. Location, SQL, Network access
    • same Javascript to native bridge
    • JS just uses a require(...)

releasing as open source

  • available now on github
  • as a 0.5 release
  • apache license
  • looking for feedback
  • iOS and Android only at the moment (Qt coming later)
  • Windows Phone 7 might come later


  • testing & debugging:
    • build script runs node.js
      • so can include unit tests at build time with assert
      • have console access
      • no actual debugger
  • why port model code – isn’t it simple?
    • but if using database on device, then model not so portable (Core Data doesn’t port well)
  • porting pain? scaling to iPad?
    • most of pain was electronic programme guide
    • download & syncing

Over The Air 2011: Crap! It doesn't quite look right!

Or… how I learned to stop worrying and set my web sites free

Lyza Danger Gardner, co-founder Cloud Four @lyzadanger

  • Founder of Cloud Four in 2007
  • Explicitly for mobile web
  • Lyza was on the team that built the Obama app
  • Went through the app and realised that there was nothing in the app that couldn’t be done with the web
  • hautelook.com – high performance mobile web
  • deschutes brewery – one web
    • uses geolocation to find where to buy the beer
  • mobile web is hard and getting harder
    • and it’s not just phones any more…
    • car radios, televisions, …
  • and there’s a whole stack every time (any of which can change)
  • in the 1990s, took print ideas and applied them – pixel perfect
    • customers believed that we had control…
    • “could you move the logo a half pixel to the right?”
  • no one can possibly know enough – devices are continually appearing and you still have to deal with the old stuff
  • how do you deal with WYSIWYG for customers…?


  • 10 highly experienced mobile developers
  • working on where we wanted the mobile web to go
  • built http://futurefriend.ly
  • three pages, two images, no interactivity
  • 100 man hours
  • -> not scaleable!

testing is very hard

take heart!

  • relinquish control over a few things we thought we had down pat

  • four considerations:
    1. content like water
      • consider wireframes that demonstrate the flow and flex of content across a continuum of device and window sizes
      • design approach: like proportion – not pixel perfect
      • build functional mockups, so you can show (not tell)
      • it will be an iterative process
      • will not be an overnight change – it’s not a brochure, despite what we told you earlier
      • it’s often surprising how willing customers will be to adapt or modify their content APIs
      • try using textile or markdown in CMS
    2. essentials first
      • not just mobile – pare down to the essentials
      • not just about design – about process, performance, experience for every user
      • start serene and simple
    3. arm the weapons!
      • responsive web design
      • fluid media: 100% width images
      • fluid grids
      • use media queries to enhance (mobile first)
      • see also Responsive Images (by Scott Jehl)
      • Boston Globe is a showcase
      • it’s ok to leave unmanaged gutter in % widths
      • use Modernizr’s modular approach (don’t test everything)
        • but it’s not infallible
      • use server-side work:
        • reordering – moving navigation around
          • android devices are too buggy
        • reduction – smaller images
        • respect – your users: don’t download graphics if you don’t use them
      • user agent sniffing – it ain’t perfect, but it gets the job done
      • don’t be afraid to do some server-side optimization
      • optimise!
        • especially your htaccess or apache config
        • use YSlow
        • make sure you gzip everything you can (not just html)
        • cache manifests are a little tricky to deal with
      • Cloud Four images:
        • server side sizing using WURFL for major sizes
        • common images are then cached
        • then 100% fluid sizing
    4. draw the line
      • set expectations with your customers
      • explain how you don’t have control over everything
      • don’t be afraid to pull out egregious hacks!
      • be ready to fail gracefully
      • this isn’t religion!
  • frameworks:
  • iOS rotation
    • use -webkit-text-size-adjust:none;

Lyza is writing a book – Head First Mobile Web

Over The Air 2011: BBC Digital Public Space

Mo McRoberts - Developer, BBC Archive Development @nevali

  • Trying to make BBC Digital Archive accessible
  • Then working together with other organisations:
    • BFI, Kew, national maritime museum, royal opera house, british library, national archives, national library of scotland
    • have 25–30 organisations who have said yes to accessing data
    • but only have Mo to connect things!
  • lots of separate catalogues
  • each catalogue refers to things in asset stores
    • may not be able to get to asset stores, but linking catalogues by itself is useful
    • also link to external sources such as dbpedia, geonames, etc
  • want to make the archives accessible to people other than archivists
  • golden rule:
    • give everything a single, permanent URI
    • make the data about that thing accessible at that URI
  • could try to fit everything into one giant, extensible XML schema
    • or else just go with RDF…
  • can put all the RDF from catalogues into an RDF Aggregator
  • wanted to find overlaps in the catalogues
  • aggregator evaluates all info coming in and tries to find matches
    • not just exact matches, but close matches too
    • disambiguating is the hard part
  • create lots of stub objects
    • people, places, events, things, …
  • eventually want to have spindle in the hands of the public
  • the archives themselves are slowly being digitised, but it takes quite a while
  • BBC Redux captures and stores TV and radio, transcodes them and makes them available in various forms
    • been running since July 2007 for everything that’s been running centrally (not all local opt-outs)
  • now has an API and developers’ guide
  • available to developers for the duration of OverTheAir:
    • prototype RDF aggregator to query
    • API to Redux
    • references to Redux are not fully tested – may or may not work
  • genome project:
    • scan in, OCR and codify all of the Radio Times issues
    • from 1920 to 2009
    • this and /programmes will provide a public API for all broadcasts ever
  • three windows of content availability:
    1. free to air on iPlayer
    2. commercially useful
    3. out of commercial time: e.g. desert island discs (but no music)
  • aiming to have content available in 10 years’ time
    • BBC Director General has committed to this
  • 1 recent episode of Doctor Who has 80 rights clearances
    • an older episode would be worse as you would have to find the appropriate rights holders

Over The Air 2011: Stolen and lost phones - can mobile phone applications help with the problem?

Detective Sergeant Andy Williams

  • National Mobile Crime Unit – based in Notting Hill
  • Criminals stealing to order
  • Cops are not the most technologically advanced people – when Andy wants something done, he asks his children…
  • in 2001, 45% street crime linked to mobiles
    • this was from the British Crime Survey – not reported crime, but surveyed
  • current stats:
    • 9.7% of all UK crime accounted for by theft of a handset
    • 60% of mobile phones stolen in personal robberies are iPhones or BlackBerrys
      • not just the phone is high value, but the data on the phones
    • avg 8,000 phones stolen every month in london

what happens to stolen phones?

  • used until blocked (by IMEI)
    • IMEI blocking works across UK, 60% of Europe, plus North & South America coming in soon
    • but main export markets are North Africa (mainly Algeria) & Romania
  • some handsets are vulnerable to having their IMEI changed (so can be unblocked)
  • phones used for parts (broken screens, etc)
  • phones used for non-phone functions – mp3 player, etc
  • blocking:
    • operator will block SIM
    • will also request IMEI to be blocked
  • individual can install a theft tracking app, but police would need a signed warrant
    • police can’t monitor 8,000 phones a month
  • IMEIs are personal data in Germany
  • phones offered on eBay, shown as blocked or no signal

immobilise – national property register


  • if device is registered with immobilise, police don’t need to go through RIPA
  • can put anything with a serial number on there
  • can check on people’s phones when stop people on the street
  • private company set up and operated in conjunction with the police

formation of NMPCU

  • initially front line - reducing robbery
  • expanded to all acquisitive crime
  • working at all levels of crime - local through to organised
  • now an offence to offer to reprogram a phone (change the IMEI)

Police Central eCrime Unit

  • trying to combat cyber-criminals
  • looking at denial of service attacks, etc
  • front line police notoriously poor at dealing with cyber crime
  • but no law enforcement agency that specialises in all areas of cyber crime
  • most expertise is in the forensic area
  • judicial system is not set up to deal with cyber crime
  • judicial boundaries don’t help – if online connections are not in UK…
  • recently starting up new kind of officer: Covert Internet Investigator
  • not very many across the country

Case study: organised criminals targeting music events

  • following same bands the whole time
    • bands with mosh pits…
  • Download 2010: 3 people found with 140 phones buried under their tent

Security & new mobile tech

  • Man City gave 20 season ticket holders their tickets on their phone
  • if someone steals your phone, they have access to your wallet, your ticket, your flat…
  • NFC requirements requested by police:
    • PIN required for all payments – not gonna happen!
      • at the moment, 5 payments of £10 until a PIN required
    • capture IMEI during transactions
      • possible but not gonna happen
    • compulsory registration with financial institution
      • may happen

key areas

  • registration at point of sale
  • carphone warehouse register 25,000 phones a day at Xmas
  • only 4 in 10 PIN lock their phone
    • significant barrier
  • locating devices post theft
    • works ok, but not great – won’t work if someone goes into a block of flats
  • identification of a SIM change post theft



  • can find out if an IMEI is stolen
  • some operators run this service for free
  • but otherwise may cost £1 a shot

Friday 9 September 2011

iOSDev UK: The Eternal Sunshine of the Developer Mind

Steve “Scotty” Scott, iDeveloper iDTV, @macdevnet

Scotty gave a great talk complete with loads of cartoons that I can’t remember here. I’ve just noted down the more serious bits…

However, the best slide was by far:

Pocket Dan - from @macdevnet's presentation at iOS Dev UK 2011

  • programming is:
    • 10% science
    • 20% ingenuity
    • 70% getting the two to work together
  • embrace your pain and draw positives from it
  • just because something has failed, doesn’t make you a failure
  • unless you can own the failure, you can’t understand the problem and move on
  • if you’re trying to learn what went wrong, make sure you’re looking at the real issues
    • keep on asking why until you hit the real reason
    • was it the people or the technology?
  • you don’t have time not to do this
  • when you next find a situation that’s negative, find a positive
  • make sure you learn to understand what people are saying, rather than what you are hearing
    • “developers get confused between Xmas & Halloween because DEC 25 = OCT 31”
  • it is impossible to mentor yourself
    • you can’t get out of your own assumptions
    • you don’t need someone highly experienced to mentor you — you just have to explain yourself and get someone to ask, “how do you know that’s true?”
  • often our thinking is shaped by a whole load of things that you haven’t let go
    • process it and let it go
  • we don’t tend to learn a lot from success
    • that’s ok - we just need to do the same thing again

iOSDev UK: Design Considerations for Educational Apps

Fraser Speirs, Head of Computing & IT, Cedars School of Excellence, @fraserspeirs


  • last year gave every child an iPad
    • only 100 pupils
    • had 220 people come to visit the school…
  • when you give people the internet the whole time, you sometimes get unexpected results
    • Fraser showed a slide of coursework on cell nuclei, decorated with a background showing the Statue of Darth Liberty
  • sitting around iPads — everybody faces each other rather than all facing the screen at the front
  • avoiding the ceremonial computer lab — moving to casual computing
  • beautiful artwork created by kids on iPads, within a month of receiving them
  • it’s not just the iPads, it’s the 1:1 — the 1:1 is more important
  • Fraser’s daughter is 4.5 — just started school
    • will graduate from university in Summer 2029
    • “we are already teaching the citizens of the 22nd century”
  • looking at investment as kids’ chairs & tables
    • not as a guarantee that scores will go up

Do’s and Don’ts for apps in schools

  • don’t assume the internet works correctly
    • schools change what internet is available through frequent policy changes
    • youtube is often turned off
  • teaching fashions come and go regularly
  • in-app purchase doesn’t work in schools
    • central purchasing or gifting
    • e.g. PCalc has a full version that can be purchased at once
  • don’t assume your users can (will) read
    • use conventions wisely (keep the back button in top left corner)
  • use push notifications sparingly
    • no good advertising to kids in school — they don’t have the app store password anyway
  • watch out for number of devices nearby
    • could be 20-30 devices around
    • infrastructure may cope, but leave room in your UI
  • limit or prevent app store interactions
    • no good in schools
    • confuses kids; annoying for teachers
    • that goes for “review me now” too
  • teachers need access to content
    • support the photos app
  • don’t promote facebook
    • facebook can be a major source of anxiety for many children
  • watch out for shaking gestures — not good for
  • don’t use bad language (and try to avoid double-entendres and local slang too). Some examples:
  • be very careful with user data — especially with location
  • talk to teachers and test with actual children
    • Fraser’s school does not have the scale to be a beta tester…
  • watch out for different curricula in different countries
  • walk through guide in the app
  • kids can use loads of apps to edit graphics, passing the image through the photos app
  • use sharing effectively
    • use “Open In…”
    • avoid huge sharing option lists
  • show proof of completion
  • avoid (penalise) random hits
  • structure + headroom = creativity
    • app idea: make toontastic for creative writing
  • show user activity
    • e.g. Brushes lets you record all your strokes and play them back as a quicktime video
  • localisation is useful even if your app is UK-specific
    • e.g. Iraqi boy with a 1:1 iPod touch switched it to Farsi and used Google Image Search to show pictures of what he wanted to the teacher
  • support projectors & AirPlay
    • don’t offer resolutions for external display — just pick one and do it well
  • there is a control to turn off Game Center at a policy level
    • so go ahead and put it in the app but make the rest of the app work without it
  • gap in the middle for 7-10 year olds
    • need more apps like toontastic — structure provided, but space for creation
    • older kids can use general content apps
    • younger kids don’t need so much freedom
    • using iThoughts HD for mindmap, then writing in Pages

example apps


  • research?
    • study with university of western scotland
    • two lessons back to back: one with iPad, one with paper & pencil
    • same teacher, same children
    • with paper & pencil, boys and some girls had less emotional engagement
    • with iPad emotional engagement of all pupils was brought up to same level as best kids
    • being submitted to BJET, but may not be published yet
  • separate educational version of an app?
    • kids want the real thing
    • universal design is best
    • Fraser tries to buy things off the shelf rather than waiting for educational specific versions
  • damages?
    • only had one — parent ran it over with Land Cruiser!
    • kids are careful — the iPad has their name on it
  • teachers adapting to technology?
    • about half of the teachers had iPhones/iPod Touches before the programme started
    • the iPad is significantly more approachable than other computers
  • how do you find apps?
    • school subscribes to Tap! magazine…
    • more popular than the TES :-)

iOSDev UK: Standing Out from the Crowd

Craig Lockwood, HuwDavid, @craiginwales

  • put a QR code on the presentation screen for a voting web page
  • pre-render your icon so you have control of the gloss
  • localisation
    • french, dutch, german, italian translations pay dividends
  • app microsite
  • using social media
    • shout loudly yourself
    • and get your users to shout louder
    • “if you’re not ethical, at least be targeted”
  • make your app meta data relevant
  • watch out for the app size
    • you can’t download an app > 20Mb over 3G
    • you have one opportunity to sell — don’t waste it
  • niche press works well for niche products
    • e.g. rare pig breeds app (Guide to Pig Keeping), got featured in Farmers Weekly and got 6,000 downloads in a short period
  • getting designers:
    • there are plenty of media students who are looking for portfolio work…


  • how to deal with app store feedback complaints?
    • point to the app website & twitter account within the app
    • people look at the reviews more as the cost goes up (even if it’s only to £2.99)
    • get your friends and family to review when you release — get in first with 5 star reviews
    • good screenshots can filter out people who don’t understand the app
    • price tier 2 gets less scathing reviews than tier 1 & free

iOSDev UK: Designing multi-user, single device interfaces on the iPad

Kate Ho, interface3, @kateho

  • Started by designing for Microsoft Tablet
    • kids started saying “this would be really cool an iPad…”

Example multi-user apps

Multi-user (sharing a single device at the same time)

  • Versus Games:
    • Examples: PaddleBattle, Dorfball(?), Table Twister, Touch of Fun
    • Very simple games: you’d think people would get bored, but people get very competitive
    • “You can only play for 30 seconds at a time without killing each other” — playing with 8 year-olds can be very bad
    • Best place to find inspiration for these games are the Wii mini games (Raving Rabbids, etc)
  • Co-op Games:
    • Complete an objective together
    • from interface3: iHave (just released)
    • who has the maths answer?
    • collectively get as many points as possible
    • SliceHD — maybe not meant for multiplayer, but great for kids!
  • Games with a twist:
    • one idea: two people playing on an iPad, and another player on a
  • Creative
  • Exploration scenarios
    • Topsee — can have a look at something and pass it over to someone else
    • interface3 interactive mortgage guide on a Surface
    • multitouch is better than keyboard since you don’t have to ask permission from the other person — just reach in a grab
  • Small group interactions
    • one person in charge and two to three people learning over the same device
    • interface3 built CoachAssist


  • design without orientation
    • circular buttons with both-way-up text
    • rotate the text every now and then
    • draggable, rotatable objects
  • try to avoid one player’s actions getting in the way of others
  • design for short interactions
    • around an iPad people are sharing personal space
    • especially if they have to put their head over the screen
  • make sure players aren’t kept waiting
  • don’t have too many complex gestures
    • “gestures are like the 21st Century command line”
    • you shouldn’t spend too much time explaining yourself
  • create shared experiences
    • what could two people do together that they couldn’t do by themselves

iOS Dev UK: Your App Sounds Great

Dave Addey, Agant Ltd, @daveaddey

This was one of the barcamp slots in the evening. Dave went through the presentation he gave previously at NSConference on VoiceOver, Apple's device support for blind and partially sighted users.

  • RNIB have an accessible app of the month
    • they’re really interested in helping people
  • 2m blind or partially sighted people in the UK
    • equivalent to population of Birmingham, or lefties, or gingers!
  • How it works:
    • label - description
    • hint - results of interaction
    • traits - only need if making a custom control
  • triple tap with voiceover enabled to turn screen curtain on — blacks out the screen so you can test it without cheating
  • use UIAccessibilityPostNotification(UIAccessibilityNotification, ...) to post sounds on events rather than touches
  • iOS knows quite a lot of UK place names, but not all (and especially not Welsh names)
  • can set your own usability tags, but uses normal spelling, not phonetic characters
    • can use say "word" on a Mac to test
  • can define accessibility containers to group stuff
  • it’s not just about making it accessible for a blind user or a partially sighted user, it’s also about making it usable for a sighted and non-sighted person using the app at the same time
  • At the bottom of accessibility options there’s a triple click home option — you can make this toggle VoiceOver
  • Maps do not have accessibility other than the pins
  • If stuff is still being selected by VoiceOver, then you might need to set them to be disabled

Thursday 8 September 2011

iOSDev UK: Robots!!

Mark Neal, Co-ordinator for the Intelligent Robotics Research Group, Aberystwyth University

  • learning & adaptation
    • neuro-endocrine control
  • visual navigation
    • robots with cameras on top finding out where they are and how they are standing
    • gyroscopes etc don’t always work in harsh environments
    • map-building
  • control systems
    • trying to make things that are redundant and reconfigurable by themselves
  • try to get out of the lab!
    • sensors may start giving you junk…
    • ideally having stuff work over a few years
    • watch out for “Dalek syndrome” — falling down stairs
    • flexibility tends to be reversible, adaptation tends not
  • department suffers from too much kit and not enough people
    • started in 1998/99
    • now have about 10 wheeled robots
    • 2 and 4 wheel pioneers — not enough ground clearance so best indoors
    • have had balloons and kits
    • now have quadracopters…
    • also have sailing robots
  • robot: autonomous
    • try to avoid remote control other than start/stop
  • would like to buy off the shelf and build software
    • works for little indoor bots
    • but bigger ones don’t really work outside
    • better to build yourself, or at least adapt
  • pioneer
    • linux box on wheels
    • 16 sonars
    • laser scanners and grass don’t mix…
  • iCub — fancy toy
    • human-shaped but can’t walk
    • investigating how kids learn to do hand-eye coordination
    • weighs 400kg
    • 4 landrover sized tyres
    • have done lots of work laser scanning monuments
  • ARGO
    • 6-wheel drive amphibious
    • £10K and then convert with a few more £K to make an autonomous robot
    • doing the same with GWiz electric cars
    • ARGO planned to be used as a radar tug in Greenland
    • power is the killer
  • aerial robots
    • had three helium balloons navigating in formation
    • kite with aerial photographing — software is to stabilise the image based only on the camera
  • sailing robots: Beagle B
    • 3.6m long
    • disabled sailor’s boat
    • vertical aerofoil wing on top instead of a sail
    • has to be autonomous since the Wi-Fi only extends about 30m
    • control system designed to use as little rudder and ropes as possible
    • almost no power to run: < 5W
    • 6W from solar panels
    • unusual to have an autonomous robot that lasts more than a few hours
    • these last at least 49 hours!

iOSDev UK: Making Money with In-App Purchases

Dave Verwer, shinydevelopment, @daveverwer

Developing in-app purchases in the Explore Flickr app

  • purchases can be:
    • content, functionality (permanent purchases)
    • services, subscriptions (repeatable purchases)
  • have to design your own store
  • in-app purchases restrictions:
    • no promo codes or volume purchases
  • store should answer:
    • what is this store?
    • what will I get if I upgrade?
    • big green friendly buy button
  • ruby script to switch info plist based on DEBUG/RELEASE — needed to switch between versions
  • measure success with analytics
    • log each stage to capture where people fall out
    • e.g. store shown, video played, upgrade button tapped, upgrade process complete
  • 1.6% conversion from Explore Flickr (from those who view the store)
  • A/B testing for store designs
    • HuffPost do A/B testing on headlines
    • have 3 choices for first hour, then automatically chosen
    • be consistent with presentation (don’t let people know we’re A/B testing them)
    • need to know if we’re still A/B testing
    • put both bits of code in app, and choose according to web check on first launch
  • Results:
    • store -> video -> upgrade pressed -> upgraded
    • A: 100% -> 7.5% -> 3.2% -> 1.6%
    • B: 100% -> 9.5% -> 3.5% -> 1.8%
    • interesting stat is that video
  • What next?
    • make the store more dynamic
    • downloaded plist file for wording
    • HTML for whole store page (but would need to download and cache it)

iOSDev UK: Mobile Apps: Bringing Together Real and Online Worlds

Graeme Gibson, AppSherpas

  • iOS device as controller
    • an interface to home automation using DMX
  • existing products:
    • POSCard: point of sale mobile commerce at low cost
    • Print&Post: Royal Mail from an iPhone
  • use eye movements to control a device
  • mobile image discovery
    • scan an image instead of a QR code
    • extracts “DNA” of image
    • matches against database of monochrome images
    • 3-5s response on 3G (< 1s on Wi-Fi)
    • 100% accuracy for flat objects with a reasonable amount of light, that are large enough in the phot
    • 70-80% accuracy with less light and > 15% perspective
    • unlike QR codes, works for distant media (e.g. poster on the other side of the road)
    • also works for a trailer on the TV
  • indoor wifi location is already available with Cisco kit
    • no extra client kit
    • extra stuff needed in the AP

iOSDev UK: Coding for your Future Self

Martin Pilkington, @pilky

  • there are three you’s
    • now — doing the work
    • future — code guru
    • past — got let near your computer and vomited all over your code…
  • consistent formatting — follow conventions
    • don’t fight the conventions
  • composition vs subclassing
    • cocoa often better to use composition
  • copy immutable classes — don’t use a reference
  • don’t ship code with exceptions
    • in Objective-C they’re for invalid state — programming errors
    • use NSError instead
  • naming
    • don’t abbreviate
    • no namespaces, so prefix all your classes, preferably with 3+ chars
    • prefix category methods on other classes too, e.g. abc_categoryMethod
    • capitalise acronyms
    • if last param is error return, should be error:
  • if you comment every method then you’ll be in the habit of commenting when it counts
    • not sure I totally agree — comments can get out of date with the code. perhaps better to comment longer code pieces rather than each and every method
  • large classes and large methods are unmaintainable
    • also splits out more stuff into back-end code
    • better for testing, better for multi-platform
  • better to inject dependencies (tell, don’t ask)
    • or at least expose a property to set during tests
    • if do so, then either set default in init, or use lazy construction in the getter method
  • notifications
    • can also be distributed to other devices
    • see kellabyte.com for continuous client
  • regular refactoring:
    • always leave the campground cleaner than you found it
    • have spring cleaning days/hours
    • lots of little refactors mean less big rewrites!

iOSDev UK: Adapting Content for Apps

Dave Addey & Alyson Fielding, Agant Ltd, @daveaddey & @alysonf

  • Why an app?
    • Can you do something with it in dead time?
    • It’s always there when you need it
    • Would you use it yourself?
  • Preparing content
    • content definition lets you split up content into small pieces
  • iPhone vs iPad
    • use cases are different
    • e.g. full page illustrations just don’t work on an iPhone — universal app just doesn’t show them
  • network content:
    • assume no network and make as many things possible as you can
    • then download & cache what you need when network becomes available
    • same goes for submitting stuff — add it to a queue and submit it when a network becomes available
    • e.g. QI app submit a fact
    • provide the app bundle with some initial content to get started
    • if you have information always show it — but show how old it is

content formats

  • HTML
  • Property list
  • Custom XML
  • NSAttributedString
  • Core Data store
  • SQLite database
  • bundled media files
  • text files — e.g. QI facts to rate
  • PDF
  • e.g. QI app
    • books came as ePub (HTML)
    • needed tidying, but was very useful
    • errors could be spotted & fixed directly
    • however, not the right format to put in the app
    • used script to transfer into NSAttributedString
    • better presentation
    • better layout for images & text
    • better pagination
    • content definition really helped
  • e.g. Malcolm Tucker
    • email views driven from plist
    • Aly edited directly in XCode and rebuild to check
    • email content in HTML
    • attachments in PDF
  • e.g. Arsenal app
    • already had a CMS for the website
    • beginning of project — defined an API
    • tweaked the API throughout development, but had something to work from right at the beginning

Helping content experts

  • work hand in hand with them from the beginning
  • make sure they have a real device that they’re using every day
  • try to let the content expert able to make their own build of the app as they change the content
    • anyone working on the content has XCode installed and knows how to build it
    • they also have access to check stuff back in
  • let them play with your toys — it’s fun!
  • put the content in with the development


  • 2.7 million stations are picked from UK Trains picker every month (~88k per day)


  • testing
    • looking to do more
    • UI testing is a bit of a faff, but is possible

iOSDev UK: Tap to Experiment

Chris Ross, Osmosis Apps, @darkrock

An attempt to find success on the AppStore

  • App: Tap to Chat
    • Other chat apps look very similar — buddy lists & tab bars
    • Decided to try something different — picture-based
  • Go along to a nearby group (e.g. Brighton iPhone Creators)
  • Experiment #1: universal Facebook chat app with a novel UI
    • 1.5 weeks each for two people
    • Used pre-existing code from other apps (Facebook XMPP chat)
  • Collaboration helps — both to evolve good ideas and filter bad ideas
  • Can appeal app store rejections, even if you don’t change the code (e.g. if your app relies on a third party that was down during testing)
  • Don’t underestimate the phenomenal power of the Christmas period
    • e.g. EA drop their prices just before Xmas, their apps go to the top, and their downloads rocket
  • Experiment #1.5:
    • iAds seeing only 10-15% fill rate
    • Apple pay you just to show the advert
    • Admob have a higher fill rate, but only pay you for click-through
    • More differentiation with paid app
    • Removing adverts is not enough to get people to buy the paid version
    • Added “share app on friends’ walls”
    • had a spike -> 1000 shares a day
    • revenue jumped to £4-4.5K / month
  • Experiment #2:
    • Started a company to house the app
    • Rewrite the code
    • Changed the facebook (spamming)sharing since Facebook complained…
    • but they were polite
    • Added Google chat, AIM + others
    • More free apps: one per API — better upgrade path (get all in one app)
    • Got a designer
  • Aimed to do all that in two weeks…
    • but took three weeks from 6am-11pm
    • downloadDidFailWithError is a private API
  • Got an expedited AppStore review to be in store in time for Apple Design Awards
  • Results:
    • Revenue jumped to c.£6k/month
    • Difficult to convert people from v1 to v2 (especially since v2 was on a new (company) iTunes account)
  • Success in the AppStore?
    • Overall stats:
    • Mean amount of money made: £30,000
    • Median amount made: £600
    • Tap to Chat:
    • 18% revenue from paid apps (18K downloads)
    • 82% revenue from adverts in free (500K downloads)
    • £40K made so far
  • Moving to using mopub to do advertising
    • provides more control on the server side
  • Mistakes
    • changed sharing in v2 — less visibility
    • no push notifications in v2 (but kind of a choice anyway)
    • transitioning to a new iTunes Connect account
  • Next steps
    • building a backend server for push notifications
    • building libraries for MSN & AIM
    • improving user retention:
    • Osmo character offers advice and news


  • Facebook App ID
    • can share same app ID between apps
    • v1 & v2 (different iTunes Accounts) and free apps use same facebook app ID
  • Facebook spamming guidelines
    • you must have a single action per share
    • you must allow the user to edit their text on others’ walls
    • If there is an issue, facebook contact you to say that you have to resolve the issue in 24hrs — but they need you to respond in that time
    • you can ask for a grace period
    • Tap to Chat asked for 2 weeks
  • Transferring iTunes Accounts
    • can convert a personal account into a corporate account if you ask
  • Experiments with price?
    • v1: 59p
    • aim to bump the price with each added network
    • “no point putting things for less than £2 on the app store — if people have made a decision to buy it, then they’ll buy it…”

iOSDev UK: Handling the Press

Chris Phin, Editor, Tap! Magazine, @chrisphin

Or, “How to get five-star reviews, sell millions of apps, and retire six months from now — guaranteed!”

  • Getting an app noticed:
    • Exposure
    • Endorsement
    • Tap! magazine really want to embrace developers
    • Purchase
    • 91% of readers buy recommended apps
  • UK magazines make money from selling issues
    • In the US it’s more based on advertising
  • How reviews are chosen?
    • Gut feeling from the editors
    • Fitting in to specific sections
  • How to piss off an editor?
    • Not knowing the magazine title or anything about it…
    • Unfocussed pitching
    • Aggressiveness
    • Choosing the wrong comms channel (email/SMS/phone)
  • How to make an editor happy?
    • Devs with passion & high standards
    • Personal connection — trust other devs’ feelings
  • Freelancers
    • e.g. Craig Gennell — Tap! mag contributing editor for games
    • Some are integral part of team; some are chancers…
    • But help them as much as possible
  • Press releases
    • Same rules as any other content — first line should be who made the app, its name and what does it do
    • Links — to the web site and the app store
    • Contact details
    • include twitter
    • After all this, can put in description of company (but not before)
  • Website
    • What it is — in as few words as possible
    • Price — including details of promotions (if poss)
    • Screenshots — equinux.com does a good media room
    • Contact details — again, specific media details if poss
    • Contact forms not so good as the sender can’t track the outgoing email
    • So have an obfuscated email address on the page
    • Reviewers’ guide
    • Often hooked around a narrative
    • Opportunity to guide the review — pick out USPs, etc
  • What to do when you get a review
    • Read it! Not just the score…
    • Take any feedback
    • app reviewers see a lot of apps, so maybe a little more informed
    • but they are just another individual user!
    • Shout about good reviews
  • Other ways to get in a magazine
    • Not just full reviews: app roundups, features, updates
    • Building relationships leads to tweets etc


  • innovative ways of catching attention
    • direct mail involving cookies!
  • press area
    • often include reviews from other magazines (but that’s not useful for reviewers)
    • screenshots, hi-res logos, videos
    • useful to have a zip
  • beta builds
    • interesting from bigger apps (well-known, anticipated)
    • Chris loves TestFlight
  • mailing out
    • really targeted, passionate, individualized approach to 5 or so key targets
    • mailshot out the rest
  • screencasts?
    • prefer image galleries as can skim them
    • otherwise, 20 seconds max!

iOSDev UK: iPad-native Game Design: Exploring a New Gaming Interface

Gareth Jenkins, @36peas

  • iPad specific — using the iPad interface as primary interface to game mechanic
  • Multi-touch interfaces don’t work when you can’t see what you’re interfacing with
  • The iPad is more likely a shared device
  • iPad player more likely on the sofa than the toilet :-)
    • i.e. usage is more purposeful rather than filling time
  • areas of focus:
    • take advantage of space available
    • think about appropriate gestures
    • think about gaming context
    • think outside the (phone) box
    • iPad specific does not mean exclusively iPad — take the idea elsewhere as well
  • examples:
  • iPad provides more room for dedicated interaction areas
    • e.g. left hand & right hand controls on edges + general interaction in middle
  • ways to think about it
    • play lots of iPad games
    • play iPhone games scaled up and work out what’s wrong
    • look at the fingerprints on your device!

iOSDev UK: Animation for Serious Apps

Neil Taylor, Aberystwyth University, @digidol

  • CALayer is not actually the view — it’s the model
  • Old-style UIView animations are now discouraged — start to use blocks instead
    • block-style also allows you to add further animations on completion
  • CALayer animation is slightly different
    • animate position, not centre
    • bounds, not frame
    • values are animated, not changed
    • CAAnimation setFromValue:/setToValue:
  • Keyframe animation lets you animate across a complex path
    • Core Animation will calculate intermediate frames
    • e.g. shopping cart items thrown into a cart at the bottom of the screen
  • Other bits
    • can have transactions to tie animations together
  • More useful references in slides…

iOSDev UK: Real-World Data (or There and Back Again)

Hamish Allan, Olive Toast

The story of writing Files Pro — an app to take files with you on an iOS device.

  • Used Deusty’s CocoaHTTPServer
  • Dropbox has a nice API
    • operations are aynchronous
  • Gamekit makes device to device connection over bluetooth easy
  • Could use HTML5 to make a PC-based interface to an iOS app
    • Visit a web page served from the device from your PC and see a flexible app within your browser
  • iCloud
    • NSFilePresenter tells you when a file transfer has completed
    • iCloud syncs the meta-data about files first, using NSMetadataQuery
  • “Your market is not power users”
  • Apple is moving towards a flat list of files with search, rather than a hierarchical system


  • No hooks in iOS for AirDrop (yet?)
  • Nor any GameKit APIs which talk to desktop

Wednesday 7 September 2011

iOSDev UK: Using TDD to write an iOS App

Graham Lee, professional in-betweener, @iamleeg

Or, “What is TDD and why should you use it?”

  • discovering bugs is not the point of testing at all
    • instead, you are proving that there aren’t bugs
  • once we’ve fixed bugs, we don’t want to see them ever again
    • tests can ensure that regressions don’t come back
  • TDD allows us to prevent bugs from ever happening!
    • you won’t prove that the app works how the customer expects, but you will at least prove that it works how you expect it to work…
  • TDD imposes black-box thinking for the developer
    • makes you think about how the code should be designed and scoped
  • accurate planning: we know how much we’ve done
    • and we can be honest how much we have done
  • TDD does not:
    • ensure that the developer understood the requirements!
    • ensure that the requirements remain static
    • ensure that pieces work together (unless you add integration tests)
  • tests should be short and have descriptive, English names
    • e.g. testDatesOnTheSameDayAreConsideredSame
    • general pattern
  • tests should be fast — well under a hundredth of a second each, so a second or so for all of them
    • avoid integration tests in unit testing since they take too long
    • don’t interrupt your concentration by waiting for tests
  • as a result, your classes will be smaller and have obvious effects
    • any side-effects are few and easy to predict
    • if your test fixture gets big, then that’s a sign that you need to refactor (possibly including the tests!)
  • TDD encourages “tell, don’t ask” configuration
    • inversion of control
    • pass in helper data rather than discover it internally
  • avoiding testing everything at once:
    • use fake objects (with same interfaces) to provide simulated interactions
    • use mock objects to record and verify interactions
  • Objective-C mock frameworks:
  • Code coverage is useful for adding tests to an existing app
    • Not so useful for building new code
    • If you’re not covering code with TDD, then you’re kind of cheating yourself


  • @pilky knows about using the accessibility framework to write automated UI tests using javascript
  • can use XCodeBuild to run unit tests from command line
  • use GHUnit instead of built-in OCUnit to output JUnit XML reports
  • iOS Enterprise Development — O’Reilly book by James Turner
    • includes lots of useful
  • squish automated GUI testing?
  • test code linking…
    • app should be plugin host, providing linked libraries
    • but it doesn’t work — have to link yourself from test code

iOSDev UK: Building Custom Controls with UIView

Rory Prior, ThinkMac Software, @roryprior

  • generally subclass UIView directly
    • can subclass other controls, but things might not happen how you expect since lots of things happen in the background
    • and you may need to use private APIs…
  • override methods:
    • initWithFrame for programmatic creation
    • initWithCoder for IB-created views
    • drawRect for actual drawing
  • UIKit uses top left as origin
    • but CoreGraphics uses bottom left…
  • adding UIImageView is easy
    • but quite heavyweight
    • instead can draw a UIImage directly
  • similarly, can use UILabel or draw string directly
    • NSString drawAtPoint:withFont:
    • NSString drawInRect:withFont:
    • NSString sizeWithFont:
  • drawing shapes:
    • CoreGraphics (nasty low-level C stuff :-) )
    • UIBezierPath (introduced in iOS 3.2)
  • complicated graphics often still done better by using bitmaps — UIBezierPath can be processor-intensive for lots of lines
  • UIColor can fill in patterns as well as flat colour

user interaction

  • override UIResponder methods to detect touches
  • you’ll need UIGestureRecognizers to detect swipes, pinches, etc
  • but use sub-views of UIButton etc to make thins much easier
  • see slides for nice example of adding UIResponder and UIGestureRecognizer
  • use the delegate pattern to send feedback from your view to the rest of your app

iOSDev UK: Beyond NSLog

Tim Isted, @timisted

NSLog, XCode and gdb

  • useful macros for logging:
    • __FILE__ (full path)
    • __LINE__
    • __FUNCTION__ (and __PRETTY_FUNCTION__)
  • NSStringFromSelector(_cmd) gives you current message
    • Lots of these useful NSString functions, e.g. NSStringFromCGRect
  • use macros in log define
    • non-debug version should be something like: TILog(...) do {} while (0)
  • XCode preferences > Behaviours
    • Run starts — can choose what displays
  • XCode also has a variables view, hidden in the next pane of the debugger
  • add breakpoints for exceptions or non-source code by using little plus button at bottom of breakpoints pane
  • breakpoints have really useful options
    • log to console on hit (with auto hit count)
    • continue automatically
    • only do stuff on conditions
  • gdb commands:
    • s = step = Step In
    • m = Step Over
    • c = Continue
    • p = Print
    • po = Print Object
  • debugging Core Data: use [self valueForKey:@"propertyName"]
  • can use addresses instead of variable names in po
  • can make breakpoints user-specific instead of project-specific


  • Time Profiler — great for catching infinite loops!
    • shows you time spent at certain places in call stack
    • tick the “Show Obj-C Only” checkbox
    • look for purple user symbols!
  • Heap Shot tool find leaks
  • quite a few WWDC videos on Instruments

iOSDev UK: Programming iOS Sensors

Alasdair Allan, Babilim Light Industries


Magnetometer (it’s not a digital compass!)

  • 4th gen iPod Touch doesn’t have magnetometer
    • so no outside AR apps without markers
  • UIAccelerometer API newly deprecated for CoreMotion in iOS5
  • if you want compass heading but not location, then just start up [locationManager startUpdatingHeading]
    • you won’t get location updates warning
  • however, magnetic north varies across the world
    • there’s a big lookup table in the iPhone that can translate the magnetic heading into true north
    • so you need actual location to work this out
  • watch out for device orientation: magnetometer always reports heading pointing out of top of device
    • need to rotate according to device orientation…
  • local magnetic anomalies cause a fluctuating magnetic field — which is when it tells you to wave your device around
  • Earth’s magnetic pole is a quadrapole, not a bipole — it swaps over every now and then and the north pole goes south

Gyroscope & Accelerometer (CoreMotion)

  • iPhone 4 has more bits in its accelerometer sampler
  • combining gyroscope and accelerometer provides very accurate device attitude
  • if there’s no natural timer in your app, then you may have to use the push API
    • otherwise much easier to use pull API
  • CMMotionManager should be treated as a singleton (but API allows you to create multiples…)
  • monitoring does take a lot of CPU, so remember to stop it when you’re finished
    • device motion at 100 samples/sec uses 65% of iPhone 4 CPU
    • see “Pushing Device Motion” slide
  • you can fetch a frame of reference and then work out attitude relative to that

AR Toolkits

External accessories

Monday 4 July 2011

MomoLondon: Developer Economics Report 2011

This week’s Mobile Monday was focussed around the Vision Mobile Developer Economics Report 2011. It’s a great report — just like last year. A brilliant idea from BlueVia to open up their research and very well executed by Vision Mobile.

It was a good panel too — with Simon Walker providing the stats on the past and a balance of present and future from the three others.

Summary of the Developer Economics Report 2011

Presented by Eli Camillieri @visionmobile

  • interviewed over 900 developers worldwide
  • also interviewed brands as to what they wanted
  • mobile web accelerating into third position after Android then iOS
    • overtaken JavaME, Symbian and Blackberry since last year
  • Windows Phone 7 not in second place but people want to develop on it
  • Symbian & JavaME now completely out of the equation
  • Talking about addressable market: put the app in front of people who will use it and continue using it
  • iOS still leads for monetisation, but mobile web has the least broken expectations
  • Over 20% of JavaME and Blackberry developers building over 10 versions of each app
  • Brands journey through mobile from iOS, through Android to mobile web (then eventually to all mobile)
    • but most organisations are still on the first step and just about taking the second…


Chaired by Eli Camillieri of Vision Mobile.

  • Simon Davies, ex-Snaptu @simonmd
    • taking smart-ish apps to developing markets
    • Snaptu sold to Facebook in April
  • Simon Walker, ComScore @comscoreEMEA
    • 48.5 million used a mobile phone to do something
    • 23 million people downloaded an app
  • Chad Cribbins, Sapient Nitro @chadcribbins
  • Tom Hume, Future Platforms @twhume
    • 100K downloads for Orange Glastonbury app
    • work across pretty much any platform that’s out there (and quite a few that aren’t yet)

Native vs web

  • CC: lots of work to start across all platforms
    • if there’s something that you can do that accesses the device itself, then go for native, otherwise go for mobile web
  • TH: there’s an awful lot of wishful thinking in the industry
    • expectations of performance are being driven by native
    • the web doesn’t offer that yet
    • in fact, native will always be better
    • so web technologies will always be slightly behind what the user expects
  • SW: bank usage:
    • only 500K browsed Lloyds site on mobile web last year and raised only slightly this year
    • NatWest mobile web 250K last year, 495K this year; 470K app usage this year catching up fast

Commercials: which are the most successful models?

  • SD: last thing to arrive in a marketplace is revenue
    • setting out to build a business at the immature stage: either have a very clear idea of business model, or else aim for selling the business
  • TH: Orange (Glasto) & BBC apps about marketing and exposure, not about making a return
  • CC: banks going after a more connected service — trying to avoid churn
    • cf. autotrader app about capturing number plates and going straight to sales
  • SW: in Europe 72% of mobile users don’t use an app at all
  • EC: unless some fail, we won’t see innovation

Localisation — are developers looking at a local level?

  • SD: at this stage of the marketplace you really do need to be as global as you can
  • TH: most localisation-driven apps at FP have been OEM ones — wanting to launch worldwide
  • TH: UK is well ahead of rest of Europe in smartphone Europe
    • so deal with UK first since you will get best returns and then attack rest of Europe

Importance of the social curve

  • SW: Facebook April 2011: 3.6 billion minutes on mobile
    • May 2010 8.2 million browser / 2.4 million app
    • May 2011 10 million browser / 9 million app
  • TH: can’t remember the last time we got a briefing that didn’t include sharing with Facebook or Twitter — it’s just a standard part of apps these days

Are app stores declining? How do people find apps?

  • EC: traffic to and from app stores will continue to increase, BUT brands are now driving the apps themselves directly (rather than people just browsing the app stores themselves)
  • SD: app stores are just a place to discover apps — in the beginning the only place
  • SW: most people accessing app stores from device rather than PC
    • data is more expensive in Europe
  • EC: Current app stores could be supermarkets

Economics: earning an income from apps

  • EC: How do you bring an app to market?
    • How come there aren’t that many marketing people in app companies?
    • App stores give you no idea who’s buying your app…
    • Need to marry technical with marketing & commercial
    • North America doing better at that than Europe
    • Techies understanding who they need to partner with
  • TH: difficult to find good people, especially speculatively
  • SD: met his technical partner at a barbecue :-)

Are people leaving the market if it’s such a tough gig?

  • EC: just because you’re not making enough money, doesn’t mean that you’re going to stop
    • e.g I’m sure many musicians are unsatisfied with the amount of money they are making
  • TH: we’ve just been on the Apprentice — in the public perception, this is a really hot space to be
  • SD: Dragon’s Den — should just create an app to give advice to entrepreneurs

How do I find an app?

  • SD: usual channels — community, press, word of mouth
    • that process has just started
  • SW: most people now just expect an app for something
    • adverts focussing on 13-25 year old audience just don’t have mobile presence

What aspects make you prick your ears of app ideas?

  • Liz Myers thinks 3 main needs of the user: microtasking, bored, local (from Tapworthy)

Correlation between marketing spend and success?

  • CC: over a long haul it’s the user experience

Mobile cannibalising a lot of other channels — where is it going?

  • SW: big shake up coming in the next year to 18 months
    • “it’s all going to the cloud”
    • should start taking points from 3-5 years ago from web to our advantage
  • SD: lots of things happening with mobile experience happening in parallel (e.g. lots of people watching a TV programme and doing something on their mobile at the same time)
    • Indonesia — more mobiles than TVs
    • Google, Facebook have the users and will pay for content
    • TV programming for mobile
  • TH: the ad-contrarian debunking idea that people have stopped watching TV
    • mobile will be the primary way of going online

Best and worst bits of the report?

  • TH: surprised at commercial performance of JavaME
    • better than Symbian and Android
    • very low value on pre-loading applications
    • would have expected to have seen many more pre-installed apps
  • SD: Qt — although Nokia sinking, it will have such a huge oil-tanker like effect…
    • Windows Phone 7 “interesting” but not being used
    • Very difficult to hire Android developers at the moment
  • EC: surprised how many developer were working on multiple platforms
    • if Android in such demand would expect to see people focussing on it
  • SW: Microsoft grew by 93% but still only 3%…

Is enthusiasm for Windows Phone 7 just for another platform to port to?

  • EC: actually talking about B2B opportunities
  • CC: heard similar
  • TH: Windows Phone 7 will be hard to do in HTML5
    • Nokia know a thing or two about getting hardware out there

Papaya mobile: JavaME money being made by people who did fragmentation solutions

HTML5 vs apps again…

  • CC: Google have done Lego Star Wars in HTML5 — it’s powerful enough!
  • SW: As a user, I don’t care where it comes from
  • SD: remove the URL bar and you’re on your way
    • excited by Android on MTK devices
    • common denominator will be Android
    • will therefore be HTML5 compatible

Concluding remarks

  • SD: do not drop your iPhone in a lock near St Ives!
  • SW: 90% Apple devices use apps vs much lower Symbian
    • cf market coverage: 3.9% Apple; 15% Symbian
  • TH: discovery is not a new problem
    • in 1st century AD, Seneca complained that “the abundance of books is a distraction”…
  • EC: when my mum, on her own, tells my dad which app to download, then we’ve hit the mass market!


  • Next momolo probably in September
  • Over The Air 2011: 30th September & 1st October at Bletchley Park
    • looking for sessions, speakers, sponsors

Monday 20 June 2011

MomoLondon: Web vs Apps

I couldn’t make tonight’s Mobile Monday on location, so I thought I’d post my delayed notes from last time’s debate on Web vs Apps.

It was a lively session with both sides arguing strongly, though (unfortunately?) sometimes for the other side! The team members started by taking turns in giving short presentations — notably all of team web had slides (including beautiful ones from Bryan as usual) whereas all of team apps had decided just to talk.

Team web ended up with the audience vote (just!), but personally I thought team apps had the better argument. Yes, there are billions more mobile devices out there that can access web sites rather than have apps, but as we’ve seen (and as even Tomi Ahonen has been repeatedly caught out by) slick user experience drives mobile devices more than anything else. Web sites are great for finding stuff — but people don’t keep coming back to the same web site like they do to a favourite, well-designed app. And the skew in stats that we’ve seen since the iPhone came out (iPhones and similar devices punch way above their weight in usage compared to number of devices) applies even more for apps vs web sites. In his 5 minute presentation, Mauricio put up some Flirtomatic stats saying that they made about three times as much revenue from mobile web as from apps, but then revealed that their iPhone app provided 11% of revenue from 0.8% of sessions!

Anyway, enough ranting… Here’s my usual semi-structured notes:


Chaired by Leila Makki

Team Apps

Team Web

5 min presentations

Each team member made their own presentation, but my notes have all the points mixed together. Viji Pathy has posted a pretty comprehensive report of the session on the Mobile Monday blog that gives a bit more detail on the presentations side.

  • Discoverability
    • App store pre-installed
    • Browse, search, one-click install
    • Web is about information — apps are about utility
  • Building a mobile web app is not just about knowing HTML and CSS with a bit of Javascript
    • Easy to get very bad results on mobile
  • Numbers: 77% of 6.8 billion people have access to a mobile device (5.3 billion)
    • only 100 million iPhones (only 2.015%)
    • for 1/3 of population internet access is only via mobile
    • the other devices are mostly “feature phones”
    • but this is not an argument for web vs native… since many of the feature phones either have limited mobile web, or else support native apps!
  • Linkability — if you don’t have the app installed, sending someone direct content doesn’t work so well
    • this is Tim Berners-Lee’s fear, but apps can integrate with a web-based backend (e.g. instagram) and app stores themselves can be web-enabled
  • Non-technical people actually don’t understand what a website is…
    • Big successful web sites are understandable on a human level: eBay/Amazon are shops; Facebook is the pub
    • Similarly, apps are a more human thing — you get a nice shiny icon
    • The blank browser scares many people
  • AW: When you get the iPad, it’s totally useless until you put apps on it
  • From content perspective: Google prioritises quantity of content, whereas apps can highlight small limited quality
    • For example, instagram has many less features than flickr but has grown to 5 million users very rapidly
  • Flirtomatic — iPhone native has 11% revenue from 0.8% sessions…
    • and Mauricio is on Team Web…?
  • At Tesco, have seen that mobile web used for research but not for re-use and habitual long-term usage
    • app use encouraged by push notifications and widgets
  • 1 in 4 mobile searches in the US are on Google Voice search
  • Mobile web seems to be doing well for mail order & delivery shopping sites — searchable content with larger payments
  • Tesco made money back from iPhone app in less than a week
  • Targeting mobile devices: build it and see who comes, then target appropriately

Summing up — pro apps

  • Tangibility
  • Ownership & engagement
  • Native apps are faster
  • Using hardware
  • Lots of web browsers available, but are they ever going to be your customers?

Summing up — pro web

  • Don’t just target the rich west — reach beyond
  • Discoverability for apps can be one of the biggest problems

Q & A

  • What about using web apps on a long flight?
    • Not really
    • but this is possible now
  • Hard stuff: two-way voice with echo cancellation etc?
    • Not in a web app
  • Fragmentation of web browsers?
    • Design your site appropriately: it depends on who you want to target, but it’s still a larger number than just iPhone apps
    • e.g. target a touch-enabled mobile site and get both iPhone and Android at once
  • Mobile social
    • Good example of having both a mobile web and native strategy
    • e.g. Facebook native users add photos more; web users add quick status updates
  • Mobile ads — is there a problem keeping competition away from apps?
    • Tesco doesn’t have external ads in their apps
    • The end-user wants the curated experience…
  • Testing across multiple devices?
    • AW: It’s a problem for mobile computers — they don’t work some of the time…
    • AW: Apps are a reliable experience
    • The mobile web is no better and sometimes harder
  • Apps are good for some things and webapps are good for others… It’s like asking a carpenter which is the better tool: a hammer or a saw?
  • Monetisation?
    • Not for web games… yet
    • Flirtomatic has in-app purchases of virtual currency, but it’s a whole range of transaction
  • How do costs compare for native vs web?
    • It depends… You can spend more or less on each
    • Tesco: cost seems quite similar — especially since mobile dev has to be optimised for various devices
  • App-store owners take a cut; will it be the same for web?
    • probably — billing partners will always take a cut…
  • Will it be a digital divide between those who have apps and those that don’t?
    • Some people just don’t want apps on their phone — e.g. mother has a binatone phone with big buttons and doesn’t even use a mouse
    • There’s just a time lag to the rest of the world
  • What about lock-ins?
    • By choosing HTML, your development environment is free from manufacturer tie-ins
    • However, by choosing HTML, you play into the hands of Google making things free, operator content filtering etc.
  • Mobile web currently over-promises and under-delivers, but we’re all hedging our bets as mobile web catches up…?
    • Panel: yes!
    • BR: mobile web is catching up very fast, and depending on your business may already be a better bet
  • How do you find where your customers are?
    • Analyse the web browsers of your mailshot emails


Tuesday 10 May 2011

Google I/O 2011

Some brief notes on the Google I/O 2011 keynote this afternoon… It started kind of dull with Android stats that were pretty good but still seemed to be catching up on Apple, then gradually got better and better.

Google really does want Android to be “one OS everywhere” (I guess running “one web” webapps…) and the UI is improving. I look forward to the media content coming across to countries other than the USA, though the lack of any mention of music or movie labels leaves me in some doubt as to when this will happen. The presentations neatly glossed over the time involved in syncing music and movies between devices and the online service — even on a home wired network the data would take a long time to upload. And there was no mention of syncing between devices on the same LAN like Dropbox either.

The big news for me, however, was the accessories and android@home. By making it so cheap to add hardware integration with Android devices, there could be a real explosion of new products and the home automation market could finally break out of eye-wateringly expensive or home hacker territory. I’m really looking forward to more detail on android@home, but there’s nothing released yet…

android updates

  • widgets can now be stretched
    • scrollable -> resizeable (just change XML)
  • android can now be a USB host
    • keyboards, mice, game controllers
  • google tv market open for devs this summer
    • will be based on android 3.1
  • icecreamsandwich coming Q4
    • advanced UI
    • APIs to help scale UI
    • action bar able to reconfigure itself for available space


  • movies and books now available through android market
    • can watch on web or on android device (e.g. android TV…)
    • seems to be US only (like Music)
  • google music
    • cache music recently played
    • can “pin” music just like on movies to make available offline
    • downloads in background
    • 20,000 songs can be added to library
    • free in beta…
    • new music app works with android 2.2 and above


  • new devices will receive latest updates for 18 months after first launch
    • (if the hardware allows)
    • guaranteed to come through reasonably quickly
  • android open accessory
    • plug in an accessory
    • phone gets taken to app (or to android market to download it)
    • supports USB now and bluetooth in future
    • hardware design toolkit based on Arduino
  • android @ home
    • android @ home framework
    • new low cost connectivity protocol for non-wifi devices
    • why not existing??
    • partnering with several industry players
    • LED lights & switches
    • tungsten demo with NFC chips in CDs cannot work unless Google get record label deals…

new devices

  • Samsung 10.1 tab: 720p, 565g, 10.1”
    • lighter than iPad 2, at least as powerful…
    • just waiting for better interface