Profile cover photo
Profile photo
Cyril Mottier
12,687 followers -
A curious guy always looking for new challenges.
A curious guy always looking for new challenges.

12,687 followers
About
Communities and Collections
View all
Posts

If it looks the same, it should act the same

This morning, I had a very embarrassing user experience while walking in my staircase… I was waiting for a delivery man to bring me several parcels. Because I wanted to help the delivery man, I started to go downstairs and met him at his truck. It was dark in the staircase. I obviously turned on the light by using the round button near my entrance door.

Once I was downstairs, the guy gave me some parcels and took the remaining ones. We started to go upstairs. My flat is at the third floor. While we were between the first and second floor the lights automatically turned off. Indeed, the light system turns off after a given amount of time. Both the delivery man and I were stuck in the staircase. I started to climb the stairs blindly to reach the second floor. I wanted to press the exact same button near my neighbour's entrance door. After hesitating and hitting some steps several times, I finally reached the second floor and found the button.

In order to turn on the light, I pressed the button … and a bell rang. I actually had used the doorbell. This was a very embarrassing moment as I was still in the dark with the delivery man and I may have woken up the neighbour from the second floor. After 2 or 3 minutes, my neighbour opened the door wearing a dressing grow … I actually had woken him up.

This situation is a perfect example of a real life user experience. In addition to demonstrating my staircase light system sucks (no presence detector, no subtle light indicator on buttons, etc.), it also showed me I was heavily relying on the assumption a button that looks the same would act the same regardless of the current floor. And this is completely natural. People tend to consider interactions regardless of the context/floor.

UX is not only about pixel-made interfaces. UX also exists in real life. Day-to-day experiences fuels a good UX in a product. This morning case is a perfect example of the "if it looks the same, it should act the same" rule. Make sure you follow this rule, too.
Add a comment...

Post has attachment
Yet another reason why branded launch screen suck

A few months ago, Material Design guidelines added a new section entitled "Launch screens" [0]. In this section, Google advocates how branded launch screen (aka splash screens) enhance the user experience when having a "cold" launch.

It's no secret that I've always been against branded launch[1] but clearly pushing towards placeholder UIs or previews instead[2].

