Mobile@Scale 2016

Last month Facebook invited mobile developers into their London offices for a collaborative discussion on scaling mobile development.

The focus was mainly on native development — and the attendees were mostly iOS and Android developers — but the scope expanded to include scaling development processes as well as how to scale apps for lots of users.

Jim Purbrick @JimPurbrick, Engineering Manager in Facebook London’s office, introduced the talks by saying that on mobile, the bug stakes are higher — once a bug is released, the app is on people’s phones and is much harder to fix. You can’t just update the code and see people get the fix in the next page refresh.

And for all the focus on ending up with a native app in the platform-specific app store, two of the big themes were sharing code across platforms and being able to make quick changes to apps that were already deployed.

I was impressed by the inclusivity of the conference — not only were the speakers from a variety of companies (not just Facebook or Facebook partners) but the audience were encouraged and given time to ask questions and discuss with the speakers.

The talks and discussions were all videoed and I’ve linked to them below together with my notes highlighting the points that made an impression on me.

Scaling iOS @ Google

Michele Aiello @micheleaiello, Tech Lead Manager on the Calendar app, Google

Michele gave a really detailed talk about how the iOS teams at Google deal with handling large amounts of code shared amongst many geographically spread developers. There’s lots of useful nuggets in here — and it’s interesting to see where Google have invested time and effort in order to make cross-platform and large team development easier.

Scaling iOS @ Google - Michele Aiello

Posted by At Scale on Monday, 28 March 2016

• Google has more than 60 apps in the Apple App Store!
• iOS devs have moved from London to every office worldwide
• strategy on how to share code really important
• design & ease of use crucial for scaling apps
• yearly gathering of all mobile developers
  • often start shared efforts there
• regular tech talks in local offices + recorded & streamed around the world
• have feature specific “Tiger teams”
  • one goal: ship a feature
  • cross functional: Android, iOS, web, PM, UX, API, etc
• have trouble with merging & reviewing xib, project & storyboard files
  • so Chrome team developed GYP: JSON for structure & dependencies
  • GYP: “generate your project”
  • use storyboard & xibs for prototyping, then shared code for elements
• release management:
  • regular releases every 2-6 weeks
  • with feature flags to toggle new features
  • compile time flag during initial dev, then runtime flags for later
  • known as the release train
  • heavier-weight trains need synchronising with marketing etc — ok to be a little late
  • 75%-80% of users are using auto-update so automatically get updates
• testing:
  • XCTests for functional and performance
  • KIF & Earl Grey for UI tests
• sharing code
  • single repo
  • HEAD is always stable
  • all code is available and shared
  • making a change in shared code: see the test results and roll back if issues
• for any shared code
  • enforce documentation & example code
  • catalog app for UI elements
• for cross platform sharing
  • try to share model cross platform and to server too
  • makes offline easier
  • have tried webviews & javascript
  • now using C++ & J2ObjC
    • C++ easy on iOS, complicated on Android
    • used in Chrome
    • j2ObjC used for Inbox
  • j2ObjC even lets you debug into transpiled Java code in Xcode
    • breakpoints, stepping, variable values all work
  • if code is simple, look at sharing the tests rather than the code
• swift at Google: currently playing with it
  • have found that development is faster
  • probably waiting a few months to bring into production apps
• user testing using beta releases (testflight, android beta)
  • metrics in the app
  • surveys after testing
• have tools to search whole repo to find out if code is still used
• sharing layout
  • done using sharing layout logic

When mobile IDEs need to scale

Al Sutton @AlSutton, Facebook

Al talked about how Facebook builds Android apps, and how they feed back improvements to their build process into the open source community (e.g. IntelliJ community edition and the Buck build tool). By using Buck, they allow their developers to choose whatever IDE they want.

When mobile IDEs need to scale - James Pearce and Al Sutton

Posted by At Scale on Monday, 28 March 2016

Nuclide

James Pearce @JamesPearce, Head of Open Source at Facebook

James continued from Al’s Android introduction to talk about Facebook’s new Nuclide IDE for building iOS apps… It’s exciting to see some competition in the iOS IDE world — whilst Xcode is great at some things, it often leaves a lot to be desired. JetBrains’ AppCode is a useful challenger but to have an extensible open-source IDE for iOS could be a game changer. The only downside for me is that Nuclide relies on Buck, so you have to change your project to buy in to the Facebook toolchain. Perhaps if someone could create a Fastlane plug-in…?

• unlike IntelliJ, Xcode is not open source, so can’t contribute
• existential issue for Facebook…
• started extending Atom from github
• aded Flow, Babel, Clang & Buck
• created Nuclide
• also added Chromium dev tools to help debug into app
  • lets you debug into Javascript, Objective C, etc all in same place
  • transpiling keeps source maps to help with line numbers
  • also lets you inspect into UI hierarchy for ReactNative apps
  • includes highlighting
• now have 2/3rds of committing engineers using Nuclide
• have analytics built-in
  • tracking feature usage
• internal infrastructure team has become a product team
• now available at http://nuclide.io
  • analytics kept for internal
• other open source projects
  • pop: iOS animation library
• doesn’t have refactoring yet

6 lessons learned scaling mobile at SoundCloud

Next up were a couple of sessions from smaller companies (though still not small!) showing how they built and adapted their apps faster to keep up with demand. SoundCloud spoke about using ReactNative (more on that later) and how they structured their dev teams to include mobile developers.

Jamie McDonald (Android) @jdamcd & Matej Balatic (iOS) @skavt, SoundCloud

6 lessons learned scaling mobile at SoundCloud - Jamie McDonal…

Posted by At Scale on Monday, 28 March 2016

• building out new SoundCloud Pulse app for people creating sounds
• most engineers busy on main SoundCloud listener app
• got a partner for Android, but built iOS app with ReactNative using web developers
• shared design & feature set across platforms saves a lot of time
  • were previously designing features twice
  • marketing was more complex too
• mobile specific API
  • mobile-specific features: background sync, batch fetches
  • “back-end for front-end” idea from ThoughtWorks
• developed C-based mobile playback library (skippy)
  • initially for Android, now rolled out across iOS too
  • e.g. optimise streaming for emerging markets
• tried to spread mobile devs through feature teams
  • but spread too thinly
  • weren’t able to pair and share knowledge
• instead created clusters of feature teams
  • mobile engineers shared amongst each cluster
  • could be in enough numbers together
• release train model
  • each feature team can take responsibility for shipping
  • allowed action but also feedback and responsibility
  • use feature flags — team responsible for turning on when ready
• tools used:
  • iOS:
    • FlipTheSwitch
    • stable CoreData stack — specific use of framework
  • Android, use LightCycle (soon to be open-sourced)
    • forward life cycle events to small independent modules
    • receives callbacks but doesn’t need to know which activity its attached to
    • enables better unit tests as can separate things out more effectively

Backend-driven native UIs

John Sundell @johnsundell, iOS Developer, Spotify

Spotify have an almost completely content-based app and are constantly tweaking to change the presentation and priority of different music. John and his team came up with a way of handling that change by controlling the whole app UI from the backend API.

Backend-driven native UIs - John Sundell and Diego Cristina Ca…

Posted by At Scale on Monday, 28 March 2016

• define components in backend API
• generalised data binding
• generalised components
  • implement standardised components which can be picked up from API
• can put cacheing, and lots of standard stuff in the generalised app
• control the UI from the backend
  • API contains view models rather than raw models
• Ed.: makes sense if you have an app with lots of similar components
  • especially for a content-based app
  • similar to Google’s code-based component library
• were able to delete 20,000 lines of code on home page browse view
• overall have been able to delete 100K lines of code across iOS & Android
• use layout traits to control layout
  • e.g. full width, separator, stackable
• request sends a lot of data about the device to the backend
  • can return different components & layout depending on device or screen size etc
  • sometimes send extra data in response so can handle quick changes e.g. screen rotation
• support infinite scroll using metadata with URIs for follow-up pages
• can set up fallback components — if this not available, fallback to previous
  • enables playing around with new features & UI but still supporting older builds

Infer: Moving fast with static analysis

Dulma Churchill, Software Engineer, Facebook

Taking up Jim Purbrick’s challenge of dealing with the higher stakes of bugs in mobile, Dulma gave us an introduction to Infer — Facebook’s static analyzer that can check for memory and resource leaks and null pointer issues each time you compile.

Infer: Moving fast with static analysis - Dulma Churchill

Posted by At Scale on Monday, 28 March 2016

• static analyzer that doesn’t require pre/post conditions
• compositional, so doesn’t need to process whole project at once
• very intertwined with compiler
• infer can find inter-procedural bugs not local to single file
• used with CI can be set up to only process newly compiled files
• within facebook: fix rate around 70% in recent months
  • high rate due to getting results on continuous integration
• there’s an Xcode plugin
• integrated with codeboard
  • web-based IDE to teach programming in classroom
  • Java, Python Haskell…
• see their blog post about being used at Spotify

3000 images per second

Henna Kermani @tokyotwilight, Software Developer, Twitter

Some interesting stats from Twitter here, in Henna’s story of how Twitter scaled up their image and video handling.

3000 images per second - Henna Kermani

Posted by At Scale on Monday, 28 March 2016

• image uploading used to be all in the same API call as the tweet itself
  • any point of failure would fail whole thing
  • waste of bandwidth for client & server
• split out image upload from tweet content
  • also allowed segmented, resumable uploads
  • used multi-part POST requests with separate INIT, APPEND & FINALIZE API calls
  • massive drop in upload failures, especially in developing world
• did research on age of images:
  • 15 days 50th percentile
  • 150 days 90th percentile
• so kept original + 20 days of variants
  • balance between storage increase per day and computation on each request
  • saved $6m in 2015 just from this change!
• image formats
  • tried using WebP for 6 months last year in Android app
    • ~25% smaller than PNG or JPG — better engagement
    • but not supported on Android <4 or iOS…
  • converging on progressive JPEG instead
  • used Facebook’s Fresco library in Android app

React Native

Pieter De Baets @javache, Facebook

Pieter gave a detailed intro to React Native — building native apps for iOS and Android using just JavaScript and HTML-like markup.

React Native: bringing the best of web development to native -…

Posted by At Scale on Monday, 28 March 2016

• if you ship a bug in a mobile app, there will always be a user out there running that bug — no matter how many updates you apply…
• write UI declaratively, code in Javascript
• share lots of code between iOS and Android
• Apple’s guidelines don’t allow you to update code in a running app
  • but there’s an exception that lets you update JavaScript over the air
  • so you can update React Native apps instantly

Don’t forget the web

Jeremy Keith @adactio, Founder, Clearleft

After all that talk of native development, Jeremy brought us back to thinking about the web and how it will always be the largest, widest target. It isn’t a “platform” and it will never be the leading edge of mobile, but it is for everybody.

Don’t forget the web - Jeremy Keith

Posted by At Scale on Monday, 28 March 2016

• when building for the web
  • start with core functionality
  • implement with simplest techology
  • enhance!
• can be done for whole service but also for individual components
• Ed. is this that much different from native?
  • especially for different OS levels, Android features etc
• there’s always something new that’s not fully supported

Handheld Conference 2012

This is a new conference, organised by Craig Lockwood around lots of intersecting areas of mobile design and development.

This year it was held in the beautiful St David’s Hotel, overlooking Cardiff Bay. The conference centre was a bit cramped, but the hotel itself was lovely.

There was a single track of sessions, but they covered a wide range of areas from getting a business started to futurology via several variations of design. As with many mobile events there was a fair mention of the web vs native debate, but there was a reasonable balance between the two here — with the only loser being the whole app hybrids like PhoneGap (which took a large amount of flak).

