Topic Archive: Mobile

Four blatant iPhone usability blunders (and one constant annoyance)

Brian Dillard, Thursday, September 4, 2008 @ 12:14 pm

I've been an iPhone 3G owner for about six weeks now - six weeks of love, loathing, cool apps and connectivity problems. Rather than complain about poor network coverage, though, I'd like to delve into some of the vexing usability problems that hamper the phone's user experience.

No ability to disable autocorrect completely

Like pretty much every autocorrect feature ever built, the iPhone's does more harm than good. It always thinks it knows best. If you don't watch it like a hawk, it will render everything you type completely nonsensical. Proper nouns, abbreviations, profanity - all get turned into gibberish by this well-meaning but deeply flawed function. And god forbid you try to use the classic email e.e. cummings mode in which uppercase letters don't exist. The iPhone literally will not let you output the word "iPhone" without throwing in that capital "P." It's maddening.

If the purpose of autocorrect is to allow you to type quickly without having to monitor your output, it fails miserably. On the iPhone, if you want what you type to show up verbatim on the screen, you have to pause at the end of each word to ensure that the OS is not about to substitute its own wisdom for your actual intent. I would honestly rather type on a 1999-era StarTAC numeric keypad.

None of this would be as galling if there were a setting to turn this feature off. But there isn't. Elaborate, unwieldy workarounds have been suggested - all because Apple users know that the folks in Cupertino often paternalistically ignore their users. Microsoft's OS and apps may suck, but you can usually customize the hell out of them. Not so Apple's.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (7)

agile ajax

From the Grassy Knoll: Google Android Undermining Java ME

Dietrich Kappe, Friday, November 30, 2007 @ 10:58 am

The dudes at Java Developers Journal (JDJ, for you acronym hipsters) has always had a hard-on for conspiracies involving Microsoft and Java. "Embrace and extend" is a mantra akin to the Dalek's "Exterminate!" in their editorial corridors. Now they see a conspiracy in Google Android.

To put it bluntly, Android as it is currently defined is a fork of the Java ME platform. Android is similar to the Java ME, but it's a non-conformant implementation.  Android is not compliant with Java ME nor is it compliant with Java SE. In fact, it’s not really Java. Although it uses the Java programming language, the core APIs and the virtual machine are not consistent with the Java ME or SE platform - its a fork. This was first pointed out by Stefano Mazzocchi in his November 12th Blog entry entitled "Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME". Stefano missed the fact that Android does not properly implement the CDC or CLDC Java ME APIs ( a minimum requirement for Java ME conformance) - but kudos to him for being the first to report on the fork. The fork has since been picked up in the blogsphere by others here, here and elsewhere.

And this is a huge threat to Java ME, according to JDJ. I think the main takeaway from the article is "it's not really Java." The reasons why folks use J2EE, J2SE and J2ME are varied and don't necessarily overlap. If J2ME goes away, that won't really affect my decisions on whether to use J2EE.

Technorati Tags: ajax, android, j2me, google, microsoft, jdj

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax

ZK on Android

Dietrich Kappe, Friday, November 16, 2007 @ 5:35 am

I'm glad that my Comp Sci classes were taught differently from my Art History courses, otherwise all I would remember is the hum of the slide projector and the taste of sleep in my mouth. Instead I remember the Bridge Pattern and the wonderful things it can do for you. Specifically, you can decouple an abstract component GUI from it's concrete implementation (see AWT). This makes the task of retargeting the GUI framework to a new platform comparatively quick and easy.

Now server-side Ajax frameworks (Echo2, ZK, etc.) have been using the Bridge Pattern for a while, but with the exception of OpenLaszlo (Flash and Ajax) and WidgetServer (Ajax, Swing Applet, Swing Desktop), they only target the browser, i.e. one platform.

Now ZK Mobile, an extension of the ZK Framework for mobile devices, is showing the power of the Bridge Pattern in the mobile world. On 11/12/2007 Google released the Andriod SDK and two days later, on 11/14/2007, the ZK team released an extension to ZK Mobile that allows you to run your ZK apps on Android. How is that for quick turnaround? Good design can be good for you and good to you.

The ZK "smalltalk" demos a simple Twitter application for the Android SDK.

Amazing how little work is necessary to get this app on a mobile phone.

Technorati Tags: ajax, android, mobile, zk

• Digg
• Reddit
• del.icio.us

Comments (2)

agile ajax

ZK Integrates with Seam, Seasar, more

Dietrich Kappe, Monday, August 13, 2007 @ 5:19 am

As an open source project, ZK is extremely active. It's enough to give you a warm and fuzzy feeling if you are concerned about it's long term viability.

So, what's cooking in the ZK kitchen? Lots of integration with application frameworks and third-party libraries.

• ZK Seam allows you to integrate ZK with Seam, naturally enough. What is Seam? A framework that is the marriage of JSF and EJB3. I have to say that I've developed such a deep allergy to both EJB and JSF that their integration seems more of a nightmare than a boon. It's sort of like that movie, The Pope of Greenwich Village, a great script and good director, but it contains my two least favorite actors, Mickey Rourke (EJB) and Eric Roberts (JSF). Offers of therapy to help me get over my aversion by showing me how EJB and JSF can be "done right," are hereby politely refused.
• Integration with Seasar. What is Seasar? It is Kanji for Spring Framework. Actually, it is a dependency injection framework that resembles Spring a great deal, but claims to get you out of application context XML hell by letting you auto assemble object injection hierarchies using regular expressions and careful placement of classes in a directory structure. You can read more about Seasar here and here.
• Further addition of yui-ext components (now known as Ext JS), a really first rate set of Ajax widgets, to ZK. Grids, drag and drop, data bindings. See here for the tutorial.

