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

iOSDev UK: Standing Out from the Crowd

Craig Lockwood, HuwDavid, @craiginwales

• put a QR code on the presentation screen for a voting web page
  • works surprisingly well (given good network connection…)
  • voting page was well presented too http://wbxapp.com/join-in
• pre-render your icon so you have control of the gloss
• localisation
  • french, dutch, german, italian translations pay dividends
• app microsite
  • drive traffic with google adwords & track with analytics
  • good example: http://thecocktailapp.com
• 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…

Q&A

• 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

BarCamp London 8: The Future of TV

Simon Maddox — @simonmaddox

Simon gave a brief intro into how he watches television shows (I missed the beginning, but part of his setup involves using plex on his iPad and on his screen at home). He then invited a discussion which centred around whether TV would move totally to online streaming in the future, or whether the broadcast model still had some life left…

• coming soon: YouView (Project Canvas in a box)
• how do I find out what I should watch next?
  • often it gets a series or so in before I hear about it…
• where’s the last.fm for tv?
• some TV is funnier with the commentary on twitter (e.g. x-factor)
  • have to watch that live to experience it properly
• sports are also something people want to watch live
  • but there are not enough broadcast channels to cover all the matches…
• can’t ignore those without digital…
• olympic games will be a big test and a switchover
• does broadcast save money over streaming?
  • possibly at the moment
  • but being solved and won’t be so much of problem in the future
  • e.g. bittorrent being modified to support streaming
• perhaps the biggest change will be content producers
  • big players (ITV etc) may get smaller
• would like to have pay-based or advertising
  • Disney DVDs with non-skippable adverts are taking the piss
  • also problem with DVDs that treat customers as pirates
• older people may be afraid of giving away information
  • may be afraid of a personalised EPG
• sidereel.com — personalised EPG
• music industry revolution has been going for 10 years and is still not finished
  • TV industry revolution is going to take longer

Over The Air 2010

This was my third Over The Air and it more than lived up to the expectations set by the previous two. Billed as “a grass-roots mobile developer event”, Over The Air is an unmissable event on the mobile developer’s calendar — a weekend of fresh presentations from people who are at the cutting edge, mixed with an overnight hack-a-thon competition with prizes awarded in the final presentation.

This year the organisers went for a couple of keynotes (including the major coup of Tim Berners-Lee on the Sunday morning) as well as over 40 seminars on topics ranging from business oriented pitch and product workshops and DIY PR; through introductions to design & prototyping tools such as Flowella and iProcessing; all the way to detailed technical explanations and tutorials such as using Paypal’s mobile SDKs and Bryan Rieger’s excellent presentation on building mobile and desktop compatible web sites (of which more later).

I’ve put my rough notes on the presentations below, but it’s worth checking out the other presentations that were spotlighted on Slideshare and the other blog entries featured in the overtheair twitter stream.

I also entered the hack-a-thon competition and won Best Hardware Hack as well as Best use of “other features”?! for my LEGO Mindstorms robot with an iPhone brain that followed faces. I’ll be posting the code for my hack shortly…

Keynote: the art of emotional design

Aral Balkan — @aral

• when computers made the impossible, possible, features mattered
  • …and it didn’t matter if the interface was hard
• mobile phones are now a commodity, but we’re willing to pay extra for some things
  • “I think Apple is on to something”
• you cannot compete on features any more:
  • when infrastructure is commoditized, the differentiating factor is User Experience
• Le Petit Prince: “perfection is achieved … when there is nothing left to take away”
• you need someone with the authority and responsibility to say “no” to extra features
• “usable” = “edible”
• we want to aim for “magical”
• Aral tries to stay “naive” so that he can understand interfaces from the point of view of an everyday person (not a developer)
• don’t trick the user
• build in “delighters”
  • not required for interaction, but…
• oslo bullet train ticket machine:
  • just a credit card slot
  • exit also has a credit card swipe
  • can get a receipt later online
  • made a difficult decision: knew that fraud rates would go up
  • but worth it for increased usage
• dangers:
  • weakest link is what is not under your control
  • e.g. facebook pulled the plug on Feathers for Facebook (now Feathers Visage) without warning, just as the app was featured on the German and Austrian app store

DIY research workshop – informing the design process

Mark A.M. Kramer — @mamk

• users have different issues to those in the mobile industry
• Mark does “nomadic ethnography” — mainly based on trains :-)
• often finds himself being a participatory observer
• Mobile research methods
  • e.g. woman on circle line instinctively knew when network was available — put the paper down and switched to checking her mail
• iPhone is a good ethnography tool — can take pictures secretly!
• mobile also enables surveys in the field
• culture is changing:
  • mobile is enabling “just in time” — e.g. “just google that”

Mark then showed us various interviews:

• inventor of makerbot and thingiverse:
  • “share or die”
  • integrate game mechanics into whatever you’re doing
• reactable music interface:
  • play along
  • make it fun
  • can really make instruments with accelerometer