As with most of my posts, here’s my quick notes, typed during the sessions so that you can get a rough overview of what happened. Craig has published videos of several of the sessions on Besquare (I'll link to them next to my notes).

Handheld 2012: Book stories — How to turn a sideline into a business

Keir Whitaker, Viewport Industries

http://keirwhitaker.com

• co-owner of Viewport Industries with Elliot Jay Stocks
• using the web to do side-projects / passion projects
• published Insites book — interviews with web developers & founders
  • also available as ebook (via http://woop.ie)
• wanted to create something that makes money while they slept
• there’s still a passion for physical media (especially amongst designers…)
• had 65 people involved in making book
  • 21 interviewees, but a lot of others
  • copy editors, etc
• picking a new collaborator is hard
• did a precursor project (insites tour) to find out if they could work together
• discuss the money up front
  • horrible conversation to have
  • but really important to sort out before starting
• raising money
  • bootstrapping (your own money)
  • kickstarter (watch out for scaling issues)
  • funding
  • sponsorship / partnership
  • chose partnership (published in association with Mailchimp)
• need banking for a business account
  • they need address, phone number, etc
  • chose HSBC for Xero integration
• company needs a physical address
  • don’t use your home address
  • can use an accountant’s address
• need a telephone number
  • again, don’t use a personal number (especially mobile)
  • used a company called dial9 to have a virtual Bath number
• need terms & conditions
  • banks pay people to read them when you apply for stuff
  • most people borrow other people’s terms…
  • ask first!
• get an accountant
  • will save you money
  • HSBC business account feeds directly into Xero online accounting system
  • accountant can then work directly from Xero
  • costs about £19/month
• need a storefront for the website
  • shopify costs £19/month
• payment gateway
  • middle man between storefront and merchant account
  • need it if you don’t go for paypal
  • alternatives:
    • braintree
    • paymill
    • stripe (US only)
    • gocardless (going Europe-wide, direct debit only)
• merchant accounts
  • money comes through into real business account after about 2 weeks
• ensure that the gateway supports issuing refunds
• digital goods
  • use fetch app
  • works by web hooks
  • benefit with fetch app is that you can resend orders (sometimes they don’t go through)
• need to do support…
  • try to take dissatisfied customers off twitter and into email
  • think about what you can offer unhappy customers (e.g. digital goods in lieu)
  • helpscout.net can suck in email
  • can outsource support
• costs:
  • accountant: £70
  • xero: £19
  • telephone: £10
  • shopify: £19
  • payment gateway: £19
  • merchant account: £25
  • fetch app: £6
  • support: £100
  • based on 4 hours of accounting & support / month
• projects will always take longer than you think
  • impacts the finances

Start small, think big

Lee Armstrong, @lesmond, lee@pinkfroot.com

Video available on besquare.me

• shipfinder - first app
• planefinder - most successful
• inspired by Google, facebook, twitter
  • started thinking big from the start
• planefinder started with coverage of the south of the UK
  • sold app across world and started getting a few emails back saying “don’t you know Poland exists?”
  • started planning for bigger
• now cover most of world apart from China & Africa
  • have 400-500 radio receivers across the world and splice that data with other databases
  • all receivers are land-based: ships have range of about 50 miles
• when initial small hosting plan started creaking had to decide to self-host or cloud?
  • ran a comparison recently, found that it would cost $2000/mth more using AWS than using at the moment
  • but have internal skills to do server management
• currently have 32 servers but are flexible
• need to be able to scale up (and down)
  • pinkfroot turn machines off when scaling down
  • doesn’t save capex of rack space, but saves power
• user reviews…
  • bonkers reviews — ignore them
  • but pay attention to common themes
  • take time to spend time on customer support
  • takes around 30 minutes to turn around an angry customer
• built in social sharing into app
  • pick a flight and share it - shares web link + image
• built up community of app users
  • really valuable when lost photos of individual planes
  • managed to get users build up their own photos in the app (credited to users)
• product releases - little and often really helps
  • big release with loads of new features will miss out most features in reviews
  • what’s new notes in store are the one chance to communicate with users
  • make it chatty, make it friendly
• building up a good brand
  • working with Eddie Stobart to make an Eddie spotter app
• have apps for iOS, Android, Windows Phone
  • spend a lot of time writing native apps
  • make savings on back-end — they all talk JSON
  • Android is 10% of iOS sales
  • Windows Mobile is 1% of iOS sales
  • doing it for brand exercise
  • going through improving other platform apps

So you have an app idea?

Dave Addey, Agant, @daveaddey

Video available on besquare.me

• 2008 Dave was an web developer in a spare bedroom office
• now runs a company with 7 employees
• a good idea for an app
  • is it a good idea?
  • is it a good idea for an app?
  • how do you go about making it?
• example: late night bars in London
  • cost low four figures to make
  • 3 months of preparation time for database
  • sold 2000 copies @ £3.99 (or £2.40 after Apple & VAT) — didn’t even break even…

is it a good idea?

• measuring good app market:
  • universal - niche
  • international - local
  • lasting - ephemeral
• UK Train Times launched in 2009 when the app store was smaller
  • local - UK not worldwide
  • lasting
  • fairly universal
• Malcolm Tucker app
  • when you open the app there’s one new voicemail waiting for you
  • when you listen to the voicemail it starts a 4 day process with incoming emails & voicemails as Malcolm Tucker tries to find his phone
  • timely
  • fairly niche
  • fairly local
  • so covered costs but not much more
  • but led to a lot of other interesting projects
• does the app have a long tail?
  • lasting appeal
• does it scratch your own itch?
• should have some kind of hook
  • something that’s not been done before
  • something to show off to user’s friends

… for an app?

• when potential clients say “I want an app”, it’s not always true — Dave talks 50% of clients out of
• dead time (5-10 mins)
  • e.g. supermarket line
  • used for QI app
  • book-style interface had larger books with longer content
• we know where you live
  • trip advisor offline city guides
  • nosey parker
  • rightmove app
  • e.g. next train home in UK Train Times
    • one button to home station from around here
• the app that’s always there
  • guitar toolkit
  • imdb: “what was she in?”
  • british red cross first aid app — everyone should download this now!
• ongoing (everyday) use
  • opposite of throwaway app
  • people rely on them
  • UK Train Times
    • get more sales through word of mouth than any other means
    • can still charge £4.99
    • has sold 300,000 copies throughout the UK
    • but losing National Rail icon caused a massive drop in sales
  • twitter clients
  • TuneIn Radio
  • clipboard management apps

how to go about making it?

• lots of platforms to cover
• one approach is PhoneGap, hybrid app builder
• but problem: e.g. featured app Wikipedia
  • doesn’t work in the same way as native apps
  • form controls are different
  • search is not the same for either platform
• @daveaddey’s maxim: “develop once for every device: you get a rubbish app for every device”
• have seen big brands develop PhoneGap apps and then pull them after a month
• if you spend ages fine-tuning your HTML to behave like a native app, then you might as well spend that time writing native
• … but the rule is different for games
  • you can build using cross-platform games engines, e.g. Unity, Marmalade
  • the interface is not specific to the device but specific to the game
• it’s all about the implementation
  • sharing profits based on an initial idea doesn’t make sense…
  • it’s all the little ideas throughout development
• Derek Sivers - cdbaby
  • ideas are worth nothing unless executed
  • they are multipliers
  • http://j.mp/ideaMultiplier
• Sergey Brin: “coming up with an idea is the least important part of creating something great… the execution and the delivery are what’s key” (via The Guardian)
• PhoneGap can be useful for a quick prototype to guage response
• apps can and should make use of HTML5 where appropriate
  • e.g. Malcolm Tucker emails, credits pages
  • QI app content — but displayed using CoreText not a web view
• hybrid approach
  • suggest creating a native app for one platform
  • a mobile web app for the rest
  • choice of one native platform is up to target market
  • use experience of first native to decide next native platform
• don’t muck with user expectations
  • native apps are expected to have native performance & behaviour
  • web sites have different expectations
  • but don’t try and make your mobile web site appear like a native app!
• pricing:
  • getting high value apps going
  • e.g. launching £10 app at £5.99
  • 69p for a UK only app is not going to break even
  • Agant don’t do 69p apps…
• bandwidth, speed, etc
  • saw more of a change between capped & unlimited than for improvements in speed
• biggest failing in App Store is lack of paid upgrades
  • adding new functionality is about finding additional users by re-promotion
  • Agant avoiding freemium because eeurgh :-)
  • but freemium seems to be a side effect of the lack of a paid upgrade option

10 top tips

1. project the risk of everything you do: best and worse case predictions
   • app should have a business plan
2. keep project budget realistic
   • don’t be tempted to spend a fortune
3. it’s important that all partners have a vested financial involvement
   • don’t take on apps for a content provider where they have no risk
4. talk about your idea - it will lead to better ideas
5. value Apple promotions
   • Malcolm Tucker was not promoted due to sweary language
   • QI app did get promoted - massive difference
6. best way to get Apple promotion is to make Apple devices look good
7. create a video that tells people what your app does
   • gives an equivalent to your app that people can share
8. keep updating your app - and give Apple reasons to promote it in each case
   • if you add big content, Apple will treat it as a new app
9. keep it simple and focussed
10. sweat the details
    • “the best way to market your app, is just to build a great app”

Content & tone

Robert Mills, Studio Manager at Bluegg, @RobertMills

Video available on besquare.me

• creating, managing & using content
• need an individual responsible for content
• content first otherwise design won’t fit…
  • see @rellyab, @halvorson
• used slickplan to plan site
  • signed off site map first
  • then got client to provide all content
  • client had to really think about what she was saying
  • she had to think about the whole site up front
• having all content ready means that organising translations is easier
• using content
  • what are you saying and who to?
• managing content
  • can use Google Docs, Dropbox, etc
  • or GatherContent
• doesn’t end after launch
  • need to review & refine
  • audit & strategy
  • ensure consistent & authentic
• auditing content for mobile
  • prioritise content over navigation
  • can prioritise content using traffic lights
  • need to check end use: ask why content is important

Working with Muppets

Ollie Wells, Sequence, @olliewells

• Sequence focus mainly on mobile web sites
• research — use analytics
• stakeholders (esp HIPPOs) can cause problems
  • Blackberry v5 is a pain in the butt
  • can use analytics to persuade them that their use case is not common
• useful functional spec wording (plain English, without version numbers):
  • The website will be built to perform at its best in the most common of modern browsers
  • Bugs that stop the side being usable will be fixed in the latest versions of the above browsers, as well as in 1 older version
  • Any bugs that we find in browsers more than 1 older version of the most common browsers will be looked at on an individual basis. This includes bugs that affect functionality as well as design.
• don’t oversimplify the mobile web site
  • ensure the functionality is still there
  • don’t remove functionality just cos your on mobile
• doing information architecture using sketches on paper
  • good example {picture}
• do prototypes on device
  • click from screen to screen
• frameworks
  • jquery mobile useful for quick prototypes
  • for prototypes, use sass, haml, coffescript and middleman
  • for production, use Mixture, gridset, twitter bootstrap
• Muppets web site for movie
  • all about characters
  • desktop is animation based
  • mobile is much simplified - same content, but static images
  • tablet is same layout as desktop but no animation
• device testing…
  • bluegg looking to open a device lab
  • choose your devices carefully - you can’t support everything
• do double res images for iconography, but not for photography
  • most users wouldn’t see the difference for photos
  • also CSS3 web fonts are useful for iconography

Taking content abroad

Rob Lo Bue, applingua, @roblobue

Video available on besquare.me

• imagine that you’re a french speaking user and you download an app, but it’s in english
  • bad initial impression…
• get your English right
  • get someone else to read it and answer questions
  • check it’s easy to comprehend
• avoid idioms - they don’t translate
• make your units use worldwide standards
  • e.g. include dollars as well as sterling, km as well as miles
  • always include timezone for event times!
• use a clear font for writing
• icons save translation costs!
• support international sharing
  • e.g. qzone (QQ), badoo
• if you have the budget and time, then look at translations
  • get users to translate!
  • but get another user to check
  • can use Google Translate for checking translation (don’t use Google Translate for actual translation!)
• choose languages carefully
  • e.g. most iPhone users in India are English speakers and use their iPhone in English… less ROI on a Hindi translation
• international compatibility

What’s holding the mobile web back, and what are Facebook doing about it?

Simon Cross, @sicross, si@fb.com

Video available on besquare.me

• worked at facebook for about 2.5 years now - makes him one of the old-timers
• digging in to Zuck’s quote from techcrunch disrupt in Sept 2012
  • faceweb v4 built from 2010: webview with extensions
  • at that time, facebook was a web company
  • update at will, one m-web codebase
• reach a point where people hated it because:
  • it was slow — slow*er* than their other apps
  • it pretended to be a native app
• took 6 months to fix it
  • because had to retool the whole company
  • had to slow down the release cycle, which felt wrong
  • had to get used to submitting binaries to Apple & Google
• v5 app (more native UI) went from 1.5 stars to 4 stars in 3 weeks
• …and Zuck’s quote continues to say that there are more people using facebook on mobile web than there are on Android and iOS combined
  • 7000 device types accessing every day
  • mobile users growing twice as fast as desktop
  • 126m mobile-only users
• so how to help developers grow mobile web apps?

distribution

• asked developers at PhoneGapDayEU why they were using PhoneGap: response — to be in the App Store (80%)
• in the app store to get distribution, but also because boss said so…
• mobile usage is different from desktop
  • general browsing is less used
  • instead people solve a problem, or fill some time
• facebook integration is no longer click to share
  • now it’s about publishing structured data
  • where, when, who
• e.g. soundcloud defined 5 actions
  • if you do any of these actions on any of their apps, it publishes that to facebook (if opted in)
  • then comes back as news feed either in app or in facebook app
  • news feed in facebook launches app directly — or else takes you directly to the app store to install it
• e.g. SongPop grew 9.7m users mainly through facebook sharing
• last 30 days, facebook sent users to native app stores 180m times
• also facebook has App Center for mobile web app
  • 170m monthly users
  • social recommendations
• last 30 days facebook sent users to mobile websites ~7m times

performance

• no visual difference from v4 to v5 except speed
  • but got 2x engagement
• Moore’s law still applies to mobile
  • at least to newly released devices
  • due to upgrades & contracts, the actual speed of increase is slightly slower…
• facebook is a founding partner of the W3C coremob community group
  • one of the first priorities is fixing appcache
• also developed ringmark: http://rng.io
  • Ring 0: what we have now
  • Ring 1: what we need to run 8 of the top 10 native Android & iOS apps
  • Ring 2: what we need to build all of the native apps on the mobile web
• 4 months ago, Dolphin Browser Beta for Android succeeded on Ring 1
• browserscope is now tracking ringmark over time

monetisation

• display ads?
  • on mobile? really?
  • they suck - both for size and for intrusion
  • BBC have long narrow columns because they need the right column for ads in the US
• credit cards?
  • too hard
  • cannot compete with native
• carrier billing?
  • can integrate via middlemen (bango, boku, zong)
  • facebook mobile payments layer on top of that
  • Ed: but doesn’t work on Wi-Fi

It started with a browser

Matt Gaunt, Developer Advocate, Google TV, @gauntface

• @AliDriver (Future Platforms designer, now freelance) able to do amazing things with HTML5
• latest devices could do it, but performance always an issue
• now looking at Google TV Spotlight
  • app store for TV optimized web apps
  • apps look really great
  • but developer spent two weeks adding a specific animation…
• just think about screens of different sizes
  • see Jason Grigsby’s article {link here}
• users don’t care if it’s a responsive design or separate mobile & desktop sites
• though probably want to have a catch-all site that will be ok for all situations
  • then add native apps or customized web sites as needed

Is your thinking L-shaped?

Kevin Mears, http://mearso.com, @mearso

• big CRTs meant you needed L-shaped desks - so could fit CRTs into the corner
• but don’t need them anymore for flatscreen monitors
• requirements change, don’t forget to change your tools…
• “Moses said”: my boss says…
  • difficult to argue with someone who isn’t in the room
• politics means that designers & developers can’t just be artists
  • have to sell the work
  • “Design is a Job”
• mobile use case — apply “app thinking” to a web site (Sarah Parmenter, FOWA)
  • what is the single reason for someone using my app?
  • and who are they?
• universities do have lots of different use cases
  • e.g. glamorgan
  • 100 users concurrent active users
  • 100 sub-sites
  • 100+ editors
• teaching people that need to delete stuff that is no longer relevant
  • Ed: but then it’s important to archive stuff on the web too
• basing templates off twitter bootstrap
  • frameworks tend to make you fit the content to the framework

UI for developers

Amber Weinberg, @amberweinberg

Video available on besquare.me

• specialises in mobile web apps
• did audible mobile web site
• pretty much 99% of design briefs Amber is given only include full-size desktop web site
• forget about mockups
  • just make it responsive
• breakpoints are when your site breaks
  • fix all the breakpoints at different sizes
• don’t fake it - you’re not a native app, so don’t pretend to be one
• put content where people can reach it
  • Apple have guidelines showing how people hold iOS devices
• show what’s important
  • e.g. boston globe
  • navigation gets simpler
• use columns
  • can move to less columns before switching to single column
  • compare scroll time with content size
• give extra spacing
  • make sure the text doesn’t hit the edge of the screen
• menus are crucial
  • if there are buttons in the header you may want to keep the menu drop-down and a separate action
  • can also have menus at bottom of page and a jump to bottom link at the top
• choose words or icons, but not both
• reduce images
  • responsive images not yet possible
  • try to use less images and more CSS
• retina-smetina
  • most of the time, users won’t even notice…
  • is it worth the bandwidth?
• buttons
  • read apple’s button guidelines
  • make important buttons bigger, 100% width
  • encourages people to press them!
• hover effects
  • make it clear that hoverable items are interactive
• don’t assume you know what your users are doing
  • but make it easy
• make font sizes appropriate
  • not too big
• don’t disable zooming
  • it’s an accessibility thing
• use sliders - with gestures
  • http://www.woothemes.com/flexslider/
• don’t forget your bookmarklet icon

We, Human

Andrew Spooner, Creative Technologist, Microsoft, @andspo

• works in developer platform evangelism team
• get tech about a year or two before it hits the public
• why do we connect things?
• vannevar bush & the memex…
• internet fridge…
• toaster telling me that the robo-vacuum has picked up the dog being sick behind the sofa
• NEST gives feedback on temperature changes: it will be 21°C in 15 minutes
• in 2008, the number of things connected to the internet exceeded the population of Earth
• latest John Deere cotton picker RFID tags each cotton bale
• microsoft project emporia
  • personalised news editor based on articles that you say you like or don’t like
• kinect
  • daughter thinks kinectimals is a film that she stars in
  • shadow puppet control
  • making people invisible (at least on TV)
  • putting a kinect on a quadrocopter
  • trolley that follows someone on a wheelchair
  • face detection and recognition…
• use with caution
  • what are the standard gestures?
  • cancel?
  • don’t turn up the volume control by whirling your arm round and round
• human capacity is not accelerating like our tools…
• minimise complexity, increase consistency
• design style: http://design.windows.com
  • pride in craftmanship — sweat the pixels
  • fast & fluid — motion & animation
    • custom controls need a lot of extra work
    • we have movement in nature, we expect things to move in the same way on digital screens
    • animation with a purpose
  • authentically digital
    • use sensors
    • iconography can represent digital realm
  • do more with less — get rid of UI chrome
    • make the content the interaction
  • win as one
    • small pieces loosely joined
• summary:
  • contextual & social UX is an expectation
  • understand the human - keep it that way

Design Systems

Laura Kalbag, @laurakalbag

Video available on besquare.me

• moving to responsive design
• but still designing at fixed widths
• shouldn’t be thinking in static
• thinking about devices, not content; deliverables, not process
  • thinking about what they give to the client
• design systems
  • typography
  • layout
  • shape & form
  • colours
• what are you going to keep the same across different viewports, and what will change?
• content is always the same
• for design, might want to start with typography
• then move on to base unit
  • based on width/height of ad unit?
  • used for grids, line height
  • makes site feel consistent across changes
• grid can’t stay the same, but try to keep consistency
  • 6 -> 3 -> 1
  • or 4 -> 2
• shape and form includes textures & illustration style
• colour can be kept the same most easily
• design in the browser
  • brilliant idea
  • can’t do it though…
• tools:
  • share design ideas through style tiles
  • styleguides
  • http://pea.rs
• clients want to know what it looks like on different devices
  • they’re snapshots, not mockups
  • if they like the style tiles, then start prototyping in the browser
• don’t base breakpoints on device widths — should be based on content
  • e.g. videos, images, headings
• “if you’re not ashamed of what you did 3-6 months ago, you’re probably not keeping up”
• another app to try is typecast

a happy grain of sand

Aral Balkan, @aral

Video available on besquare.me

• think about how the whole system works together
• an experience is only as strong as its weakest link
• as a designer, try to remain naive
• washing machine:
  • designers think they’re building a machine that washes clothes
  • users actually want a machine that cleans clothes
  • don’t want or need to know the internals of how or why clothes are washed in different ways
• superman effect:
  • makes the technology disappear
  • and the interaction appear like magic
  • Ed: shouldn’t this be the A. C. Clarke effect…?
• interaction design is about dealing with the loss of a human from an interaction
  • replacing the human with a machine is hard
  • but it’s really important
• focus
  • great design is a symptom of a design-led organisation or organisational structure
  • antoine de st. exupéry: “Perfection is attained, not when no more can be added, but when no more can be removed.”
  • design is not democratic
  • you have to make sacrifices
  • in this day & age, great design is the business plan
• design > test > develop > test > design …
  • keep iterating
  • and don’t forget the vision
  • the user testing needs to be filtered through the vision
  • Ed: e.g. Apple does less user testing as they know that asking people doesn’t always give the right answer
• user empathy:
  • indeterminate spinner isn’t enough — need to show empathy when waiting
• web vs native: http://thelink.is/webvsnative

MomoLondon: HTML vs Native

A lively and exciting debate (despite the old material!), well-run by Ewan MacLeod, Editor, Mobile Industry Review @ew4n

Panel

Team HTML5

• Andrew Betts @triblondon
  
  • HTML5 apps for FT
• Simon Arora, Biz Dev Mgr, Keynote DeviceAnywhere @devanywhere
  
  • Initially all about native
  • More and more customers asking for HTML5
  • More platforms with a single codebase
  • No need for appstore or marketplace certification
  • Wider reach to monetise services
• Jose Valles, Head of Bluevia @josevalles49
  
  • Been an HTML5 supporter for a long time
  • Launching FirefoxOS device

Team Native

• Alex Caccia, President, Marmalade @marmaladeapps
  
  • one of the leading cross-platform build platforms
  • take advantage of ARM instruction set…
  • two of top three games in US app store built using marmalade
  • HTML5 just doesn’t provide enough power - need native for performance
  • HTML5 does not solve fragmentation
• Chris Book, Bardowl @bookmeister
  
  • native gives close access to device APIs
  • deal with different network situations
  • HTML5 doesn’t work for audio streaming and caching
• Nick Barnett, CEO, Mippin @docnickb
  
  • make app builders for operators and manufacturers
  • provide both HTML5 and native app builders
  • it’s more about the business model and distribution
    
    • if you want to be in the app store, you have to be native

Last app you paid for?

• AB: Open House London
  
  • because their website is appalling and doesn’t work
• SA: Travel Deluxe
  
  • native london travel
• JV: probably a skateboarding app, or tripit or spotify
• AC: Expense Calculator
• CB: New Star Soccer
  
  • 10 games free, then in-app purchases
• NB: International Rules of Yacht Racing
  
  • native

All native apps. If you want to buy an app, it has to be in an app store…

What about Facebook?

• AC: Hardware platform is moving faster than anything else
  
  • If you come up against an issue, you’re against the browser
  • The only way past is to know the details of the insides of the browser
  • Can’t solve it by logic (terrible for project management!)

FT web app UX

• EM: FT webapp has to go through local cache expanding step before starting
• AB: equivalent to installing an app from the store
  
  • if you say no, it still works; but in a potentially limited way
  • actually a benefit: allows levels of access

Stats from deviceanywhere

• SA: out of 100 customers, top 25 are looking at HTML5
  
  • have a lot of enterprise customers
  • looking to increase their reach
• NB: these customers already have iOS and Android apps?
• SA: yes, looking to extend reach across devices without decent appstores

HSBC Business Banking

• EM: it’s an utterly crap HTML5 experience
  
  • banks say they’d love to do HTML5, but security say no!
• JV: why then do they have online banking?
  
  • want to keep customer experience
• CB: native NatWest app is better than web experience…
  
  • haven’t been able to update their website in 12 years!
  • loads of apps where you use native app first rather than web site
    
    • e.g. Hailo, National Rail Enquiries
• NB: cross-platform HTML5 is a nonsense
  
  • at Mippin, we build web app builders for each platform separately
• AB: that’s just ‘cos you’re not doing it very well!
  
  • FT use same codebase for Android, iPhone, iPad
• NB: but Windows Phone 7 UX is completely different from iOS
  
  • customers expect something different
  • so you need to write your UI differently anyway
  • may as well write it natively each time

How do we resolve vested interests? And designing for format?

• AB: each format and each channel will have differing expectations
  
  • if you define your constraints narrowly enough, natively will always be better
  • if you have a broad strategy and vision, then web technology will win
  • what about TV? what about kiosks?
  • a single web technology solution will adapt to those situations
  • single code base works with touch, keyboard and gestures too!
  • at a recent hackday, FT Labs connected a Kinect and controlled the app without touching the screen
  • the FT webapp works in the way that the people reading the paper are used to — independent of device expectations
• AC: want a fine degree of control over what it looks like and how it behaves
  
  • in gaming environment, you really want to make the app shine
• CB: isn’t this all about the 30% that Apple want to take out of the subscription?
• AB: it’s not (exclusively) about the 30% — it’s more about a direct relationship with the customer
  
  • enables customers to switch devices without losing their subscription
• CB: but Spotify have native apps and still go cross platform whilst keeping relationship with customers
• AB: if Apple changed their rules to say that Spotify would have to give a percentage of their revenue, then Spotify would be stuffed
• NB: if the Daily Mail went the FT route would people get their news elsewhere?

Is it fair to say that HTML5 is destroying usability of mobile platforms?

• JV: no, it’s building something
• CB: Google Maps browser version just not as good as previous native version

Hybrids?

• NB: mippin use unique per platform wrappers
  
  • PhoneGap works well for iOS, not so well for Android
  • BlackBerry has WebWorks
  • hardcore gaming is a pretty specialist use case
• CA: use the right tool for the right job
  
  • SDK supports HTML5 content within an app
  • and then you can switch out and use the native with ease
• Audience: built a PhoneGap app and was appalled by performance
  
  • scrolling 50-100 names was just not good enough

Native provides consistent experience?

• Spotify on some platforms lets you order playlist, Android doesn’t
• if been written on HTML5, then would have worked fine
• AB: people put 70% of budget into iOS
  
  • then 20% into Android
  • then 5% into Windows and Blackberry…
  • not surprising that non-iOS apps are crap

Discovery…

• JV: 700K apps in Apple appstore, so discovery there is hard too
  
  • don’t see a difference
• AB: FT not in a unique position – shared by lots of big brands
  
  • for small companies, app store is probably a good thing
  • FT have specialist native apps in the store which point users in the direction of the web app

Prisoners of the market owners?

• NB: usual retail model: retailer takes 30-40% of revenue
  
  • and benefits can be considerable!
  • if you’re in Brazil in 2 years time with Boot2Gecko devices, then the mindset could be completely different
• Dan Appelquist: isn’t that the issue — app stores are dragging us back into the old model that the open internet is breaking us out of
• CB: yes, the dominance is worrying
  
  • but it’s a business making opportunity for startups
• CA: native is not closed
  
  • hardware manufacturers trying to make best user experience

Security in native?

• CB: difficult to securely store offline data
  
  • premium audio streaming is not yet possible in HTML5
• EM: a bank developer said “the security people want a native app for encryption reasons”
• AB: why does the online banking not just work on the phone?
  
  • yes, you can have encrypted storage, but do you need it

Best way in for mobile development

• NB: use an app template toolkit for a size that fits
  
  • learn to be a mobile developer…
• what if you just want to see your idea?
• CA: most dangerous word when you start is “just”…
• AB: the reason for the standard layouts on web is ads
  
  • have to build the design to fit the adverts
  • there’s been a boost in design creativity from moving to new formats
  • you can take that newfound focus on user experience and bring it back to the desktop
  • you’d never expect a mobile app to have big gutters down the side
  • unless it’s an iOS 5 app on an iPhone 5…

Notifications

• NB: issue for HTML5 apps
• AB: W3C working on notifications as a spec…

New users from India, China & Brazil won’t be in Apple or Google’s ecosystem

• NB: won’t be a technology decision — more of a distribution

Javascript libraries?

• NB: 85% of development in HTML5 apps goes into javascript

Great new debugging suites for Android Chrome and iOS Safari

• Dominic Travers: great time to develop HTML5 apps!

Will we still be arguing in 5 years’ time?

• AB: native will always be able to innovate faster
  
  • web will be behind, but standardised
  • FT’s Android app is partly native for performance
  • as soon as the browser catches up, they’ll remove the native part

---

Announcements

• W3C coremob.org community group
• UKTI Competition Final 29th October
• 7th Anniversary in November

MomoLondon: Mobile Payments

I arrived a few minutes late and missed the beginning of Dave Birch’s introduction, but I gather it involved Star Trek and early Visa commercials…

Dave has posted his own summary of his introduction which was all about needing a better story to tell about mobile payments. He reckons we don’t have a really good narrative to get people excited about the subject, and that makes it harder to get the future technologies more widespread.

Some other points he raised were:

• Keuffel & Esser (world’s largest manufacturer of slide rules) commissioned a report about the future in 1967. It was amazingly accurate apart for the bit where they went out of business 5 years later due to the invention of the calculator…
• Facebook have money transmitter licenses in 38 out of 50 states — a good start, but not really useful if you need to pay someone and they go on holiday to a state that’s not covered…
• In EU there was a regulatory barrier and now there isn’t — arrival of non-banks will be a big game change
• UK Universal Credit system — payments won’t be by cheque any more
  • going for prepaid accounts
  • £2bn per month will be going through the new system
  • a big opportunity…

He then challenged the panel to come up with some good narratives for digital, mobile money. My usual summarised notes are below. Dave did a good job of making the evening interesting to listen to, but we didn’t really come away with any new stories to tell. As Margaret Gold tweeted later, the most we talked about was buying coffee…

Panel

• Dave Birch, Director, Consult Hyperion @dgwbirch
• Jennifer Payne, Ponti’s Group @pontisgroup
• Russell Sheffield, paythru @russsheffield
• Iain Herd, PayPal Mobile @iainherd
• Nathan Cushnie, O2 Money @gncushnie

Nathan Cushnie: O2’s Mobile Money

• what is the user case?
• just payment as utility is not very exciting
• discovering deals, then paying directly
• consolidating payments with other financial things — the rest of the wallet

Iain Herd: PayPal

• what is the value for the merchants?

Russell Sheffield: paythru

• has to be seamless, global & ubiquitous
• fit the nuances of different cultures
• Turkey have 10-12 merchant accounts for each merchant — they choose which to use
  • in Turkey, terminals are provided by the banks for free so this is possible

Jennifer Payne: Ponti’s (retailer)

• not enough benefits for the retailer
• want the experience to be user friendly, social, tie in to marketing
• want a little hub and want it to be handed to us

Masabi - train tickets

• merchants are terrified that they’ll install the wrong hardware (betamax)
• masabi trying to provide several different versions all the time
• what about a platform that will support multiple systems?

Are we just waiting to clear the logjams before Apple tells us what to do?

• RS: it is complex - have to make sure it’s secure and keeps customer confidence
  • better not to let the consumer decide
• IH: most players not looking at the whole journey
  • Apple good at making things work end to end
  • good at simplicity
• JP: so many people creating different wallets
  • do I wait for them? do I make my own app?
• NC: don’t want the consumer to have to choose technology

Audience experiences of purchasing on a phone?

• used an SMS to buy using a local currency (Brixton pounds)
  • strong community narrative which was nothing to do with payment
• starbucks app — did what it needed to do
  • very simple
• been in a shop and got pissed off: used Amazon to buy direct
• IH: used Pizza Express payment app
  • audience: fairly simple
  • retailer had no difficulty using it
• audience: bought something in Macy’s
  • frustrated that had to take the phone out of his pocket
• audience: paid with NFC on iPhone at Starbucks
• RS: all down to the customer — the moment they have to think about the transaction, the interruption can stop the payment
• DGW: the goal with the phone is to make things better
• DGW: no good experiences involved PayPal, Barclays, etc
• IH: need big companies involved to get reach — all previous mentions were small scale

Wandering through the building and paying

Do we even need to get our phone out of our pocket? Is it better just to walk around and have things credited to our account automatically?

• Ben Whitaker, Masabi: femto cells on trains/buses… could just pick up people on the journey by being there
  • what about people on the bus stop?
  • track people across the journey…
• PayPal Here/Square: check in to a merchant
  • next time you’re in the shop, the POS terminal shows your face
  • you can pay just by walking up to the till and talking
  • loyalty scheme — offers targeted at retail customers
  • POS machine shows how many times you’ve been in the store, what your last purchase was…
• what does the mobile channel deliver?
• is just leaving your wallet behind enough of a change?
• JP: people go to a restaurant for the customer experience
  • just ordering on your phone is a lonely experience…
  • want engagement as opposed to payment
  • if it comes to payment later then that’s good

mobile should do more

• payments going through to expenses automatically?
• want someone to help me budget & track my spending…
• NC: narrative needs to be bigger than just a transaction
  • accounts departments won’t accept electronic receipts at the moment…
• RS: NatWest doing moneyless accounts in last couple of months
  • been that way for 15 years in South Africa because banks & mobile operators working together
• DGW: Orange & NatWest did a trial in 1996… unfortunately not much has happened since then

Is it really just a squabble about who owns the customer?

• IH: when working at a mobile operator, looking far too much at the commercial model than at what the consumer actually wanted

Risk - mobile payments should be more secure, and therefore cheaper?

• IH: very large percentage of PayPal is risk management
  • when talking with partners, that’s one of the main things they bring to the table
• however, PayPal’s risk management seems to involve offloading a load of risk onto the merchant — see the various articles about PayPal seizing and freezing accounts

What about identity on mobile?

• RS: single sign-on
• NC: not really looked at identity
• IH: PayPal has less accounts than Facebook, but they’re all verified
• DGW: if you figure out identity, then payment falls out in the wash…

What about payment with non-currency, e.g. selling personal information?

• despite the promise of a new idea, this question didn’t get much of an answer…

Why can’t I take the phone round a supermarket and scan products as I go myself?

• NC: O2 Wallet does include a bar-code scanner
  • can scan a virtual/digital barcode poster shop
  • next step would be paying for real things

Don’t want Starbucks & McDonalds — I want independent merchants

• Not just taking the payment utility, want community and local interest

Replicating existing stories hasn’t worked - successes are those that create new markets

• “What frustrates me is that those electronic, mobile transactions don’t appear any different in my bank statement”

Working backwards from the future

• NC: consumer makes a gesture; consolidate offer & loyalty points; merchant gathers data

Payment of medium sized amounts between people (e.g. £600 for doing something)

• PayPal is not legal tender — cannot force someone to be paid by PayPal…
• the revolution is on the customer acquisition side, never on the usage
• IH: PayPal focused on getting to Facebook size
• it’s only a matter of time until you can send money via Facebook
• audience: if you get a parking ticket, pay it by PayPal — it totally confuses them!
• want to pay a builder, who pays his contractors, who use the money immediately to go down to the pub — cash is the only accepted mechanism right now
• DGW: refuses to pay cash as he refuses to take part in the black economy!
  • part of the story could be that you’ll pay less tax if you pay by mobile :-)
