Beyond Material Design

Material Design has been around for a while now. Over the past three years and a half, we’ve seen a tremendous evolution in the way mobile apps are designed. Many communities have been created around this new design language. Even a large number of websites have taken inspiration from it. Google is also making regular changes to the specification, keeping it adapted to current app usage.

 

Why is it so popular?

Google already had a design language for Android before Material Design: Holo. It wasn’t as complete, but still was an excellent start for all app creators. In my opinion, the main difference between these two, what explains why MD is so popular, is how Google is pushing it. Holo was made for Android. MD has been created for all platforms, so now, all Google products users see it, even on iOS. And they talk a lot about it.

 

But now all apps look the same!

Really, do they? The goal of a design language system (DLS) like Material Design is to offer a framework for designers, so they can build their content on a solid foundation. But that’s what MD is, just a foundation. Design goes beyond that.

Now, of course, most developers aren’t designers. That’s a whole different job. And not all of us work with design teams. Devs tend to strictly follow the specifications, and don’t go beyond it. That’s how we end up with a lot of apps which aren’t very imaginative design-wise.

So what? Is that a real issue? I don’t think so. Would you rather go back to the pre-holo time? Before MD, most app developers I knew didn’t use margins for their layout. Now, they do. Developers use cards, FABs, colors!

Do these things are misused? Yes. Do developers, designers and companies sometimes create monsters? Yes. Is MD often mistreated, tortured, deformed? Yes. But again, it’s way better than it was before. Design has made it to the world of app developers. For good.

 

But this kills designers’ creativity!

It can, but I don’t think it happens that often, especially if you’re aware of what a DLS is about. As pointed out in this article from Hayden Bleasel,

“Good design systems are catalysts for consistency, not an immutable list of commandments.”.

I think it’s a pretty good summary. What it brings is a way to help designers building a coherent product experience across features and platforms. Then, designers can use these blocks to build something truly unique, but still consistent. Honestly, just look at all the amazing creations uploaded daily on UpLabs, and look back at Android 2.x apps. Do you think creativity has been killed here?

 

Is Material Design going to be there forever?

Probably not. It’s going to get old at some point, probably sooner than later. But what’s very interesting with MD is that it continues to evolve, while still respecting its core principles. Cards, drawers, FABs, all of this can disappear. As long as the core rules are applied, it’s still Material Design, just like Apple human guidelines are still human guidelines, flat design or not.

Share Button

Android Makers 2017

Last month I was in Paris for the 1st edition of Android Makers, a brand new conference about mobile apps. Organized by the same guys who made the Droidcon Paris, it was two amazing days of talks about Android, with speakers from all around the world.

I was lucky enough to do a talk about mobile app design, and all the though situations you can meet when you’re creating an app for someone else. Here’s the video (in French):

 

 

You can also read the slides on Slideshare (even if it might not be really complete without the stories told in the talk):

 

And to show you how cool was Android Makers, here’s my top 3 from the conference:

 

 

The Fabulous Journey to Material Design Award by Taylor Ling

In this talk, Taylor Ling explained us the key principles he used to design Fabulous, an extraordinary app that won a Material Design award last year. Probably one of the best talk I’ve seen in years.

 

 

The ART of organizing resources by Jeroen Mols

Here Jeroen Mols explains us the conventions he uses to name his resources. We were nicely surprised to see that we were basically doing the same things at iD.apps. So we’re probably doing it the right way :).

 

 

Android Things for IoT by Wayne Piekarski

Wayne Piekarski from Google was here to show us some of the cool stuff you can do with Android Things. Honestly, watch the talk. Now I want to IOT all the things!

 

In the end it was a great event. I can’t wait to come back next year!

 

 

Share Button

True Colours, or the quest of comparing two colors

Introduction

I’ve started a few months ago to work on an application called Eternal Minis. It’s a social network where warmongers can share their painted miniatures. If you don’t understand what I’m talking about, check out Wikipedia.

Anyway, the app allows users to add paints they’ve used to a posted minis. It’s a very interesting information if you want to learn how someone has painted a specific color effect. However, it can be a bit tedious to add all the colors you’ve used, especially when there are dozens of them! My idea was to help the user by suggesting the first color. Maybe it’d help him start, and he’ll keep adding other paints after that.

 

Color distance

My first idea was to vectorize the RGB components of a color picked on the photo (using Palette), and then make a distance calculation between this color and the predefined paints included in the app. Even if it may sound like a good idea, a short distance between RGB components might not be really relevant.

So I started to search for some actual color comparison algorithms. What I found is that you can calculate an Euclidian distance between two colors, from actually any format. So you can do the following with RGB components.