Also, you should give a look at the ZK Mobile framework, now at version 0.8.5. Basically you develop apps much the same way you do in ZK for the web, ZUML, etc., but it has a different set of components.

Technorati Tags: ajax, zk, seam, ext js, seasar, spring, mobile

• Digg
• Reddit
• del.icio.us

Comments (1)

agile ajax

Mobile Ajax and Predictions of J2ME’s Demise

Dietrich Kappe, Thursday, August 10, 2006 @ 9:00 am

Nokia is taking a hard look at Ajax for mobile platforms, according to this article. The money quote from a Nokia exec:

Epting , Nokia's Vice President for Developer Operations, says that Nokia's aim of making the mobile platform more predictable and easier to work needs naturally to include newer browsing platforms...and AJAX is very much flavor of the month, so Nokia needs to watch it carefully and decide what mobile developers want.

And from Ajit Jaokar we get the following prediction.

"Java ME as it stands today is seriously flawed (not the technology but the business model)," Jaokar comments. He adds:

XHTML will be an 'also ran' because AJAX will offer a superior user experience. Hence, my belief that AJAX will be the preferred platform of choice for mobile applications at the expense of Java ME and XHTML."

I thought XHTML was part of the Ajax picture, but as we know from his previous articles on the subject, Ajit means 'webapps with postbacks' when he says 'XHTML.' Part of his reasoning is that both XHTML and J2ME break several of the Web 2.0 'principles' set forth by Tim O'Reilly. I think we can agree that XHTML apps that use Ajax are better than ones that don't for bandwidth constrained mobile devices. They also fulfill principle #7 -- Rich User Experiences. J2ME, on the other hand, fails the test of principle #4 -- End of the Software Release Cycle.

There's a few principles that I think mobile Ajax applications need to adhere to in order to make mobile Ajax compare favorably with J2ME:

1. Provide equivalent functionality while downloading smaller amounts of Javascript and other data to limited bandwidth and memory devices.
2. Provide some functionality even with limited connectivity.
3. Elegantly support a diverse set of hardware interfaces.
4. Prevent business logic and sensitive data from leaking into the business tier.

I'm confident this is all possible in the long run as mobile devices get better bandwidth and start to look more like little laptops. What I'm not confident about is the timeframe. Too early is the same thing as wrong, and Ajax for mobile may be too early.

Right now there's lots of positioning with regard to Ajax and mobile, but not a lot of action -- the press release phase of technology innovation. It is worth noting that for the mobile version of its innovative Ajax maps application, Google didn't go with Ajax but instead deployed a J2ME app.

Technorati : ajax, j2me, mobile

• Digg
• Reddit
• del.icio.us

Comments (5)

agile ajax

Google Maps for Mobile - Not AJAX?

Dietrich Kappe, Wednesday, August 2, 2006 @ 9:00 am

I've been using Google Maps for Mobile for a few weeks now and find it rather useful, especially when I'm in a strange city driving a rental without a nav system. OK, what does this have to do with Ajax? Nothing. And that's precisely the point. Google, arguably the pioneer in all things Ajax, is distributing their Maps application -- the Ajax app that first made people sit up and take notice -- to mobile devices as a Java application.

Now maybe under the covers it's actually a custom web browser that supports Ajax, (if anyone has taken the time to test this theory out, please let me know) but I somehow doubt it. What does this say about the state of mobile Ajax if the big dog on the block puts their money down on a custom Java application? I think it means that we're a long way away from practical mobile Ajax and even further away from the winners being picked.

That of course doesn't prevent Nokia and Opera and various other players from claiming that they've solved the mobile Ajax puzzle. Until they solve the problem of direct manipulation, though, they haven't convinced me. Once Opera Mobile allows me to drag Google Maps (the non-mobile kind) around on my phone's screen, they haven't passed the Ajax version of the Turing test.

There are just too many interfaces for mobile devices now to make this practical. How do we support in an Ajax capable browser the buttons, pens and wheels that make up the beastiary of mobile device user controls? It's not just about filling out forms anymore. Some phones may never be Ajax capable for this reason: their controls are just too limiting.

So, don't hold your breath on mobile Ajax. By the time everyone has upgraded their phone, it'll be 2008.

Update 1: I guess some people didn't get the point of this post, and I do admit that I might have burried the lede. So let me try again: Google isn't placing a bet on mobile Ajax. Mobile phones continue to have diverse user controls unsuitable for direct manipulation, which seems necessary for the Ajax version of Google Maps. The next generation of phones (RAZR, etc.) may not have the kind of pen interfaces to support that style of interaction. Therefore, mobile Ajax won't be a reality for quite some time, maybe not even 2008. It's not the software, but the hardware, and that's why google is crafting a seperate app for each phone.

Technorati : ajax, gmm, google maps, java, mobile

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax