Building It Twice - San Jose, Costa Rica, September 2015

An updated version of my talk about building the same app for iOS and Android!

At the end of the talk I mentioned two open source projects that Vokal uses to work with mock data:
https://github.com/vokal/VOKMockUrlProtocol for iOS
https://github.com/vokal/Mocktrofit/ for Android

Transcript

1. Building It Twice Lessons from building apps natively for iOS and Android September 2015 | DevAndDesignCR | San José, Costa Rica by Ellen Shapiro vokal.io | justhum.com | designatednerd.com | @DesignatedNerd
7. Names have been changed to protect the innocent my current and former employers' legal teams
8. Case study #1: Hard Liquor Distribution
9. What does the app do? —Helps distributors sell more of a high-end brand of hard liquor with profit calculators
10. (A lot)
11. What does the app do? —Helps distributors sell more of a high-end brand of hard liquor with profit calculators —Keeps distributors in touch with news from the brand
12. What does the app do? —Helps distributors sell more of a high-end brand of hard liquor with profit calculators —Keeps distributors in touch with news from the brand —Gives distributors access on the go to assets they can use to promote the brand.
13. How was the app built? —Built iOS and Android at the same time.
14. How was the app built? —Built iOS and Android at the same time —Team of 3 iOS and 3 Android developers (not including myself)
15. How was the app built? —Built iOS and Android at the same time —Team of 3 iOS and 3 Android developers (not including myself) —Very, very well defined design from direct client
16. How was the app built? —Built iOS and Android at the same time —Team of 3 iOS and 3 Android developers (not including myself) —Very, very well defined design from direct client —API built and managed by end client...less well.
17. What went well? Please do these things.
18. What went well? What: Extremely clear style guide from the agency
19. What went well? What: Extremely clear style guide from the agency Effect: Devs created reusable styles and classes, changes could be made once, applied everywhere.
20. What went well? What: Extremely clear style guide from the agency Effect: Devs created reusable styles and classes, changes could be made once, applied everywhere. Lesson: Spending time on a clear style guide in design can save a lot of time in development.
21. What went well? What: Designs and wireframes took platform- specific patterns into account.
22. What went well? What: Designs and wireframes took platform- specific patterns into account. Effect: Devs didn't need to ask questions about how something should work on iOS vs. Android.
23. What went well? What: Designs and wireframes took platform- specific patterns into account. Effect: Devs didn't need to ask questions about how something should work on iOS vs. Android. Lesson: Think through how different platform conventions affect the user flow at design time.
24. What went well? What: Platform teams would work on different features at the same time.
25. What went well? What: Platform teams would work on different features at the same time. Effect: Each team was able to tell the other about potential land mines in that feature before building.
26. What went well? What: Platform teams would work on different features at the same time. Effect: Each team was able to tell the other about potential land mines in that feature before building. Lesson: If you're building in parallel, don't always have all teams building the same thing.
27. What went poorly? Please do not do these things.
28. What went poorly? What: While iOS only had to support the current version (iOS 6), Android had to support Gingerbread.
29. What went poorly? What: While iOS only had to support the current version (iOS 6), Android had to support Gingerbread. Effect: The same feature on Android 2.3 would take multiples of the effort it took to build on iOS 6.
30. What went poorly? What: While iOS only had to support the current version (iOS 6), Android had to support Gingerbread. Effect: The same feature on Android 2.3 would take multiples of the effort it took to build on iOS 6. Lesson: Think hard about effort to support a platform vs. # of customers using that platform.
31. What went poorly? What: Backend team was behind schedule, changing environment without notifying app devs
32. What went poorly? What: Backend team was behind schedule, changing environment without notifying app devs Effect: When something would go wrong, it would waste twice as much time.
33. What went poorly? What: Backend team was behind schedule, changing environment without notifying app devs Effect: When something would go wrong, it would waste twice as much time. Lesson: Set up clear times for updates and clear channels for communication.
34. What went poorly? What: Neither the iOS nor Android teams wrote many tests.
35. What went poorly? What: Neither the iOS nor Android teams wrote many tests. Effect: When something broke, we didn't know until much later, and it was hard to find the cause.
36. What went poorly? What: Neither the iOS nor Android teams wrote many tests. Effect: When something broke, we didn't know until much later, and it was hard to find the cause. Lesson: Writing tests costs time up front, but saves time later.
37. Case study #2: Getting Your Car Back From The Valet
38. What does the app do? —Allows users to request their car from their phone and pay/tip with a credit card.
39. What does the app do? —Allows users to request their car from their phone and pay/tip with a credit card. —Notifies valets when a car has been requested.
40. What does the app do? —Allows users to request their car from their phone and pay/tip with a credit card. —Notifies valets when a car has been requested. —Notifies users when their car is being retrieved.
41. What does the app do? —Allows users to request their car from their phone and pay/tip with a credit card. —Notifies valets when a car has been requested. —Notifies users when their car is being retrieved. —Gives users a cashless valet experience
42. What does the app do? —Allows users to request their car from their phone and pay/tip with a credit card. —Notifies valets when a car has been requested. —Notifies users when their car is being retrieved. —Gives users a cashless valet experience —Users don't wait for their car in the rain / cold.
43. How was the app built? —Built iOS MVP, then built Android client as iOS added new features.
44. How was the app built? —Built iOS MVP, then built Android client as iOS added new features. —Single-developer team per platform (i.e., I built 90% of both MVP apps myself #humblebrag)
45. How was the app built? —Built iOS MVP, then built Android client as iOS added new features. —Single-developer team per platform (i.e., I built 90% of both MVP apps myself #humblebrag) —In-house design by Vokal
46. How was the app built? —Built iOS MVP, then built Android client as iOS added new features. —Single-developer team per platform (i.e., I built 90% of both MVP apps myself #humblebrag) —In-house design by Vokal —In-house backend by Vokal
47. What went well? Please do these things.
48. What went well? What: Backend team was well ahead of schedule for initial iOS build, APIs were well-documented
50. via https://www.flickr.com/photos/girliemac/6514584423
51. What went well? What: Backend team was well ahead of schedule for initial iOS build, APIs were well-documented Effect: I rarely ran out of stuff to do and was almost never blocked by backend issues
52. What went well? What: Backend team was well ahead of schedule for initial iOS build, APIs were well-documented Effect: I rarely ran out of stuff to do and was almost never blocked by backend issues Lesson: App dev is hard without a working backend. Get your BE team ahead as far as possible.
53. What went well? What: iOS app was built to MVP before Android app build started.
54. What went well? What: iOS app was built to MVP before Android app build started. Effect: Issues only needed to be fixed once. User feedback was addressed before Android started.
55. What went well? What: iOS app was built to MVP before Android app build started. Effect: Issues only needed to be fixed once. User feedback was addressed before Android started. Lesson: Building sequentially can save time on subsequent apps.
56. What went well? What: Thorough, clearly named UI and behavior- driven tests for iOS were written
57. What went well? What: Thorough, clearly named UI and behavior- driven tests for iOS were written Effect: Test names/comments could be lifted to start tests on Android, saving even more time.
58. What went well? What: Thorough, clearly named UI and behavior- driven tests for iOS were written Effect: Test names/comments could be lifted to start tests on Android, saving even more time. Lesson: Having the 1st app tested makes it easier to ensure later apps are testing/doing the same thing
59. What went poorly? Please do not do these things.
60. What went poorly? What: I vastly underestimated how much I had to relearn and how much had changed in Android dev
61. What went poorly? What: I vastly underestimated how much I had to relearn and how much had changed in Android dev Effect: A lot of gains from the things that went well were cashed in on rewriting functionality and tests.
62. What went poorly? What: I vastly underestimated how much I had to relearn and how much had changed in Android dev Effect: A lot of gains from the things that went well were cashed in on rewriting functionality and tests. Lesson: Either get a specialist, or add significant padding to account for ramp-up on a platform.
63. What went poorly? What: User feedback was not sought out before we started building due to budget concerns.
64. What went poorly? What: User feedback was not sought out before we started building due to budget concerns. Effect: Users, especially Valets, had very different ideas of required functionality than we had, causing a lot of rework.
65. What went poorly? What: User feedback was not sought out before we started building due to budget concerns. Effect: Users, especially Valets, had very different ideas of required functionality than we had, causing a lot of rework. Lesson: Don't wait to reach out to your user base.
66. Obligatory Summary Slide™ —Style guides: Not just for the web anymore!
67. Obligatory Summary Slide™ —Style guides: Not just for the web anymore! —Get user feedback before you start building
68. Obligatory Summary Slide™ —Style guides: Not just for the web anymore! —Get user feedback before you start building —Get backend development as far ahead of client app development as possible
69. Obligatory Summary Slide™ —Style guides: Not just for the web anymore! —Get user feedback before you start building —Get backend development as far ahead of client app development as possible —Functional/Behavior tests are far easier to repeat across platforms
70. Obligatory Summary Slide™ —Style guides: Not just for the web anymore! —Get user feedback before you start building —Get backend development as far ahead of client app development as possible —Functional/Behavior tests are far easier to repeat across platforms —Communicate early and often
71. Question time!
72. Closing Vanity Slide Work: vokal.io mobilemakers.co Personal: @DesignatedNerd | github.com/DesignatedNerd justhum.com | designatednerd.com