An Euclidian formula with 3 dimensions, courtesy of Wikipedia
An Euclidian formula with 3 dimensions, courtesy of Wikipedia

 

However, RGB components, even if they’re great for computers, may not be very relevant for how humans perceive colors. Actually, if you take a look at the Wikipedia article on Color difference, you can read about the work of International Commission on Illumination (CIE). the CIE76 formula for color distance looks like this:

Looks familiar, right?
Looks familiar, right?

You’ll notice that the color components are called L, a and b. It’s because the CIE colors are defined with the Lab color space, which is trying to approximate how humans perceive colors.

So we can easily convert RGB colors to the Lab space, and then use the Euclidian distance to find a relevant color from a mini picture!

 

Make the robots working!

As an Android developer, the good news is: Google has already made all the heavy stuff. The ColorUtils class has a method RGBToLAB (which returns an array with Lab components), and a distanceEuclidian method has well.

So, all you have to do is to pick a color using Palette, and make the comparison with ColorUtils.

What I actually do in Eternal Minis is loop over all vibrant colors in all swatches, and then keep the color with the lowest distance to any paint color included in the app. Then I suggest the user to add the found paint. And here’s the result:

Final result
The final result

 

So what’s next?

The approximation works fairly well, but there are a lot of things to consider outside the color comparison. Photos are often taken with a white or black background, so you don’t want to suggest this color to your user for example. So there is still a lot of work to ease the life of painters!

Share Button

Google I/O: I was here

Even if I haven’t posted about it (except if you follow me on Twitter), I was at Google I/O this year, thanks to my company. And it was awesome, as you can expect. I’ve met a lot of people, see some great conferences, and I’ve came back with tons of new ideas.

I’m especially pleased with their work on Firebase (except for this annoying push notification bug). And I really want to try Google Home (who wouldn’t?).

Here is the top 5 of the conferences I’ve seen. Enjoy!

You also have to see this one. It’s not your usual I/O conference. You’ll thank me 🙂

Share Button

How Realm has reconciliated me with mobile databases

Realms of Chaos

I’ve been developing Android apps for few years now, and even if I’m a huge fan of what the platform offers to developers, one thing has always bothered me: Databases.

I come from the web world, where you have very powerful ORMs (like Hibernate, Entity Framework…). And when you arrive to Android, what you have is… SQLite. Hard to use, painful to work with… It’s such a mess that I’ve avoided it as much as possible. Then came ORMs for Android, like ORMLite, GreenDAO, ActiveAndroid…

I had the occasion to work with most of them, and even if some are better than others, globally, they’re really, really not efficient enough. At least in my opinion. Models generation, data migrations, APIs… Most of these things are hard to work with when it comes to Android ORMs.

Here comes Realm

Then came Realm. A promising database with a nice APIs and a SQLite-like performance (or even better). It’s actually a whole new DBMS, written in C++, and available on iOS (Swif/Objective C) and Android. Besides being really fast, Realm offers an API so nice it reminds me my good old Entity Framework.

They present their product better than me, so go visit heir website: http://realm.io

It’s pretty easy to setup, and you can start making your entities in a minute. And if you doubt about speed, know that not so long ago, your data manipulation and reading had to be done on the same thread. But from what I’ve experienced, it had no major performance impact (and Joaquim Verges, creator of Falcon Pro, has the same conclusion: https://realm.io/news/joaquim-verges-making-falcon-pro-3/). Don’t worry, if you still want to read data in a background thread and display them in the UI thread (which is probably a good idea, or an absolute requirement, depending on how you see things), Realm is now offering async methods for data manipulation!

Why is it so great?

Even if Realm has been around for several years, I haven’t tried it until recently (even if I was keeping an eye on it). After all, the Android version hasn’t reached the 1.0 version!

I’ve started to use it on Condor, a Twitter client app I’ve made last summer, and to be honest, I was impressed. Since then, I’ve used it on Astonishing Comic Reader, powering some very, very huge collections of books, without any problem. And I’m basically planning to add it to use it in all my future projects.

So it’s just the most perfect library in the world?
Actually not. It has some flaws. After all, it’s still in beta.
The brand new async methods seems not that stable, at least for now ( One of my colleagues had a severe bug which stucked him for a day or so). Some parts are also a bit tedious to use, like the Realm migration API. It’s changed recently, and it’s much better, but I feel like there’s still room for improvement. But anyway, I still consider it’s one of the best libraries you can find on Android.

What are you waiting for?

Seriously, go try it. Copy/paste the Gradle dependency line, and start to play with those RealmObject. I’m sure you’ll be quickly convinced!

Share Button