Skip to content

Everyday User Experience through my car

Those small little details it makes your experience different. Most of the case you won’t notice those but it left you with good experience for using that product. Here are some of those details I noticed on my car, Acura CSX, that make my experience better.

Wiper Sensor: Living in Vancouver, rainy coastal city, I rely on my car windshield wipers quite a bit. Normally I set it to intermittent mode and adjust the speed accordingly. Here is what Acura did for me: if I am moving it is operating as I set to. But if I am stopping at traffic light or something, it slows down automatically until the car moves again. A few good things come out of this. First, it conserves energy. Second, it reduces wear and tear. Third, it does not get in your way when it is not needed. Here is one theory I have not tried yet: whether it will slow down when in fact it is raining very heavily.

Fan Speed: With my old Honda when I started the engine, it blows freezing air to my face since fan is set to certain speed. With Acura, it does not do that until engine is warm enough to actually provide warm air to heat up the cabin. Love not to get blown away by cold air when I am freezing already.

Volume Control: When you switch source on your stereo such as AUX, FM, CD, it maintains volume level set in each source. When I hookup my iPod to the stereo, I normally have to crank up the volume but I don’t really need to do that when I am on FM. I have had some bad experience with home entertainment systems that does not do this small thing.

All in all, auto industry has done a lot of research and improvements to make our daily lives better such as speed sensitive volume control, automatic wiper, automatic headlight, steering-wheel-mounted controls and etc. But most of those features are part of the advertised content. You know you are getting this feature or not when you buy the car. And I always love to find out small *good* things that are there but nobody told you about it. Who wouldn’t love (good) surprise?

Also here is something I found out recently that has been there in front of you for years. There is a small arrow beside gas pump icon in your car’s (for most of the cars’) dash telling you on which side of the car the fuel tank is. You normally won’t have problem especially with your own car, but it certainly come in handy when you are in a rental car.

Posted 31 December 2009 † Myo § Random ‡ Comments (0) ° Tagged: ,

Taking a spin of iPhone SDK & Android SDK

Holiday is upon us and this post is triggered from some free time off from work. This blog post is about my first experience on taking a spin on iPhone SDK as well as Android SDK. When I write this post, I have not dived deep into both SDK yet. But I wanted to share my first hand experience while it is warm.

Downloading & Installing: Both SDK provide an easy way to download. For iPhone you just need to download one giant installer (XCode & iPhone SDK), do the install and you are done. Even though it is over 2GB, it gives a newbies a quick jump start. One downside from iPhone, you need to register (for free) as iPhone Developer for download and additional technical resources. On the other hand for Android, you need to download Eclipse then install Android Development Tool (ADT) Plugin, and download Android SDK. Wait, it is not over yet! You need to open up SDK and download the platform (which version of Android) and link SDK (and platform) from Eclipse. I am not saying it is a complicated process. But if you are not familiar with Eclipse and its plug-in system, it is not very friendly process to get you started. Maybe Android team should consider one bundle download that includes all of those things.

Using Tutorials: Both iPhone and Android provides getting started tutorials. Android has a quick first application tutorial, simple and effective. Then it provides you with more sample code that you can download and browse around. For iPhone, it also provides a quick first application tutorial. It is a bit longer than Android’s tutorial but it gives more detail explanation about what is going on and give introduction on implementation patterns. It also has some extra tutorial that will walk you through more complicated example. Along with the sample code you can download and play around, iPhone provided much more organized and detailed technical resources over Android.

Language: It is not news that Android uses Java as its programming language and iPhone uses Objective-C as its language. Both are Object Oriented language. Aside from syntax and terminologies, the major difference is iPhone OS does not support memory management using the garbage collection feature that is in Mac OS X v10.5 and later. This is the disclaimer before I go ahead and say my next few sentences; I am a Java programmer (there are a few languages, such as ActionScript, Ruby, I use day to day) and I have very little experience with languages like C / C++. I found it much harder to read / understand Objective-C. Maybe my brain hasn’t wrapped around the syntax just yet. And what’s up with calling Protocol when you want to say Interface, or declaring as Interface when you want to declare Class. 0xCAFEBABE rule!

First Application: With Android, you can get and running your first application pretty quickly. With iPhone, it is much more complicated. There are quite a few step and things you need to do to actually get your first application. You need to understand how linking from one component to another work to fully understand how the application run. I found Android applications are straightforward and easier to understand.

Using IDE: Though I have not dug deep into XCode yet, it provides sufficient support as I would expect from an IDE. With Android basing on Eclipse JDT environment, there is not much to add. Both IDE come with the emulator for the devices. I love how you can keep on running / debugging in Android, without needing to restart your emulator. For iPhone, I love how you can push your application to the real device directly from IDE (if you have proper signed developer certificate).

Further Thoughts: Both SDK helps developer to get their job done as fast as possible. As you are familiar with language, SDK and IDE more, you should not have problem with working on either SDK. That’s what we, programmer, do. We adapt. Aside from monkeying around, everybody wants to get something in return for their time. Most of the cases, it is money. At this point, iPhone has much better chance to reward for your time. For example, someone will be less hesitate to click and buy $0.99 when they do not need to enter their credit card for the sole purpose of trying your application. Depending on your application, iPod Touch (which is relatively cheap and penetrates different market share) users could be your potential customers too. It might not fair comparison given that iPhone has over a year head start and help from the success of iTunes Music Store; But this is truth as of today.

Posted 30 December 2009 † Myo § Mobile § Technology ‡ Comments (1) ° Tagged:

Using Mixin metadata with Module gotcha

This post is not about using Mixin metadata tag. There are tons of documentation on the web to explain about usage. Here are a couple of useful links:
http://adamflater.blogspot.com/2007/03/static-code-blocks.html
http://www.adobe.com/support/documentation/en/flex/1/mixin/

In fact, this post is about to warn you about some of the examples. In short, when you use Mixin, Flex will make sure that “init” method will get call on your class when SystemManager is ready or your Module is initialized.

Here is typical signature we found on most of the examples:
public static function init(systemManager:ISystemManager):void
This works great as long as your class is not referenced from Flex module. Why? I am glad you ask. The process of calling “init” can happen from two places. One is SystemManager if your class is referenced from main application and the other one is FlexModuleFactory if your class is referenced inside a flex module. When “init” is called, either SystemManager or FlexModuleFactory passes itself as argument to the function and FlexModuleFactory never implemented ISystemManager. So, it failed. But you will never see error message because there is do-nothing-try-catch block around that call.

Lesson learned is one should use interface or parent class of both SystemManager & FlexModuleFactory, there are a few of choices for you, for example, IFlexModuleFactory, DisplayObject, Sprite and etc. For me, I stick with “Sprite” though there a few example from Adobe using “DisplayObject”.


[Mixin]
public class MixInTestDelegate {
public static function init(root:Sprite):void {
trace("I will get called in main application and module");
}
}

Posted 03 October 2009 † Myo § Adobe AIR § Adobe Flex § Technology § Tips ‡ Comments (0) ° Tagged: ,