Cool Beans

Recent rejection of the official Google Voice application from the iTunes App Store has prompted me to write something that's been grumbling in the depths of my soul. (Well, not quite that deep, but still, grumbling.)

Google has, once again in their spirit of giving paradigm-shifting technology, given away for free a telephony system called Google Voice. Basically it's a service that consolidates all your varying numbers into a single number. Not a new idea, but with things like voicemail transcription, and the long-wanted but hardly ever implemented phone blocking/screening features, I must say it's far and away one of the most useful free telephony services ever to be given to the eager public.

Android (an open mobile operating system created by Google) developers and Blackberry developers have already released applications to utilize this great system natively on supporting phones. But the question always comes up, "When is the iPhone app going to be ready?"

This is a sticking point for me. A thorn. Yes, the iPhone is unbelievably amazing. Usability of the OS alone makes it stand out as the ultimate take-everywhere device. If I am not at my computer, I am probably holding my iPhone if not thinking about holding it. It is undeniably a market leader, the standard by which all are compared.

But there's the despised side to Apple. It's their controlling side. They've played it well by having super-secret product development, generating buzz and causing a frenzied cult following for anything latest-greatest to come out of their Chinese factories. They've kept their design elements uniform, and their development environments very well-integrated; they've controlled their features by constantly simplifying, doing away with the superfluous (what they deem superfluous) and forcing users to realize that they don't need things like LPT ports, PCMCIA slots, and Firewire 400. And so with these undemocratic decisions, still keeping a pulse on usability design somehow, they've managed to provide us with products we admire and covet, even to the point of forsaking features we used to really like.

This, of course, has nothing to do with Google Voice, which merely hopes to give you free calls and better services than AT&T, but Apple has pulled the plug on any apps that use this service, citing duplicated features, and arbitrarily rejecting something we all could really (and do want to) use on our take-everywhere device.

It's really time for Nokia and Android to step up. I wanted to write a more comparative post about the pros and cons of developing on each platform. Having hammered out code in each environment, I've come to appreciate and dislike some things about each. But with this latest F-U from Apple, I'm just going to get to the gist of competitors:

• Android needs to fix its garbage collection so the performance doesn't suck so much.
• Android needs a UI guru.
  

I mean, it's a great system. A pleasure to write in (albeit a bit legacy Java-like), and best of all, it's so free! And I don't mean let's go download it for free, free-- but free as in code what you like free. With some terms-of-service exceptions Android development involves no App Store bonehead who is going to axe your months-of-labor baby because it competes with their existing official app or irks the carrier. As for UI, let's face it. If I'm dragging a tab with my finger, and it freezes for a half-second, then jumps and makes me select something else accidentally, that's just plain annoying. Annoying to the point of not wanting to use the phone anymore. It's that much of a deal-breaker.

So no matter how great the OS is, if it doesn't perform in a usable way, it will ultimately be set down in favor of what Just Works™.

• Nokia needs to quit meandering in J2ME and linux wannabe obscurity (and S60 inaccessibility), set out some  welcoming development tools and, once again, design awesome usability.

Thing about Nokia S60 (and Win) development is you have no real crazed following of "for fun" side-project-turned-startup developers. I try to find programming resources in these areas, and they don't hold up a candle to the deluge of iPhone-- and now Android-- dev resources. User groups are easy to find in those other non-Nokia platforms, too.

Nokia and Blackberry’s hardware and carrier focus has thus far led to lack of investment/interest/capability in software SDK design & developer support.

Diesel McFadden in response to an article by Christine Gonzalez

Inaccessibility, and developer pain, are not a ways to build a kickass mobile OS. I'd really like to see this major mobile player kick developer-friendliness up a few notches and quit being so arcane.

The more Apple does stuff like this, the more it is a loud call, a superb opportunity, for other competing OS providers to come up with a superior user experience and draw more into their fold. What better way to create a following than to have thousands of determined coders evangelizing for the greatness and intuitive ease-of-use of your products.

Apple can also see this as an opportunity to lighten up, and to let people have what they want even if it doesn't agree with Apple superiority. But I have a feeling that might be asking too much.

As programmers or service providers, our lifeblood is our customers. Well, duh! you may say. Yet many a (young) programmer would like to think they could just code away at their desks creating elegant and properly formatted perfection, avoiding "useless meetings," and being largely abstinent of the business side of things.

But what happens when things fail? Fail massively? What happens when our front-line support staff are forced to face the music as dozens, if not thousands, of customers start calling in? How do you manage an audience that is starting to share horrible things about your products?

It's bound to happen... Are you prepared for it?

I was recently reading an article by HighTechDad about the do's and don'ts of customer service. HTD is well-versed in this area, having run Customer Service departments in the past. He shares some experiences and provides many tips about keeping your cool and getting to resolution from the customer or company perspective, e.g.:

