Cyril Mottier

“It’s the little details that are vital. Little things make big things happen.” – John Wooden

Highlighting Search Terms

Every day, hundreds of millions of people make videos, take photos, send messages, etc. The amount of data resulting from the everyday Internet activity is amazing and mostly created by individual users. Fortunately, a lot of applications are providing searching or filtering capabilities to help users quickly browse and find content. Whenever an app creates or provides content, it comes with a search feature: Gmail, Google Calendar, Play Store, etc.

Although search is usually one of the main entry point in a mobile app, I regret to see a lot of mobile apps are not always implementing search in a comprehensive way. Specifically, I often end up having search results presented to me but don’t always understand why. In this article, I will introduce you to search results highlights, explain you why they are extremely helpful from a user point of view and how simple it is to implement them in an Android app.

Seamless Linking to Your App

I gave a talk at DevFest Nantes recently. The talk, entitled “Seamless Linking to Your App”, was focusing on some ways to tear down the walls between your website and your native mobile application as stated in the abstract:

An Android app is usually only a single part of a larger product. Indeed, a product is usually made of several independent entities such as a website, one or several mobile apps, etc. In this talk, we will learn how to increase app engagement and tear down the walls between your website and your apps. You will also discover how you can give your users the most integrated mobile experience possible with features such as Related Apps Banner, Smart Lock for Passwords and more… In a nutshell, this talk is all about driving users to your mobile app and making your product successful.

Launch Screens: From a Tap to Your App

Last Friday, I was attending the mDevCamp conference in Prague, Czech Republic. I gave a talk entitled “Launch Screen: From a Tap to Your App” and spent a really wonderful time there. Here is the abstract about the talk:

The launch screen is a user’s first experience of your application and, hence, should be designed with great care. In this talk, we will deep dive into the concept of launch screen, discover how to measure, debug & optimise them efficiently, and learn more about how to implement them correctly. In other words, this talk is all about discussing for ±45 min about screens displayed less than 5 seconds.

The Android Clock App Clinic

I was recently invited to Ankara, Turkey for the Android Developer Days. I gave a talk entitled “Deep Dive Into Android State Restoration” and spent a wonderful time there. In order to go to the event I obviously spent a lot of time travelling. The travel, in addition to usual transportation issues (cancelled trains, delayed flights, etc.) gave me plenty of time to get bored… For some reasons, I started playing with the Android Clock application and noticed several issues and possible improvements.

This post can be considered as a quick app clinic on the Android Clock app. App clinic is generally dedicated to third-party apps but, after all, there is absolutely no reasons it can’t be performed on Google apps… I also think showing and explaining the few details that could have been better is a great way to learn and improve. Demonstrating a UI/UX guideline using both great and bad examples is how most human interface guidelines are based on. Material Design guidelines use this method a lot. Also keep in mind guidelines and reviews are not definitive rules and are, by definition, subject to discussion.

A Story of Software Development Methodologies

I have been recently asked how the Android team at Capitaine Train is working: “How often do you release new versions of the application?”, “What’s your versioning strategy”, “Do you beta test builds?”, etc. Let’s be clear: I’m not a processes/methodologies freak and prefer not to talk about them most of the time. I would rather consider myself as a product guy. However, no matter how great a product is, software development processes take part of its success. This article is an attempt to share and discuss about our “way of working” in the Capitaine Train for Android team.

Note: Prior deep diving into this article, let’s start with a quick disclaimer. Indeed, I think it is mandatory to mention the strategies, processes and other methodologies described below are far from being ideal. Just like there is no perfect answer in UX or development, there is no perfect way to deal with large projects. In other words, this article has no intentions to force you to switch to new methodologies and should be read as a simple feedback on how the team manages projects like the Capitaine Train for Android apps.

Grid Spacing on Android

