I now have a “Unique custom Google+ URL”.
In my circles: 34 people — means they give these URLs to pretty much anyone
I’ve been asked several times to implement the oh-so-popular navigation drawer for folder selection in AquaMail, replacing the old-fashioned drop-down list.
The technical part is easy, but the more I get into it, the more it seems like a bad idea. Here is why.
TL;DR – I’m happy for the young energetic designers who are making a career out of “inventing imaginative ways to improve mobile device navigation patterns”, but there are significant drawbacks which may outweigh the claimed benefits.
1 – I’m faced with the decision of whether I should keep the drop-down or not.
Having two entirely different UI elements that do same thing (let the user directly navigate between folders) is strange, putting it mildly.
Let’s look at the options:
- Remove the drop-down entirely and keep just the drawer.
This is bad for users who are not experts on Android UI patterns. Yes, the drawer indicator is there (the three tiny horizontal stripes to the left of the app’s icon), but… Sometimes I get emails asking how to access the menu, and there are users who barely know about the Back button. Nothing wrong with these people, they’re just not experts on technology or UI, and I’d rather not make the app more confusing to them.
- Remove the drop-down, make the folder name (where the drop-down is currently anchored) another way to open and close the drawer. The native Gmail app does this.
The issue is how to make it obvious that this is how things work? The drop-down is easy to see and understand because it has a little triangle bottom right, like all other drop-downs everywhere else.
Keeping the triangle makes the UI immediately inconsistent: it looks like a drop-down, but when tapped, it does something else (opens the side navigation drawer).
Removing the triangle is even worse (the native Gmail does this): now there is no visual clue that this is not just a piece of text, but an active UI element.
This last issue is now very common in Android and becomes more and more common. Personally, as a user, I find it confusing like hell. It used to be that buttons looked like buttons, lists looked like lists, etc. – now UI elements that “do stuff” no longer look like anything, they’re just areas the user is supposed to tap (or slide? which way? or long press?), and the only way to find out is to use mind-reading skills.
2 – The navigation drawer is anatomically wrong.
It forces the thumb to move sideways (left to right) which is awkward in the first place, and then, when it’s almost touching the palm, the thumb has to move vertically to select from the now open navigation drawer’s list.
Really, if you’re reading this, try it yourself and pay attention to how your thumb’s muscles tighten when it’s bent and closest to the index finger. It’s at this point that the navigation drawer requires the thumb to start moving up and down to pick from the list.
Furthermore, a drop-down list can extend the entire width of the screen (or close to it), so the thumb does not have to move left much at all. A navigation drawer, by convention, is anchored on the left, and is more narrow than the screen (the shadow effect). Reaching sideways to the left is hard, especially on large screen devices. Reaching up is easier: the phone can shifted in the hand, up and down; but this does not work for reaching to the left.
3 – The navigation drawer doesn’t achieve what it’s supposed to.
Ostensibly, the motivation (or one of) is better usability on large screen devices, the explanation being that a drop-down anchored in the action bar is difficult to reach.
However, a side drawer also has a list, of same items, and it’s natural to start them at the top (unless you have some UI element that can go first, just to take up space… see the Google+ app, it’s the profile photo).
Let’s see, we wanted to get away from a list that starts near the top, and we ended up with a list that starts near the top, which is not any easier to reach, and which puts additional stress on the thumb’s muscles.
4 – How do other app do it?
My favorite type of question (why isn’t Mr. Obama any good at Judo?)
The native Gmail app sort of manages to make its navigation drawer more usable by moving action bar icons to the top, which in turn pushes the drawer’s activation area (the current folder’s name) to the left.
But at what price?
Android 4.0 introduced a way to put action bar icons along the bottom on “narrow screen devices”, i.e. phones. This is a great feature, making frequently used actions easier to reach (better location; a larger number of icons showing at the same time).
Now Gmail’s way of implementing the drawer puts the icons back at the top. Let’s see, the number of icons is now reduced from 4 or 5 to just 2, the rest require tapping the “three dots” icon or the hardware Menu button. And these two icons are now located — ta-da! — near the top of the screen.
In summary, “one small but very visible step forward, two giant steps back” is what Gmail’s navigation bar treatment seems to me. They made 2 or 3 commands (tasks) less accessible, to improve accessibility of 1 command (task): switching folders.
Will I keep the already-almost-implemented navigation drawer?
Really don’t know yet. Maybe I’ll add a Prada logo instead.
New version just released to Google Play.
- New feature: scan for and switch to best network (among already configured). Disabled by default, please see app settings.
- Fixed EAP (802.11x) networks on Android 4.3.
- Added a setting for “exit” button: disable WiFi or not.
- Fixed “open first” network sorting.
- An option to show detailed WiFi state in a status bar notification, off by default, see app settings.
- High res graphics for Full-HD phones (Samsung S4, HTC One, Sony Z, etc.)
More on the “best network” feature:
- Disabled by default, please enable in settings.
- Switches between already configured networks, will not connect you to some random open WiFi network on its own.
- Triggered by the firmware reporting the current network’s signal level changes, or by time. Do not expect this to be instant.
- By design, only works when the device is not sleeping. If your device does “stuff” in the background, there is a good chance the switching will work, when the device is woken by other apps.
- By design, does not interfere with the device’s automatic (firmware driven) initial connections, i.e. when there is no connection yet. Will switch a bit later if a better network is found.
current signal level at which, or below, to switch (defaults to -65 dBm, which is definitely not a very good connection, but still sort of usable);
min. interval for scans / reconnects, defaults to 5 minutes;
how good a new network’s signal level has to be, compared to the current one, for the switching to happen, defaults to +10 dBm.
Most of my time these days is taken by Aqua Mail.
Fixed compatibility of the one-tap switcher widget with Android 4.1-4.2.
Android bug report filed here: https://code.google.com/p/android/issues/detail?id=43336
Updated Portuguese translation.
Added Portuguese-Brazilian translation.
Added “sticky broadcast” permission which is not needed, but there are firmwares who think it is, and crash the app.
Does any of this ever get any testing?
When’s the final Android release coming out? I’m impressed with the 16 beta versions so far, but would like to see at least a release candidate.
I noticed today that KDE4 in Debian Testing is now at (almost) the recent version and decided to give it a try.
After doing this (and purging KDE4 from my system… again…) I returned back to my usual XFCE environment and all of a sudden fonts in Google Chrome looked ugly, different than before.
The fonts in Chrome’s window decorations (page title, bookmarks bar) were fine, it’s just the fonts in web page content that appeared without hinting. Other apps were fine too.
Checked XFCE’s font settings (I prefer to use anti-aliasing and slight hinting), switched antialiasing and hinting off and on, checked /etc/fonts, nothing helped.
Did some searching on the web, and here is the fix.
~/.fonts.conf needs to have a section at the end (marked below) that apparently doesn’t get added by XFCE’s font config applet, but is necessary for Chrome.
<?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <match target="font"> <edit mode="assign" name="rgba"> <const>rgb</const> </edit> </match> <match target="font"> <edit mode="assign" name="hinting"> <bool>true</bool> </edit> </match> <match target="font"> <edit mode="assign" name="hintstyle"> <const>hintmedium</const> </edit> </match> <match target="font"> <edit mode="assign" name="antialias"> <bool>true</bool> </edit> </match> <!-- ***** ***** The following section was missing. ***** Adding it fixed web page fonts in Chrome. ***** --> <match target="font"> <edit name="autohint" mode="assign"> <bool>true</bool> </edit> </match> </fontconfig>
- Fixes for Android 4.1.
I use internal, undocumented APIs that are not exposed via the SDK, but are used by the built-in Settings app.
The new internal APIs appeared in Android 3.0, over a year and a half ago.
Certain functions are only possible by using these internal APIs, and in addition, Android 3.2.1 (at least) contained a bug that would cause the device to lock up if a dozen or more networks were configured on the device. The issue did not occur when using the internal APIs. It’s easy to see how it might have been missed in testing — “eating your own dog food” is not just a catchy phrase, it’s a good idea, which the developers of Android don’t always follow.
The internal APIs have been fairly stable from 3.0 on to and including 4.0. It was a disappointment to me that even with the 4.0 release those APIs did not “step into the light” (did not become documented). Now in 4.1, it actually got worse – these APIs are significantly different from those in 3.0 – 4.0 (even though the basic principle on which they are built is the same — asynchronous message passing rather than synchronous binder IPC calls).
There is a comment in WifiManager.java hinting that these new APIs might be finally opened up in the next Android version (5.0? 4.2?). I’ll be glad when they are, and hope that they won’t change too much from their current state (assuming the cleanup happened just now, in 4.1).
- New, improved Czech translation.
- New Portugese translation.