• feature phone user from Eastern Europe (no smart phone culture):
  • want something I can read my magazines on (comic books)
  • but want it portable
  • I’ve seen others using iPads etc.
  • social shaping of technology
• 10 year old — what I like about my iPod touch:
  • app developers will become rich if they make something that people like
  • he likes games
  • doesn’t want to pay for things

things to think about:

• eWaste — what about all those unused phones?
• social isolation
• generational differences
• impact on children
• designing for inclusion & accessibility

Orange Mobilise – the mobile volunteering initiative

David Simoes-Brown (Strategy Partner at 100%Open), Jogesh Limbani (Head of Open Innovation at Orange R&D UK)

• Orange using open innovation to encourage ideas to come in to Orange
  • The Wisdom of Crowds, James Surowiecki
  • Cognitive Surplus, Clay Shirky — 100 million hours of adverts watched over one weekend in America, equivalent to the amount of time taken to create wikipedia
• Orange want to help minutes matter
• Tuangou (cloud clout buying) in China
  • gathering people together to negotiate a discount
• Orange want to capture 5 minutes a day from the 3h 45m TV watching for volunteering
• Have previously launched Orange Rock Corps — can earn a ticket to a gig by volunteering
• 1 million people giving 5 minutes = a decade of real time
• http://mobilevolunteering.co.uk:
  • Orange building an app (iPhone to begin with)
  • Gathering ideas
  • Promoting existing apps
• Challenge:
  • can pick an app from suggested ideas
  • contact the author and go
  • OR submit an existing suitable app
• Orange will launch the top three voted apps & actions in October
• Will also launch 7 other apps & ideas as chosen by Orange rather than community
• Voting criteria:
  • You’re on the bus with five minutes before the stop — what can you do?
  • Popular & used often
  • Has a clear social or environmental benefit
  • Practical & attractive to a sponsor charity — needs a backup
  • Looking for a balance of actions:
  • research | lookout | reach out | skill set
  • Also looking for a balance of purposes
• suggest to look at latest & most active rather than top scoring

Rethinking the Mobile Web – a pragmatic look at creating an accessible and inclusive mobile experience

Bryan Rieger @bryanrieger

Bryan gave a fantastic presentation about how to make workable web sites for mobile and desktop use. There’s also a whole load of discussion on slideshare below the presentation about different approaches. The how-to bits of the presentation start from about slide 104, but there’s a load of stats up front to convince you that having a mobile-friendly site is worth it, and that mobile-friendly does not just mean iPhone…

Rethinking the Mobile Web by Yiibu

View more presentations from Bryan Rieger.

• iPhone in US only covers about 6% of the population and only 4% of 5 major EU countries
• Huge impact but not huge penetration (at least of people, but huge percentage of traffic…)
• nice comparison of older (desktop) Macs vs recent mobile phones
• feature phones of today are the smartphones of yesterday
• the old devices don’t suck
• gs.statcounter.com stats from 02/2010
  • lots of Opera Mini in Nigeria
  • lots of BlackBerry in Australia
  • in Feb. the UC proxy browser ate Nokia’s Chinese market share
  • Nokia bought Novarra in March 2010…
• going forward, main browsers in use are WebKit and Opera Mini
  • coming up later are Mozilla Fennec (will be Firefox Mobile), Ovi & UC proxy browsers
• why is it ok to say “this site works best on Safari 4”, when it wasn’t ok to say “this site works best with IE 4…”?
• design “mobile first”
  • @media queries often fail — so taking a desktop site + media queries results in a desktop site on mobile
  • mobile site + @media queries => desktop site
  • not a new idea — just progressive enhancement!
• use screen and handheld types for first stylesheet
• book recommendation: DOM Scripting by @adactio (if jQuery not available…)
• http://tinysrc.net will resize and compress image for you
• infographics may need reinterpretation for smaller screens, rather than just resizing
• a bit of a dream: Bryan would like to extend the <img> tag to have multiple images for different screen sizes
• Q&A: Opera has device stats available from http://www.opera.com/smw/

Viral Survival Kit: Cloud Computing for Highly Scalable Apps

Matt Wood, Amazon Web Services — mawood@amazon.com

A quick overview of Amazon’s cloud services. Useful for working out what you might need. I was kind of hoping for something more technical, but this is good too. Especially useful is the link to the Amazon Simple Calculator, so you can work out how much your requirements might cost.

• Amazon started with two servers (1 db, 1 app server)
• They refactored so that:
  • dev teams could request resources on demand
  • wouldn’t have to worry about scaling & reliability
• AWS is a datacentre abstraction
• can provision a server in about 20-25 seconds (though Windows servers take a little longer due to security certificate isses)
• guardian open platform is delivered using AWS

S3 & CloudFront

• all data is replicated to three different centres
• scaled automatically as demand rises
• can have a reduced redundancy service at lower cost (only 5 9s rather than 11…)
• CloudFront provides CDN

other services

• RDS: relational datastore — MySQL as a service
• EBS: elastic block store
• EMR: elastic map reduce — hadoop on demand
• VPC: virtual private cloud — elastic resources in the cloud appear in your own network through a VPN
• CloudWatch: monitoring, autoscaling
• ELB: elastic load balancer

