With the latest iteration of Android, Google refined some little details. No big changes, but a lot of new small modifications that matter. In a previous experiment I wondered how could time widgets be improved.
In Android KitKat, Matias Duarte’s team finally changed the way the clock widget works. Instead of having a wheel and selecting hours digit, then minutes, and waiting for the wheel to stop, you may now directly move the clock hand. This is a huge improvement! For more precision you may still type the exact time yourself of course.
This new widget is accessible by the Clock application as well as input events of type time.
Another detail that’s found into Android is the ability to have fullscreen desktop and applications. Applications that take advantage of this new mode can now take the whole space of the screen: the OS application and navigation buttons will then fade away: giving an impression of bigger screen.
While this is a good thing for some screens, this gives quite a mess when text appears below the navigation buttons. Here is an example of the Talon Twitter client:
While playing with various mobile (touch-enabled) OS I noticed that all were using the very same widget for setting time.
Here is the one used in iOS:
… and the one used in the latest Android (ICS):
They both share the same usage: you have to scroll to choose your number. The problem is that it may take some time before reaching the correct number. Not to mention you may go to fast and skip it.
What about having a true analog clock and being able to move the clock hand ?
Here is a little clock widget in which you may use directly move the hand to set the time.
Just for the fun this is made of CSS only so it can easily scale across different devices. This should work with any touch-enabled devices as well as traditional mouse-driven devices. Microsoft-specific touch events aren’t support right now.
Today’s browsers have very fast rendering engines: the above image is made of 26.000 different box-shadow. No canvas, no embeded image. And this is rendered instantly on today’s computers and take only a few seconds to render on my quite old Omnia 7 phone.
Zooming seems to trigger a chrome bug though.
Demo: hacking with box-shadow
While adding MS CSS prefixes to 500 photos slideshow, I noticed something was making the transitions blink. With some more tests I found out this was related to CSS transtions. It seems IE 10 (consumer preview) has a little bug which causes opacity to be reset to 0 when CSS transforms are applied.
Here is a simple box with opacity set to 1:
-ms-transition-property: opacity, -ms-transform;
Adding the hidden class is supposed to fading to 0 as well as applying a little rotation. This seems to work as expected except that when the transition is over, the box appears, as if opacity was (incorrectly) reset to 1.
A quick and easy way to fix it is to set the opacity to a very low value, like 0.01.
Demo: bug proof
Edit: good news, bug has been fixed in Windows 8 release preview!
Here is a little slideshow I did to see what could be done with the 500px API. I wanted to see how CSS 3 could be used to minimize server load so not a single picture (except those coming from 500px of course) is used inside this application.
While working on IE 10 support I stumbled upon this opacity bug as well.
Demo: 500 photos