Most user interfaces - on both mobile and web - are based on a notion of grids. Grids basically consist on splitting the user interface in a bunch of aligned squares that can be merged together to create blocks. Using the grid principle while designing UI helps aligning elements, brings consistency, cleans up the code, ensures users can easily parse the content of the UI, etc. In a nutshell, grids are an extremely powerful designing tool.

Using the grid principle generally requires developers to add some extra padding/margin/spacing (choose the name that best fits your style…) between elements. Indeed, adding spacing between elements helps maintaining a clear separation between blocs while still maintaining high level of readability of your UI. All Android developers are familiar with these concepts and most cases are actually solved by using framework features such as padding and/or margin on Views. In order to clearly isolate the logic from the UI, this is generally done in the XML definition of the interface. While this works particularly great when the UI is quite static, it may be harder to manage dynamic UIs where elements get hidden/shown on demand. This article gives you some tips and tricks to better manage dynamic grid-base UI.

Putting Your APKs on Diet

It’s no secret to anyone, APKs out there are getting bigger and bigger. While simple/single-task apps were 2MB at the time of the first versions of Android, it is now very common to download 10 to 20MB apps. The explosion of APK file size is a direct consequence of both users expectations and developers experience acquisition. Several reasons explain this dramatic file size increase:

  • The multiplication of dpi categories ([l|m|tv|h|x|xx|xxx]dpi)
  • The evolution of the Android platform, development tools and the libraries ecosystem
  • The ever-increasing users’ expectations regarding high quality UIs
  • etc.

Publishing light-weight applications on the Play Store is a good practice every developer should focus on when designing an application. Why? First, because it is synonymous with a simple, maintainable and future-proof code base. Secondly, because developers would generally prefer staying below the Play Store current 50MB APK limit rather than dealing with download extensions files. Finally because we live in a world of constraints: limited bandwidth, limited disk space, etc. The smaller the APK, the faster the download, the faster the installation, the lesser the frustration and, most importantly, the better the ratings.

Android Wear Flat Device Frame

As some of you may know, I recently release my first publicly available Android Wear application: Capitaine Train Android Wear1. As part of the design and development process I had to create some mockups and wireframes. All of these prototypes were made thanks to Photoshop CS6 and based on a 280x280 document. This square document represents the actual screen resolution of one of the currently available Android Wear watches: the LGE G Watch.

Working on full-frame screenshots is usually enough in the design and development phases of a mobile app. But when it comes to marketing, communication and promotion, device-frame screenshots should be favored over full-frame ones because they give life to your product. Indeed, device-frame screenshots have the advantage of bringing your application to the real world by associating it with the objects/devices it will be running on.

Because I recently had to give some Android Wear-related presentations, I wanted to have a nice and simple way to integrate my screenshots into actual device frames. I had a look on the Internet but was quite disappointed about the resources currently available2. As a consequence, I made my own device frame and would like to share it with you so that you can use it in your presentations or simply when promoting your Android Wear app.

Shaping the Future of Android With Dart

In the past week there have been a tremendous number of discussions, tweets, posts, articles, etc. about some new and modern programming languages. There is no doubt that these sudden swirls have been motivated by Apple unveiling a brand new language called Swift at WWDC 2014. Being on vacation for the past two weeks, I have read quite a lot about the Swift programming language, its syntax, its features, its Objective-C interoperability, etc. But I have also seen some people claiming Android, from a developer point of view, is out of date compared to iOS? Why? Because it is based on Java.

To be honest, I agree with them. It has been a long time I have been claiming Google should ditch Java for another language. The thing is I think Google has been working on a replacement programming language just as long as Apple did - in secret - on Swift (i.e. 2010). So? What is this modern programming language? Some people think Go would be a great fit, I personally think Dart is more appropriate. I read and learned a lot about Dart during my vacation. From my point of view, for many reasons Dart is better for Android than Go: it is more mature, it is VM-based (just like Java), it better fits the Google ecosystem and it has an extremely easy learning curve while still remaining a simple language. It’s clearly time for Google to make Dart the future of Android and, in a global fashion, the future of the company itself.