some detail

• m1.small available for about 8¢/hour
• m1.large has more CPU etc
• t1.micro is even smaller, only 2¢/hour
  • tight RAM constraints (600Mb), but has automatic CPU scaling
• can plan over longer term and get reduced price (0.07¢/hour if you pay $50 upfront)

designing for failure

• can attach an elastic IP address to an instance
• if server fails, can just repoint to another instance in the same datacentre
• also deal with datacentre failures
  • four regions (East Coast, West Coast, Dublin, Singapore)
  • each region has multiple availability regions
• RDS can enable master/slave with an API call

automation

• can pull monitoring data into ganglia
• monitoring can be connected to autoscaling
• can set thresholds for setting up and killing servers
• integrated with availability zones

security

• can have multiple roles with fine grained access
• provide mitigation against DDOS
• default-deny firewall
• see http://aws.amazon.com/security for details
• data stays within regions

Q & A

• Amazon Simple Calculator provides an estimate of costs

What Would Picasso Do — a panel of art and technology

Another brilliant Bryan Rieger production: find six people with interesting ideas and ask them to inspire the audience by talking about what they liked. It worked…

• Bryan Rieger: http://yiibu.com
• Filip Visnjic: http://www.creativeapplications.net/, curator of http://processing.org
• Jason Fields: Head of Multiplatform User Experience at the BBC, also runs http://app.itize.us/
• mills: ustwo
• Matthias Dahlström: lastminute labs
• Tom Hume: Future Platforms

What Would Picasso Do?

View more presentations from Bryan Rieger.

Tom has been thinking about…

• Joseph Beuys: “everyone is an artist”
• Music industry history is minuscule compared to whole history of art
  • we focus on near-sighted things
• Art doesn’t seem to scale
  • engineering efforts can take 100Ks of people
  • what would art equivalents look like
• Constraints feed creativity

mills is enabling creativity…

• granimator: enabling the public to create screen backgrounds
  • invite artists to contribute assets
• making creativity accessible

matthias has been playing with plasticine…

• dali from 1950s: gem-decorated heart with pumping action
• we work on the surface with the gems at the moment
• need to work deeper
• plasticine interfaces — when they’re rough, people want to grab them and play
• Sony has a big blue design book
  • explored wireless headsets in 80s
  • worked in the home, but in shared spaces you would get someone else’s music
  • dismissed at the time, but might now be treated as an interesting feature

Jason has been looking at apps…

• UK is much more advanced than US in area of IPTV & set-top boxes

Filip has been thinking about art…

• linear vs dynamic
• goals vs accidents
• framing / positioning
• interactive vs reactive
• sense of ownership

Q & A

• Are creative apps on iPad/iPhone merely frivolous?
  • e.g. Brushes, Magic Piano
  • TH: 11-point multitouch is not frivolous
  • JF: a device to interact with while watching TV
  • TH: Jeff Minter: apps for Amiga
  • no intermediation — straight onto the screen
• Are there any useful consequences of art-related apps? Can they be applied to productivity-related apps?
  • TH: epic win: a todo list manager that takes game mechanics and gives you experience points for completing todo items…

tweetalondoncab

This wasn’t a presentation on the main schedule, just the cabbie who started @tweetalondoncab talking about where he’s got to and where he wants to go.

• gone from 2 drivers to 120!
• however, can’t cope with more than 3-4 jobs at a time

process

1. customer DMs to @tweetalondoncab
   • may have to come back to them and get further details (inc phone number)
2. the chair account (protected account) advertises the job (removing specifics) with phone number of person in chair
3. drivers get a text alert when tweet sent from chair account
4. driver responds with a phone call and gets job allocated
   • receives phone number and address of pickup
5. chair account sends out that job has been allocated
6. chair account informs customer of their driver’s details
7. driver contacts customer by phone when they’re ready

also have @cabup protected account that provides shared information updates on demand & traffic — added value for drivers who join in

future ideas

• would like to include cab sharing
• still want to advertise to all drivers as it’s their decision to take it
  • first come first served at the moment
  • but would like to add in how long the driver would take to get there
  • especially for higher value jobs (e.g. Victoria -> Gatwick)
• want to attract people who would normally order a private minicab

constraints & ideas

• dealing with 3-4 jobs coming in at once
  • if can see all cabs on map, would be able to tell customers that can’t help within 30 mins
  • driver claiming job is pinch point
  • have a link to a page with how many minutes to be there
  • claim the job automatically
  • could have a form to submit info, so jobs are better structured

Keynote: Sir Tim Berners-Lee

I didn’t get to take many notes during Sir Tim’s keynote as I was busy finishing my hack (of which more in the next post). He was an inspiring speaker in his own way — you could see the passion for his subject shining through.

His main points were about ensuring things are referable, and that the reference can (and should) be done with URLs.

• if an app doesn’t have a URL then it can’t be linked
• it doesn’t get the interestingness — people can’t use it for other things