What happened to me this morning is another reason why splash screen should be avoided at all costs in favour of 1) an optimised launch time and 2) a placeholder UI. Here is what happened : I was using Google Maps and looked at the help inside the app. After looking at it, I pressed [HOME] and stopped using my phone. After a few hours, I had to have a look at a place so I opened Google Maps once again, closed the restored "Help" screen and BOOM : a branded launch screen displayed for half a second … Such a painful experience :(. For the quick tests I have made, this bug also affects Google+.

[0]: https://www.google.com/design/spec/patterns/launch-screens.html
[1]: http://cyrilmottier.com/2012/05/03/splash-screens-are-evil-dont-use-them/
[2]: http://cyrilmottier.com/2013/01/23/android-app-launching-made-gorgeous/
Animated Photo
Add a comment...

Post has attachment
New "-round" resource qualifier in Android M Preview 2
 
Round screen layouts are now part of the `Configuration`[0] in Android M preview 2. In other words, this new addition introduces a shiny new "-round" resource qualifier that allow developers to have different layouts between round and rectangle screens (as you can currently do with WatchViewStub[1] for instance).

What does all of that mean? Well, if this addition makes it to the Android M release, "hacks" around WindowInsets.isRound()[2] and use of WatchViewStub will finally be over.

[0]: http://developer.android.com/reference/android/content/res/Configuration.html
[1]: http://developer.android.com/reference/android/support/wearable/view/WatchViewStub.html
[2]: http://developer.android.com/reference/android/view/WindowInsets.html#isRound()

#androiddev   #android   #gde   #article  
Photo
Add a comment...

Post has attachment
The status bar height in the Android M developer preview is changing. It is now 24dp tall in order to match Material Design quidelines (previously 25dp). From what I remember, it is also the first change in height since Android 1.0.

#AndroidDev   #Android   #gde   #blogpost  
Photo
Add a comment...

Post has attachment
While travelling to the Android Developer Days, I had plenty of time to get bored. For some reasons, I started to play with the official Android Clock app and noticed some possible improvements.

Here is my Android Clock app clinic notes: http://cyrilmottier.com/2015/05/14/the-android-clock-app-clinic/
Add a comment...

Post has attachment
Introducing a new <tag /> XML tag to attach info to Android Views

It is no secret, the Android framework has a very open, large and verbose API. It basically lets developers create everything they want as long as they have a clear idea of the final product. However, there are some cases where framework capabilities are not obvious because they are not well documented or just hidden in the verbose API. This is especially true when dealing with the Android View ecosystem. In this post I would like to discuss about how to attach information to a View.

The framework comes with several ways allowing developers to attach information to a View. Some of them have always been available while some other are relatively new. In order to better list these techniques, I have split the post in several parts. Each part relates to an API level.

Android 1.0

Being a object oriented programming language, Java has always offered an easy way to add information to an object: inheritance. The language lets developers prevent this by either making the constructor private or the class final. But because Views have been designed for inheritance, it is quite simple to extend a given class and add information. For instance, you can add information to a TextView creating a TextViewWithData which extends TextView.

Inheritance works great but has one main problem : it is not global. If you want to be able to add info to all View classes, you have to extend all of them creating a "shallow" copy of the framework classes.

Actually, Android has always allowed developers to attach/retrieve information at the View level. This is done thanks to the setTag(Object)[0] and getTag()[1] methods. Android also provides a android:tag[2] XML attribute you can use directly attach a String tag to a given View. In general, you should use findViewById(int) in order to retrieve a given View in a View hierarchy. However, there are some cases where getting a View with a particular tag can be handy. This can be done using findViewWithTag(Object)[3].

Android 1.6

API 4 introduced a new way to attach tag objects to Views. Indeed, both setTag(int, Object)[4] and a _getTag(int)[5] were introduced. The main advantage of these methods was it was possible to add several tags to a View. There are some requirements though: keys had to be a resource identifier (i.e.@+id/something). In practice, these methods were introduced to store references to child Views.

Although these methods methods looked nice it was strongly discourage to use them because the implementation was mostly leading to memory leaks. Indeed, tags were actually held in a static global pool. You can have a look at [6] and [7], and more specifically +Adam Powell comment, to better understand the issue.

Android 4.0

The internal implementation of setTag(int, Object) finally changed in Android 4.0. A switch to a non static SparseArray local to the View itself was made. In other words, starting API 14, it is now safe to use setTag(int, Object) to store references to child Views in the hierarchy.

Android 5.0

Recently, API 21 introduced a brand new way to attach information to Views straight from the XML definition of a layout. A new XML tag <tag /> were in introduced in LayoutInflater allowing us from attaching text information to the parent View. If you like deep diving into the Android source code, you can have a look at +Alan Viverette's commit[8]. Here is an example of how to use it:

values/ids.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <item format="reference" name="btn_state" type="id" />
</resources>

activity_tag.xml

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal">

    <Button
        android:id="@+id/btn_negative"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:text="@android:string/cancel">

        <tag
            android:id="@id/btn_state"
            android:value="@string/btn_state_negative"/>

    </Button>

    <Button
        android:id="@+id/btn_positive"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:text="@android:string/ok">

        <tag
            android:id="@id/btn_state"
            android:value="@string/btn_state_positive"/>

    </Button>

</LinearLayout>

The new <tag /> tag brings a new way to statically attach information to a View. It's now up to you to determine some great use cases to this new LayoutInflater-interpreted XML tag.

[0]: http://developer.android.com/reference/android/view/View.html#setTag(java.lang.Object)
[1]: http://developer.android.com/reference/android/view/View.html#getTag()
[2]: http://developer.android.com/reference/android/view/View.html#attr_android:tag
[3]: http://developer.android.com/reference/android/view/View.html#findViewWithTag(java.lang.Object)
[4]: http://developer.android.com/reference/android/view/View.html#setTag(int, java.lang.Object)
[5]: http://developer.android.com/reference/android/view/View.html#getTag(int)
[6]: https://code.google.com/p/android/issues/detail?id=18273
[7]: https://plus.google.com/u/0/+NicolasKlein/posts/2cH1tw3bCy9
[8]: https://github.com/android/platform_frameworks_base/commit/451a3417e97d9d3bb835290a65f9af30b112c789
Photo
Add a comment...

Post has shared content
Decided to spend the evening updating my floating label implementation, FloatLabelLayout, to match the Material Design spec[0].

The text growing/shrinking animation needs a bit more work but it's mostly there. I've also started using ViewCompat#animate() so that we're backwards compatible back to API v4 (although the animation will only work in API 14+).

You can find the source on GitHub: https://gist.github.com/chrisbanes/11247418

#AndroidDev   #MaterialDesign

[0]: http://www.google.com/design/spec/components/text-fields.html#text-fields-floating-labels
Animated Photo
Add a comment...

Post has attachment
A Story of Software Development Methodologies

I have been asked several times how to deal with release cycles of a mobile application. I don't think there is a perfect way to deal with such problems. I just wrote an article that describes how this is done on large Android applications project like Capitaine Train:

http://cyrilmottier.com/2014/12/09/a-story-of-software-development-methodologies/

#gde   #blogpost   #android  
Add a comment...

Post has shared content
Hmmm what to say about this great post? I think the image below is just self-explanatory :-)
Android Wear round device frame

I just published an Android Wear round device, based on +Cyril Mottier​'s Android Wear Flat Device Frame [0].
It uses the actual screen resolution (320x320 pixels) of one of the currently available round Wear devices: the LGE G Watch R.
This frame can be very useful to promote wear apps or to be used in amazing presentations.

You can download it for free (licensed under the CC BY 3.0) here: 
http://goo.gl/GaW0Yf

[0]: http://cyrilmottier.com/2014/07/31/android-wear-flat-device-frame/

#androiddev #androidwear
Photo
Add a comment...

Post has shared content
Wait while more posts are being loaded