Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Going Universal - iPad Lessons Learned at ING

Going Universal - iPad Lessons Learned at ING

A talk I gave together with Andrew Snare at GOTO Amsterdam 2012 (May 25th) as part of the tablet track.

It's about how an iOS development team at a large Dutch bank dealt with a last-minute requirement change that our iPhone-only mobile banking app should be released as a universal app, with a customized iPad UI. This happened about a month before we were supposed to go live and the app was not finished yet.

It describes the options we considered, the process we eventually chose, the high-level technical design decisions we made, and the results.

C2d2eb5dc036708dac0282dc78f88a03?s=128

Age Mooij

June 07, 2012
Tweet

More Decks by Age Mooij

Other Decks in Programming

Transcript

  1. Going Universal iPad Lessons Learned at ING Age Mooij Andrew

    Snare
  2. None
  3. None
  4. Things were going well... Background

  5. The Challenge • Strong focus on UI look and feel

    • Heavily customized/styled UI • Complex security requirements • Coming from behind the market • There was an existing app based on the MSN chat-bot: universally embarrassing.
  6. The Process • A pilot scrum project at ING •

    2 week sprints • Started with one team, grew to 3 teams (iOS, Android, backend) • Dedicated UX people • Lots of internal stakeholders!
  7. “That’s great, but will it also work on my iPad”?

    – Really Important Manager The Big Demo September 2011
  8. “That’s great, but will it also work on my iPad”?

    – Really Important Manager The Big Demo September 2011
  9. BigPhone™ — Just Scale Up Plan A

  10. Plan A: Results • Took 2 weeks • Developer hated

    being isolated • Did not meet UX requirements • It let us estimate the real effort.
  11. Lesson Learned For a high quality app, you really need

    to create a separate iPad UI.* *Duh!
  12. A Tale of Two Teams Plan B iPhone Universal iPhone

  13. Plan B: Results • Lasted half a sprint • Not

    sustainable due to merging overhead • New team couldn’t help but slow the original team: they needed help.
  14. Lesson Learned This was a really bad idea!

  15. One Big Happy Family Plan C newTeam oldTeam bigTeam =

    zip(newTeam, oldTeam)
  16. One Big Happy Family Plan C newTeam oldTeam bigTeam =

    zip(newTeam, oldTeam)
  17. Plan C Result: 1.0 • This worked! • Some pairs

    worked on new functionality, some on existing screens. • Took 6 weeks, instead of 3 • Business very very happy.
  18. Lesson Learned Pair-programming is a fantastic tool for scaling a

    team up quickly.
  19. So what did we really need to do? The Nerdy

    Bits
  20. Splitting the Screen

  21. Splitting the Screen • Oh, the pain: UISplitViewController • It

    must be the root, but our starting grid is. • View controllers could no longer be in charge of the entire screen. • Handling teardown on errors was very very hard. • Keeping the two sides synchronized: • Current balance • Refresh detail triggers refresh of master • Refresh master triggers selection, which forces refresh of the detail.
  22. Lessons Learned Custom UI and navigation flow is expensive. View

    controllers should use a shared model.
  23. Reuse existing view controllers inside model dialogs. This saved us

    a lot of time. Modal Popovers Here be dragons: -(UIViewController *)parentViewController; -(UIViewController *)presentingViewController;
  24. if (iPad) … • Sometimes we could get away with

    a more generic solution: view.autoresizingMask = UIViewAutoresizingFlexibleWidth | …; • We used a lot of if-iPad blocks: if ([UIDevice currentDevice].userInterfaceIdiom == UIUserInterfaceIdiomPad) { … } • We used subclassing: @interface FooViewController_iPad : FooViewController @end
  25. Rotation • Rotation was originally omitted to save time. Not

    an acceptable compromise on the iPad: people expect all orientations to work. • Lots of small changes required, mainly with autoresizing behaviour.
  26. Cleaning up the mess… Technical Debt

  27. Conscious Compromise • Decision to trade off technical debt for

    meeting the deadlines. • Paying off the debt is still an ongoing effort.
  28. Lesson Learned Technical debt can be acceptable… BUT …be aware

    it may never be paid off. Don’t make the compromise if this is unacceptable.
  29. Next time? Just start with universal from the start…? Stay

    agile, but anticipate going universal: • For example, UI/UX design that is easier to scale.
  30. And what’s next? Where are we now?

  31. A Success Story > 1,000,000 downloads Lots of feedback (about

    missing features) Consistent 4.5 star rating 4 major releases 2 minor releases About every 6-8 weeks
  32. Sneak Preview

  33. Sneak Preview

  34. Sneak Preview

  35. One more time… • For a high quality app, you

    really need to create a separate iPad UI. • Bad idea: 2 teams, 1 product. • Pair-programming is a fantastic tool for scaling a team up quickly. • Custom UI and navigation flow is expensive to build and maintain. • View controllers should use a shared model. • Technical debt may never be paid off: don’t make the compromise if this is unacceptable.
  36. Thank You! Age Mooij (@agemooij) Andrew Snare (@asnare) Questions?