Recently the Android team at Nexmo attended Android Summit in Tysons Corner, Virginia. Organized by the folks at Capital One the conference gathers speakers from around the globe to speak about designing, developing, and testing for Android. As a bonus, proceeds from ticket sales raised $6000 for Women who Code.

The conference covered three tracks: Design, Develop, and Testing. I’ve chosen a few to detail some highlights of:

Design + Develop + Test

Giving the keynote on the first day, Kelly talked about what communication between designers, developers and testers should look like and shared some excellent tips. A few of the awesome takeaways included:

The developers and designers on her team use Zepelin. It helps layout design mocks and conveys dimensions and spacing easier than PDFs.

Name your colors in a style guide shared between you Designers and Developers, so you don’t have to refer to colors by hexcode.

Get a heatmap of where users try to click to determine the best places for clickable actions using UsabilityHub

Create an emulator for each day of the week and assign each one a different SDK level, this way you’ll find small quirks in your app the are dependant on each version of Android.

Best practices in Building Mobile Libraries

Fellow Neximo Emma talked about what she’s learned from her experience in building SDKs; starting with her time working on Ovi apps, to her work on the Verify SDK, and the upcoming SDK for the Conversation API. Emma’s recommendations include the following:

If you include dependencies when you’re writing an SDK, don’t use dynamic versioning. Differences in versions can break things for your users, and they may not exactly know why.

Double check if you need to include a whole dependency, sometimes you can bring in only the class you need (with proper attribution, of course).

Be wary of permissions your SDK may need. Remember to request permissions and have a fall back if the end user doesn’t grant the permission.

When you’re publishing your SDK, don’t forget to follow proper semantic versioning

Ensure you publish a proper human readable changelog with each release, not just a git log diff.

Designing a Bot with Humanity: How Eno Came to Life

The Capitol One Design Team for Eno

Though this talk wasn’t about Android development per se, it was still extremely relevant to a lot of the work we do at Nexmo. The team at Capital One behind the AI chatbot Eno showed off their product and shared some stories about their experience launching it. Debuting at this year’s SXSW, Eno is an SMS based chat bot that communicates with customers to give them information on their accounts and help them make payments. Part of the reason why I loved this talk was that the among the team that created Eno and gave the talk were a filmmaker, anthropologist, creative director, and head of content. Just goes to show you need more than just a few developers to make a great chatbot! Here are a few of their thoughts:

It is important to establish a character; this was achieved by creating a story and a background.. In Eno’s case, Eno is gender-neutral, transparent about being a chatbot, really likes chatting with humans, and has a sense of humor.

The developers added boundaries to Eno. If a user harasses Eno, it will respond by reminding the user what they’re saying is impolite, and then changes the topic back to the user’s account.

The team decided to make their chatbot available via SMS only since almost 99% of smartphone users still use SMS, and those who don’t use apps like Facebook are still comfortable texting.

What Happens When Everyone is QA? And I Mean Everyone!

Lana Khilko & Cody Henthorne

Two developers from Groupon presented about extending the QA process beyond just the engineering and QA teams. Cody, from engineering, and Lana, from QA, spoke about how they work together and with the rest of the company at Groupon to make sure their app can ship features faster with fewer bugs. Cody and Lana gave advice about each group that works with their app:

Computers: Don’t forget we have machines that can do stuff for us. Set up a CI server that will compile your app and run tests on it. You can even connect it to Slack to send your messages when your builds fail.

Developers: At Groupon, every pull request must have unit tests included in it or the pull request is automatically rejected. In addition, QA and Engineering work together to establish a suite of tests that the developer will run before they send a feature to QA.

QA: The culture between Engineering and QA are important at Groupon. Cody and Lana agree that it’s a partnership, and both departments are on the same team. Lana also acknowledges that QA should have the final say to merge features to reduce the amount of bugs that could be released.

Rest of the company: Groupon relies on dogfooding their app to find other bugs or inconsistencies in their app. They push out beta versions to the rest of the company at Groupon and give them rewards for finding bugs in the app.

Customers: To ensure a smooth release of new versions of the app to customers. Groupon uses staged rollouts when releasing new versions. By releasing apps this way, you can initially release a new version to only 5% of your users, then steadily increase the number of users who have access until you have released to the full 100%. Using staged rollouts, the team can monitor crash reports or negative user reviews.

Those were just a few of my favorite sessions, but there were many more! If you’re feeling a bit of FOMO for missing out on the conference, don’t worry Android Summit recorded all of the talks and will be uploading them in the next couple of weeks. You can subscribe to Android Summit’s YouTube channel or follow them on twitter @androidsummit to be alerted when the videos are released. Congrats to the team at Capital One for organizing a great conference. I look forward to the next one.