• Offer solutions
• Try to go beyond the expected
• Don’t let the customer know that you are frustrated
• Be friendly and conversational
• Try to connect at some level with the customer (e.g., if you know their location, ask about it)

In this day and age, you don't want people walking away from your service reps feeling deprived or ignored. Especially since there's the added vector of complaint when your socially-networked customers instantaneously broadcast their pain and suffering to hundreds of friends, family, coworkers, business contacts, Twitter followers, and blog readers.

Many companies dread the periods of high support traffic and view it in the "lock down" mentality; a mindset of merely dealing with damage control. Service representatives are trained to tell frustrated and/or impatient people that: Yes, we know there's a problem, we don't know exactly what happened, we don't know yet when it will be fixed, and we are sorry for the inconvenience. Customers who deal with "enterprise vendors" in particular are almost used to the abuse and don't expect much from a submitting a trouble ticket. I believe people on all levels, from the coder in the trenches, to the person who has to answer the phones, can go beyond what is expected to help retain customers and let them know they keep us alive.

The difference between how a company treats us when they make a mistake can be the ultimate in loyalty building (or destroying). A mistake handled well might makes us more loyal customers than we would have been had we never experienced a service problem. Remember this with your customers when you make mistakes on the job.

- Chad Fowler, The Passionate Programmer

From the end-user point of view, nothing sucks more than having a valued service suddenly fail to perform at the minimum acceptable level. Even retail purchased items that were once prized possessions (before they broke) cause us much disappointment when they fail to do their function. If I paid hard-earned money for it, it better perform. We've all been there: High elated expectations come crashing down as we realize, "What? It doesn't work? Why? What alternatives do I have? Do I really want to stick with this and try to get it fixed? Can I refund it? Nooo, can't it just work! Aaagh, why's life so hard?"

A Good Bad Good Customer Service Experience

Recently I visited a well-reviewed winery called Darioush. This was about 2 wineries into a trip, so I had already sampled and enjoyed a bit of Napa Valley to this point. But what wines I thought were good were far and away superseded by the ones at Darioush. I had no problems handing over $80 for a bottle of wine that I absolute had to take home with me.

You might be thinking, "Who cares? I thought this was about customer service! Why are you talking about your dumb yuppie-wannabe wine trip?" Well, let me get to that.

Once I got home, I unpackaged the wine to admire its serene bottled beauty. But then I noticed a little purple residue in the cork wrapper. I knew immediately this meant the cork was leaking, which meant the wine was probably bad. From high to low. What to do? Such an insignificant single item in the grand scheme of wine production. Dejected, I went to their website sent them a note about my discovery. For a few seconds I considered driving the 40 miles the next weekend to exchange it in person, but in the end I resigned myself to $80 down the tubes. Sigh.

The next day I got a call from a number I didn't know. The person on the other line asked for me by name and was suddenly apologetic about my experience with my wine purchase. Without even questioning the nature of the problem, she was ready to send me a replacement bottle immediately, and only needed to verify my original purchase and get my shipping address. Wow, just like that, they want me to be happy with their product. They've gained a loyal customer in me.

Then I waited a week and a half.

Bad. What happened to my shiny customer service impression? It faded into mild acceptance. I felt like I was duped, like a yes-man (or woman in this case) told me what I wanted to hear then left me in the paperwork. "Immediately" was not really so much. Once again let down, I counted it a loss and sent another short message via their website.

The following day I got a FedEx tracking number originating from Napa. No call, no reply.

They followed through on their promise, albeit with a little reminder. This, coupled with a great product, was good enough for me. I can still share the story about how they went beyond initial expectations to keep me happy, but the story is not as punchy as it could have been. They have, my loyalty, retained.

