Going Universal: iPad Lessons Learned at ING · 2012-05-29 · One more time… • For a high...

Preview:

Citation preview

Going UniversaliPad Lessons Learned at ING

Age MooijAndrew Snare

Things were going well...

Background

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.

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!

“That’s great, but will it also work on my iPad”?– Really Important Manager

The Big DemoSeptember 2011

“That’s great, but will it also work on my iPad”?– Really Important Manager

The Big DemoSeptember 2011

BigPhone™ — Just Scale Up

Plan A

Plan A: Results

• Took 2 weeks

• Developer hated being isolated

• Did not meet UX requirements

• It let us estimate the real effort.

Lesson Learned

For a high quality app, you really need to create a separate iPad UI.*

*Duh!

A Tale of Two Teams

Plan B

iPhone

Universal

iPhone

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.

Lesson Learned

This was a really bad idea!

One Big Happy Family

Plan CnewTeam

oldTeambigTeam = zip(newTeam, oldTeam)

One Big Happy Family

Plan C

newTeam oldTeambigTeam = zip(newTeam, oldTeam)

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.

Lesson Learned

Pair-programming is a fantastic tool for scaling a team up quickly.

So what did we really need to do?

The Nerdy Bits

Splitting the Screen

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.

Lessons Learned

Custom UI and navigation flow is expensive.

View controllers should use a shared model.

Reuse existing view controllers inside model dialogs.

This saved us a lot of time.

Modal Popovers

Here be dragons:-(UIViewController *)parentViewController;-(UIViewController *)presentingViewController;

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

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.

Cleaning up the mess…

Technical Debt

Conscious Compromise

• Decision to trade off technical debt for meeting the deadlines.

• Paying off the debt is still an ongoing effort.

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.

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.

And what’s next?

Where are we now?

A Success Story

> 1,000,000downloads

Lots of feedback (about

missing features)

Consistent 4.5 star rating

4 major releases2 minor releases

About every 6-8 weeks

Sneak Preview

Sneak Preview

Sneak Preview

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.

Thank You!

Age Mooij (@agemooij)Andrew Snare (@asnare)

Questions?

Recommended