• IH: can give people prepaid PayPal credit cards — they can withdraw cash from an ATM

What about beggars? Small transactions to unknown people

• DGW: contactless terminals by busker pitches in the underground set at £1
• DGW: Not a problem he’s trying to solve…

Should I have the right to make an anonymous payment?

• IH: that’s where PayPal came from
• Data that goes with the payment that seems to the root of the business models we were talking about earlier…

Would it be good for Ponti’s to get rid of cash?

• JP: it’s not on our radar — all that matters is that we get paid and the customer is happy

What is the market asking PayPal for?

• in UK fashion group pay by barcode
• all German shops close on a Sunday, but can put panels (with QR codes) in windows so people can shop online when you’re closed

Is showrooming a problem for retail (comparison shop and then buy online)?

• JP: Not particularly true in a restaurant…

Wrap up:

• need to look bigger than just replicating credit cards
• In 1967 the USA banks thought it would take at least until the 1980s to get rid of cheques… Money changes very slowly

---

Announcements

• Samsung Smart App Challenge - $4m worth of prizes
• 19th July — Smart Accessibility Workshop: 4-7pm
  • what to think about when designing apps on mobile
  • already a third full
• 24th July — Mobile Apps Marketing

MomoLondon: Data Driven Mobile Apps - Open data and more...

I missed last month’s Mobile Monday on Mobile Games but this panel more than made up for it.

Thanks to Jo Rabin and the rest of the Mobile Monday team for organising, and to Kasabi for the drinks!

Panel

• Chair: Matt Biddulph @mattb - http://hackdiary.com
  • used to run http://dopplr.com
  • then worked for Nokia as Head of Data Strategy in Location & Commerce apps
  • any mobile phone company is becoming an information company
  • a data driven app is one that gets better the more data it has
  • good example is the evolution of Foursquare
  • in the last few months, they have added features to let you explore the area around you
  • human interaction and input makes data come alive
• Leigh Dodds @ldodds - CTO, Kasabi
  • Kasabi trying to make data more accessible and easier to use
  • most of the apps I use are just interfaces to content, though not really data driven
  • data driven would be getting data from lots of people, or from historical data
  • favourite app is MyFitnessPal: a calorie tracking app that tracks everything he eats — either barcode or search
• Jeni Tennison @JeniT - Linked Data Expert, Technical Architect for http://legislation.gov.uk
  • been involved in data.gov.uk esp. linked data
  • mobile devices have a lot of context available
  • how do we create the API that allows us to get out just the data we need for right here, right now?
  • what is the UI to summarise the data and pull out the really interesting bits?
  • pulling in data from multiple sources
  • feeding back data