Moral of the story? If you're the customer, don't come to the table feeling entitled; manage your own expectations. For the service representative: Be honest and receptive (even if it's bad news) and be ready for your product to fail. You never know who's socially networked and waiting to share. Do whatever you can to transform the mistake or problem into a chance to build loyalty, and, perhaps most important of all, follow through on your promises.

--
* This article title I got from Chad Fowler's book referenced in the quote. Please read this book if you're in any sense working with code, it has some fantastic advice.

We lament the loss of material things, and try to honor the "old ways" that were more tangible and harder to erase. The digital age comes with it a seeming cheapening of these pieces of information in that they are so easily lost, hidden, stored away, and forgotten. And yet, the digital age is much more like life in a way. It is transient, so easily lost, so temporary and temporal. Death is constant with digital media. There is no lasting, there is no permanence. Everything is in transition, and in almost inconceivable bits and bytes that can be wiped with a misdirected EM pulse, corrupted NAND module, or disk platter failure.

Death is merely transition. How attached we are to the old state, is how heavily we feel the sense of loss. But digital (computer) media is always bound for transition and nothing is guaranteed. In this sense it is very much like life, like reality. And much less an illusion than the "old ways" of information storage that we romanticize.

It's been known for some time now that OSX has a pretty bad Java bug that could allow an applet to run commands as the user. This issue is also known as CVE-2008-5353 and puts Mac users at serious risk of getting owned simply by visiting a website. Sun fixed this issue in a patch released in early December 2008-- that's more than six months ago as of this writing. I was almost starting to think up a conspiracy theory that Apple needed the vulnerability for something, but then I found that Brian Krebs of the Washington Post reported on the gaps between Sun's fixes and Apple's updates: an average of 166 days.

This big Java never-fix hole got a lot of press around May 19-22. It even motivated me to dig around Apple's feedback site and ask them to please fix it asap. Nearly a month later, nothing. Even with the release of the impressive and sleek Safari 4, the issue persists.

Remediating the Issue

Note: As of 6/16/2009, Apple released a Java update that addressed the purpose of this article.
The steps below are being left for posterity, but to fix, simply choose "Software Update" from your Apple menu.

One can do the widely publicized work-around: Turn off Java in your browser. In your browser Preferences there will be a checkbox "Enable Java" which we are told to simply un-check. I find this to be somewhat ridiculous. If we were asked to turn off Flash, there would be an Internet revolt. Disabling an entire application platform, to me, is not a suitable interim solution. This would be especially true for people who use services like Wuala, Hushmail's java-based authentication, or products like MindTerm's ssh applet.

So I went for a surgical method.

All credit for this one goes to Marc Schoenefeld of illegalaccess.org. I'd just stop at linking the site from here but I think there are a few other details worth mentioning about his published solution. Basically, the goal is to create some classpath trickery by compiling your own Calendar class and putting it before the bad one included in OSX's java library.

Let me go through illegalaccess.org's steps:

1. Find a non-OSX version of JDK 1.5.0_19, like the linux version.
• This was surprisingly difficult on java.sun.com. Apparently Sun doesn't want you to use it anymore. License agreements, End-of-Life notices, and finally a .bin file that I couldn't open in OSX, and had to bother my friend with an Ubuntu laptop to run and extract for me.


2. Open a Terminal. Locate and extract src.zip and find

   java/util/Calendar.java

• Be sure to stay in that "root" source directory where you can see:

  java/

3. Compile the class via command-line using:

• javac java/util/Calendar.java

• Several compilation warnings, but they can be ignored.


4. Create a new jar using:

• zip /chosen/path/FixedCalendar.jar java/util/Calendar*.class

• I decided to use

  /Users/username/lib/FixedCalendar.jar

  as the place where this patch jar file would reside.


5. Edit ~/Library/Caches/Java/deployment.properties 
• Set:

  deployment.javapi.jre.1.5.0.args=-Xbootclasspath/p:/chosen/path/FixedCalendar.jar

• Yes, keep the

  p:

  in there. That threw me off, but it should be there.

Google's Dan Morrill discusses Android 1.5

This meetup talk given by Dan Morrill of Google Developer Relations includes upcoming Android features for "Cupcake" 1.5, some code demos showing Dalvik VM versus native development benchmarks, and a few of Dan's favorite apps.

Admittedly, it's difficult to follow the technical parts of this talk in an audio recording only; especially as Dan modifies code and demos the k-means clustering application. But there are several fascinating knowledge gems about this rapidly-growing mobile OS.

Broken up in three parts as usual:

• Intro and announcements - 8.3MB, 9:03 minutes.
• Android 1.5 - 45.4MB, 49:36 minutes.
• Q&A session - 10.5MB, 11:26 minutes.

09 I/O splash screen

When Google VP of Engineering Vic Gundotra announced at the Day 1 keynote that attendees of Google I/O would all receive a free Android developer phone, the room of thousands went into an uproar of applause. I arrived late, so I was all the way in the back catching the tail end of the keynote. But wow did I catch the good part! Free unlocked developer phones? No way!

Since laying my hands on the phone, I managed to stay excited about it even almost two weeks later. What a way to get developers into coding for this relatively new mobile OS.

Having previously developed on Symbian S60, dabbled in QT, and a former member of the technical demo teams of the ACCESS Linux Platform, I settled on the iPhone's superior user experience; and basically surrendered any hope that competing mobile operating systems would be able to take a major hold in the market.

Even when Android SDK 1.0 was launched last September (2008), my reaction was "neato" but with a small degree of skepticism: "Yet another Linux-based mobile operating system by some consortium of vendors." Fast forward to today. It took Oprah-like generosity, an open SDK, and a very cool little phone for me to see how engaging it could be to develop on Android. I will delve into programming in another post. For now, let me talk about a few key hardware differences straight out:

The HTC Google Ion "G2" vs. iPhone

Media Player:

Google Ion and 1st Gen iPhone

The Google Ion, a.k.a. the HTC Magic, is definitely not (yet) a media player competitor. The included demo songs sounded horrible (both from a personal choice perspective, and in overall quality) so I deleted them and went to my own library. I loaded up some of my finest Amazon MP3s and was shocked to hear so many sound artifacts and the same loss of resolution (despite the high quality source of these music files). I should backtrack and mention that I listened via the USB-to-headphone adapter, which might the culprit. There is no headphone jack on this device. If I hadn't known any better I would have thought the MP3s were recorded on a voice-recorder using space-conserving settings. The player is likewise rudimentary, nothing at all like an iPod experience. I am almost certain this aspect of the OS will improve with upcoming phones/Android releases.

Video and Camera:

The Ion can record video (a plus) but playback is a crude 3-button interface. At least I'm primed and ready now to do my own cell-phone videos, something I've always wanted for my iPwn. However, you can only email the latest recorded video, and must copy off the microSD card to share any other previous videos (that's gotta be an easy bug to fix).

The 3.2MP pinhole camera auto-focuses. Decent for street documentary, I'd say. The auto-focus feature enables easy use of another favorite: The bar code reader. Using Compare Everywhere I am able to scan up a shopping list of books each time I go to Barnes & Noble.

Standby Time:

Battery life is really lacking on the HTC. Moderate usage with 3G enabled, wifi on, Bluetooth, and GPS will give you less than a full day (24hrs) of life before it needs to be plugged back in to the USB power supply. Forum posts blame background multiple processes (typically runaway apps). I have, several times now, had an app get stuck; then the battery would get really warm as it churned up CPU. I tried an app called Advanced Task Manager to possibly "kill -9" runaways like this, but no such luck. Only a full power-cycle was able to stop them.

Soft keypad:

I was really expecting a pop-out keyboard like the G1. The touchscreen keypad is comparable, but come on, how hard can it be to allow us to use Bluetooth HID profiles? I want to use my fold-out Bluetooth keyboard!

Trackball:

There's a little Blackberry-Pearl-like rollerball by the bottom buttons. I don't use it much, but one colleague explained it's best for moving the cursor around when editing text. Seems superfluous.

Phone calls:

This is what the phone is for, right? Call quality was fine, but being accustomed to the multi-tasking phone features of the iPhone, the HTC was disconcerting. When on a call, the screen just blanks after a few seconds. Even when the caller hangs up, the phone does nothing. You have to remember to press a button to call up any menu (like the dialpad or to hang up).

The Network:

The HTC doesn't have the right radio for other 3G netoworks, so if you like 3G you're stuck with T-Mobile. It is unlocked, though, so in theory it's compatible with any GSM network. I've tested it on AT&T EDGE with no problems. You can guess which phone I'd take with me when traveling, especially out of country.

Conclusion:

All in all, it is somewhat obvious this is a developer-focused phone. Both the hardware and the UX need some polishing, but it's lot sleeker and cool than the G1. I don't know if it's just my SDK excitement or the newness factor of being handed a free phone... my 1st gen iPhone is currently powered-off and calls are forwarded to the Ion. This is the first time I've honestly considered switching away from the iPhone. The HTC Ion with Android is very welcoming. If you're into programming at all, the barrier to entry is quite low.

Pick a Path

This month (June 2009) is a very exciting month in the mobile industry. There are several local events-- Google I/O, Palm Pre webOS launch, and WWDC --that are really shaking the way we think of mobile applications. Whereas before I thought the iPhone blew everyone out of the water, the gap is closing fast. Do I learn ObjectiveC and join a rabid app market? Do I jump into an open community of Google Android developers? What about webOS and the rave reviews that the new Pre UI is receiving? We are at a crossroad, and for programmers there are many new paths to explore.

Loic Le Meur of Seesmic

Went to a meetup (StartupSF) with a wise guest speaker, Loic Le Meur, founder and organizer of LeWeb Paris and CEO of Seesmic.

I am glad I recorded the talk because it was filled with insightful and contrarian views to competitors, reacting to negative feedback, and determining product features.

Have a listen.

• StartupSF Introduction - 11.1MB, 12:06 minutes
• How to Launch a Product with your Community - 32.1MB, 35:03 minutes. Update: 6/9/2009 view Loic's slides that Slideshare sync'd to this recording here.
  
• How to Launch a Product with your Community, Q&A - 41.1MB, 44:52 minutes.