Posterous theme by Cory Watilo

Thoughts, early 21st century

Filed under: idea

Android phones used as a computer interface

As far as I know, there isn't much interaction between smart phones and computers today. They are mostly used as two independent devices. I can access the files in my phone from my PC, sync contacts and music, but not much more.
When I'm in front of my computer I usually have my phone plugged into it. This phone can detect acceleration and has a hi-res touch screen. Why not use the phone to augment the computer?
It would be great if my laptop could read all phone sensors in real time. Then it could be used as a game controller. A mouse in one hand, and my phone in the other. I could tilt it, touch the screen and even see information about the game in my phone's display. Maybe it would be even possible to use the phone for aiming, using the phone camera to track objects in my computer's screen (registration points).
But as I don't play much, I'm more interested in productivity than in games. I'd like to use the phone's display as an external display for my laptop. For instance the Gimp's toolbar or a color selector could be shown in my phone, leaving more free pixels in my laptops display. As I'm working with my Wacom tablet on my right hand, I'd like to use my left hand tilting the phone to control color, opacity or brush width. If I'm creating music, I'd like to tilt the phone to control the filter frequency or the amount of effect in a certain audio track. If latency is low enough it would be a much better interface than a mouse and a keyboard, something that could complement other MIDI controllers.
I think there are some experiments in this direction, but if Google (or someone else) added the required APIs and libraries to Android it would become much easier to experiment in this field. Hopefully some developers and artists find this concept interesting enough to work on it.

Make the web faster - zip it

In mid 90s I realized most Flash swf files could be compressed using zip. The resulting file would often be 50% smaller. I sent this suggestion to Macromedia, and I was very happy when the next version of the SWF file format came out, it included LZW compression.

Google has an initiative to make the web faster. They just proposed a new lossy image file format. I was just wondering if something like what SWF does could be also used for HTML. Imagine you pack all your JavaScript, CSS and smaller images inside a resource.zip file. Later, you would target each file inside this zip file like:

<link rel='stylesheet' href='resource.zip?file=/mystyle.css' type='text/css' />
<script type='text/javascript' src='resource.zip?file=/jquery.js'></script>
<img src="resource.zip?file=/images/blank.gif" />

This way the browser could download all the resources with just one request. Compare this to many complex sites that make over one hundred requests to the server. CSS sprites would be something from the past.

There are some drawbacks: linking to compressed resources in other domains wouldn't be as easy as today, and crawling by search engines would require decompressing the file first. Uploading asset groups by FTP would also be faster, but then updating a single file would require uploading the complete compressed asset file.

In any case the speed increase would probably be very noticeable if web sites downloaded most of their assets on one request, instead of making hundreds of them.