Note: I started writing this article based on Android P preview 1. Android P preview 2, released at Google I/O 2018, actually removed some (most?) of the APIs used extensively in this blog post. Even though none of the UI tricks described below are possible with Android P preview 2, I thought it was still interesting to share them. Indeed, both the technical and design approaches may still be cool and reusable. Let’s hope this article will motivate Google engineers to bring back the required APIs once they will see what kind of interesting stuff they were enabling with Android P preview 1…

One of the new feature in Android P is the support for display cutouts. A display cutout (a.k.a. notch) is a small cut in a portion of the screen displaying no UI. Generally, notches are at the top edge of the screen and hold the cameras and sensors. The very first device I discovered featuring a cutout was the Essential Phone. Then came the iPhoneX and its large notch. More recently, we’ve seen this “disease” spread out to a lot of other Android OEMs…

As you may have understood, I’m not fan of cutouts in general. First, from a developer point of view, as they require quite a lot of work to deal with them properly: we’ve always been used to rectangle-shaped windows¹. Secondly from a UI designer point of view as they clutter the UI and make it directional. Finally from a user point of view as they are not intelligible nor visually attractive.

Cutouts look like a temporary solution to technical impossibilities. I don’t consider them as viable in the long term and can’t wait to see full edge-to-edge screens. But they help in the mean time. As a consequence, we need to deal with them and that’s probably why Android P brings support for it. I took some time to look at the framework additions in Android P preview 1 and started to have fun with notches rather than complain about their introduction. So let’s have fun with cutouts!

It is no secret I have always had interest in making mobile apps as lightweight as possible. Back in 2014, I wrote “Putting Your APKs on Diet” explaining in details the anatomy of an APK and giving several tips and tricks Android developers can use to reduce the binary size of an APK.

We’re now in 2017 and mobile apps are bigger than ever. According to Sensor Tower’s analysis of App Intelligence¹, the total space required by the top 10 most installed iPhone apps in the U.S. has grown from 164 MB in May 2013 to about 1.9 GB in May 2017, a 12x increase in just four years. Unfortunately, this analysis only focuses on iPhone apps but, from my experience, Android apps has also increased in size in the past four years.

One might say, app file size increase is actually completely normal. Indeed, a lot of things changed in the past 4 years and users expectations increased too: devices have higher densities, apps bundle more features and provide richer experiences, etc. As a consequence, the question is not “Is the increase in file size normal?” but rather “Is the increase in file size smaller/larger than it should”. In other words, does the increase worth the value? The answer to that question is rather complex and subjective.

The recent release of Android O introduced a new concept for launcher icons called “adaptive icons”¹. The main idea behind adaptive icons is to display a variety of shapes across different device models. In practice, each OEM provides a mask which the system uses to render all icons with the same shape. You can obviously read more about adaptive icons on the dedicated d.android.com webpage.

As an icon designer, creating an adaptive icon can be quite cumbersome. You have to deal with several constraints but it’s difficult to have a clear view on the actual look of your icons. In a recent tweet of mine, I mentioned a pretty handy web tool that you can use to get a quick preview of your launcher icons: adapticon.tooo.io

Although this tool is really nice to preview the possible animations of your icons, it also requires you to upload the images on a server and copy-paste their URLs in the appropriate fields making the design process quite lengthy and boring. In order to quickly look at some possible renderings, I recently created an Affinity Designer template:

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.

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.

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.

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.

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.

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.

I gave a talk entitled “Deep Dive Into Android State Restoration” at Droidcon France on Monday, this week. I have been asked if the talk was recorded. The short answer is: it was. Unfortunately the video is still being process by the guys behind Droidcon France. In the meantime, here are some resources you may find useful:

• The slides in PDF format
• The slides in Keynote format (recommended, contains animations)