• Ian Holt @IanHolt - Developer Programme Manager, Ordnance Survey
  • quality of data is paramount
  • OS run masterclasses to help people use their data
  • favourite data app: ASBOrometer
  • what was important was people’s perception of the data…
• Hannah Donovan @han - Design Director, This Is My Jam
  • used to work at last.fm
  • thisismyjam is just coming out of beta
  • data driven apps provide a key to the mess of the universe around you

What are your favourite datasets

• LD: NHS dictionary of medicines and devices
  • recently been relicensed under new open govt license
  • everything that you could ever be prescribed
  • annotated with mappings through to product codes — so can scan a barcode and get a reference
  • good base data set as can reliably ensure people are talking about the same thing
  • a crucial problem in big data…
• IH: often the geo data is a backdrop rather than the actual IDs
• HD: echonest danceability
  • at a hackday made a prototype to throw a track at a robot to dance to it

Do apps get worse with more data?

e.g. twitter signal/noise dropping?

• HD: bad example: Spotify getting hooked up to facebook and timelines being spammed…
  • thisismyjam trying for a slower pace
  • doing things realtime is hard but just becoming possible
  • has been a trend just to add more realtime ‘cos it’s cool
  • but actually we want to see more useful social & cultural info not just realtime firehose (“API vomit”)
