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

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:

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.

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.

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.

Note: I generally blog about subjects I don’t deal with in my day to day life at work. However, the article below mentions some work I have done at Capitaine Train. As a consequence, I think a disclaimer is needed here: I work for Capitaine Train, but the opinions expressed on my blog or anywhere else (Twitter, Google+, etc.), are my own, and have nothing to do with my employer.

In the past few months, I have been working on developing an Android application from the ground up. This app named after the name of the company, Capitaine Train, can be downloaded on the Google Play Store. Capitaine Train - which can literally be translated as “Captain Train” in English - is a 3-year-old startup born from a simple truth: getting train tickets in Europe was a pain in the ass. We, at Capitaine Train, aim to revolutionize the way people travel all around Europe by simplifying the overall train experience. The release of the Android application clearly represented an important step forward in this direction.

Trying to revolutionize the train experience in Europe is not easy. It requires us to achieve a tremendous amount of work: getting to know the various carriers, learning about the document/reservation requirements for each of them, integrating their price/time tables, binding our servers to their systems, etc. From a user point of view all of this is the hidden, but vital, part of the iceberg. Indeed, a travel need or desire starts from a simple search request: From where? To where? When? Who? Although these questions are simple, the search step is extremely important in the booking process. This is where the trip actually begins after all! We designed the Android app keeping this essential idea in mind by simplifying every bit of the process. In this article, I would like to tell you the story behind the implementation of the search experience in the Android app and how we used animations to enrich the user experience.

Recently, I have been asked several times why I wasn’t blogging anymore. The answer to this query is quite simple: I have been both busy and lazy^^. Busy mainly because of the enormous amount of time I have spent working on, polishing and tweaking the Capitaine Train Android application. Lazy because … hmmmm well, I’m sure you’ll agree with me, it’s relaxing to be lazy from time to time!

Me not posting on my personal blog doesn’t mean I’m not active anymore. Even though I’m not publishing new articles here, I usually keep on sharing some of my thoughts on UI, UX, mobile development – or more generally on all of the topics I love discussing about – on some other web media. In this article, I would like to discuss about these web media I appreciate and use regularly.

A year ago I shared some graphic assets to help developers and designers create applications that are consistent with other map-based Android UIs. At that time, Google Maps Android API v2 didn’t exist and developers had to use the Google Maps External Library which was - I won’t mince words - so poorly implemented you had to create everything on your own (markers, info windows, etc.)…

The release of Google Maps Android API v2 has been a huge step forward regarding map rendering capabilities on Android. The new framework has suffered and still suffers from sometimes unpleasant drawbacks1. From a designer point of view, it has one main advantage over the previous framework: it is bundled with a bunch of default resources. In other words, Google Maps Android API v2 helps developers with no particular design-skills to create nice-looking maps and improve design consistency through applications.

In the past 6 months, my Android development environment has changed quite a lot. If you follow me on Google+ and/or Twitter, you may have noticed these changes reading some of my latest tips. I love talking about UI and performance but I also seriously consider tools are crucial entities in the process of developing nice and polished Android apps. In this post, I share about my experience and the tools I use everyday when coding: