Thursday, January 10, 2008

Google Android


When Google announed their Android platform for mobile devices, I was barely interested. As a Java developer, I was variously intrigued by their language framework which is essentially Java but not branded as such. I watched the demos and thought they were interesting but still not up to the level of the Apple iPhone. But after taking a trip to the local Verizon and AT&T stores, I changed my mind.

My wife and I have mobile phones that are over two years old. The battery in my LG-free-with-the-plan phone lasts about 20 minutes. My wife's phone is a Nokia which lasts much longer but definitely sports an outdated look. Since our original two-year contract has expired, I figured I'd look around at new phones that I could get when signing our next contract.

Talk about a disappointing experience. I looked at every phone at both the Verizon and AT&T stores. Most of the phones are flip phones (which I don't like), but beyond that, the user interfaces of these devices are unappealing. It seems that even the more expensive models share the same stodgy and difficult UIs of their lower-priced siblings. One feature I particularly wanted was a built-in mp3 player. I tried this feature on several phones and was met with difficult-to-navigate, unintuitive, and uninspiring interfaces. In the end, I liked the look of the LG Chocolate the best, but disliked the software that runs it.

I now believe that Android is positioned to be the common mobile platform of the future. Mobile phone makers can get out of the business of making phone OSes and concentrate their efforts on user experience. It really makes sense. The core competency of most mobile phone makers is making and assembling hardware. For whatever reason, they don't have the resources to design and develop and effective mobile OSes. With Android, phone makers are now able to combine their efforts to create a basic OS so that more effort can be devoted to creating a good user experience. In fact, mobile phone makers may be able to get out of the OS business altogether and rely on a third party to build the OS (some, in fact do this to some degree). The phone companies themselves can even craft their own OSes based on Android. I'm really looking forward to an Android-based phone that will (hopefully) offer an easier and more appealing user experience.

Beyond mobile phones, I think that Android could potentially become the platform for a number of small electronic devices. Think about having an Android-based thermostat or an Android-based car computer system. Thermostat manufacturers could take advantage of the developer-friendly features of Android to reduce development costs for their devices.
Car makers could base their in-car applications on Google's Android (Ford has already teamed with Microsoft to create its in-car computing platform).

There are a lot of opportunities that the open, community-based Android can bring to companies whose core competencies do not lie in developing complex operating systems. Since Android is essentially Linux underneath, Google is building on a solid tested platform. Google has the clout and resources to make Android succeed in a segment that has traditionally been dominated by smaller companies and home-spun solutions.

Tuesday, January 8, 2008

The thing I don't like about Shale Clay

I'm new to Clay, so forgive me in advance if any of these comments are said out of ignorance. Before I proceed with my gripe, I would like to say that I think Clay is pretty slick in its capabilities. Actually, I quite like Clay overall. In essence, it allows you to use 'standard' html to create dynamic web pages. When a page is served to a user, Clay replaces page content placeholders with dynamic markup. Pretty cool.

My main problem is the fact that 'standard' markup is not really standard after all. For example, to define placeholder html that should be replaced with dynamic content at runtime, you must specify a jsfid attribute inside whatever html tag you wish to make dynamic. The mere act of adding this simple attribute breaks the possibility of strictly conforming to the XHTML specification. If you run your page through a conformance check, it will obviously result in errors anywhere you use Clay-specific attributes. I also have to put up with numerous underlined warnings in my html editor telling me that the jsfid tag is 'undefined'.

Those who understand Clay and Java web development are thinking, "How else can you tag a component so that it can be replaced at runtime?" Well, you can't. And maybe that's my problem---that the XHTML spec doesn't allow extensions such that programmers can use dynamic scripting or other features without breaking strict XHTML convention.

So what's the solution? I don't really know. I guess you could say that I'd like to see the XHTML specification written in a way that both designers and developers can benefit. In the meantime, one way to mask (but not fix) the problem would be to create development tools that understand the semantics of Clay or other dynamic web technologies and toss out the warnings and errors instead of deluging the developer with them.