• IH: crowdsourcing is great but watch the quality…
• JT: developers like to put everything on the screen
  • but need to think about that the user wants to do and how they’re going to do it
• MB: should be a symbiotic relationship between designer and developer
  • not even back and forth, but an exploration

Good/bad experiences of designer and developer? How do you avoid API vomit?

• LD: pairing up with a designer to explore some ideas is really interesting
  • designer asking “can I do this?” - stretching the developer
• attendee: disagree completely! esp. govt should not pre-judge data based on use cases
• IH: there has to be cartographic decisions at some point
  • what do we do now that we want digital output from the data that was collected previously for paper use
• JT: there’s difference between what is available in the API and what’s shown in the UI

Historically, data was in libraries by default — in the public domain. But now owned by corporations. Have we sleepwalked into the police state?

• LD: in a library is not public domain - now data is more accessible
• HD: there were also people who controlled the content in libraries and only a few people had access
  • now the data is accessible from anywhere, not just in a big city centre

Combination of licenses from different data

• Creative Commons movement has tried to clarify the concepts of collaborative works etc
• If I want to take open govt data and combine it with wikipedia…?
• LD: there aren’t any hard and fast answers
  • still in a murky state
  • Creative Commons is very useful and people are starting to apply them to their data, but creative commons licenses do not apply to content in Europe
  • though there does appear to be CC 2.0 licenses available
  • been some work in Creative Data Commons
  • commercial data has custom licenses
  • generally assume that the most restrictive license applies
  • attribution stacking problem — might have to attribute 1000 people to use one piece of data

Where does the data in an app come from?

• IH: data may be untraceable
• HD: really important to tell your users where the data is coming from
  • we still need quite a lot of different sources
  • content, editorial, user generated
  • depending on what you’re looking for, the answer might be different every time
• JT: in legislation data, trying to maintain audit trails
  • if something goes wrong, want to know where

If data is important to people, it will tend to become free…

• IH: OpenStreetMap are a wonderful bunch of people
  • OS remit is to capture a high degree of detail
  • have to have a universal coverage of Britain
  • some of data has been released as open, and some is licensed
  • keep pressuring for what you want and it might be delivered…

A mobile data driven app: integration and consequence

• MB: important word is “driven”
  • there are plenty of static data sets, and data based applications
  • the thing that I do is magnified either by the depth of reference, or the other people who have done a similar thing
  • need to involve connected reference data and activity data
• HD: people are the special sauce
  • navigating a mess - the layers that people create around what’s around
• MB: in the first year or two, delicious.com/popular or the twitter hashtags were actually interesting
  • but with too much data, everything tends to bland
  • this is a huge issue with data driven apps
• HD: last.fm data was indie focussed
  • but when integrated with XBox suddenly changed overnight to reflect country wide
  • overall stats now reflect national taste
  • but can drill down by category
  • but need to watch out for the important filters — make sure you don’t lose the “friend dataset”

Data protection: need to ask users to explicitly opt-in

• IH: MapAction in Haiti
  • some events will create a lot of noise
  • needed to concentrate in specific countries
• JT: UK is pretty near the forefront of open govt
  • open data institute
  • hard to work in balance with legal framework

Privacy: user backlash

e.g. Path uploading your address book without asking

• LD: product development — want to get as much data as possible as that’s where the value is
  • from the consumer side, want to know where the benefit is for me
  • don’t want to give it away just for marketing or selling on
• HD: we’re currently working with blunt tools when explaining to user how we want to use consumer’s data
  • OAuth screens don’t offer room to tell you how your data will be used

Web or apps?

• MB: most exciting thing is the phone being full of sensors
  • the map (generated data) can become worth more than the territory (the app you build)
  • so always think about native apps over web
• JT: (as W3C contributor) should always be using proper web apps, of course…
  • but apps can always get more data than generic standard APIs
  • payment model is good on devices but not good at the moment on open web

Is there a good description of different types of data and how you might need to combine them?

• HD: use cases are fundamental
  • often see a tendency to make things consistent
  • but the different things may have different contexts
  • for example, last.fm on a TV with XBox is different to what you would want on your phone
• LD: took a while for the language of film to evolve
  • maybe we’re going through the same thing in mobile?

What kind of data stores are people using in real life? NoSQL, RDF, Oracle…?

• MB: more about really rigorous approach to data identity
  • have to keep provenance and individual promises

Is there any way I could buy and sell my data?

• LD: lot of work going on in this area
  • storing personal data and allowing apps access to it
  • My X (?) in the UK
  • Ed.: I couldn’t find a reference for this one

Announcements

• 19th March: ePublishing/eBooks
• 2nd April: DEMO NIGHT
  • applications open very shortly!
  • looking for 16 companies
• Mobile 360 Live
  • 20% discount for Mobile Monday London members

iOSDev UK: Design Considerations for Educational Apps

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

http://speirs.org

• 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:
  • Rasterbator
  • Procreate
  • Little Snapper
  • hardware growler
  • mental case
  • FlashToPass
  • http://gojobby.com
• 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
  • see toontastic
• 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

• preschool memory match
• the history of jazz
• slice it — but gets too hard too quickly
• DrawRace 2
• Real Racing 2 HD — but uses up huge amounts of battery
• toca tea party — not a game but a digital toy
  • have a virtual tea party around the iPad
  • lots of other other toca “games” available — see http://toca.com
• math bingo
  • gather “bingo bugs” and then use them in a breakout game
  • 15 year-olds were saying “why do we not have math bingo?”
• penultimate
  • write on a project as you walk around

Q&A

• 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 :-)