Learning Curved

[Tycho Morgan]

I've had a few thoughts about the learning curve of mobile technology, mostly in relationship to the idea of functionality and usability that I brought forward last week. <br /><br />Obviously because of the drastically different form that mobile technology employs different types of interfaces, input options, and software applications, in order to provide a user experience that is practical. These optimizations are a good thing, especially on paper, but in practice it's hard to get used to some of the changes that the developers make when trying to streamline, and as a result some of the most potentially productive innovations in the Pocket PC, are rendered virtually useless. <br /><br />It's hard for the developers to find the balance between innovative design, and the familiar methods that we are used to. Do you create a product that will allow users to input data with remarkable speed assuming they take the time to learn a new way of writing or typing? Input is obviously more subject to these kinds of challenges, but interfaces of all sorts can run in to this problem. A solution may have the <i>possibility</i> for exceptional productivity, but if the user must jump over too many learning-related hurtles, then the solution will ultimately flop. <br /><br />The learning curve dilemma is present in many parts of today's Pocket PCs: feature organization, menu structure, and of course—for me--the never ending input drama. <br /><br />Ideally there shouldn't be any learning curve, and this is why qwerty keyboards are appealing. Almost every computer user knows instinctively how to use one, and so these options are successful, despite not really being optimized or at peak efficiency for anything less than full sized keyboards, and some would argue that it isn't even at peak efficiency for desktop touch typing, but that's another story for another site. Unlike the qwerty based solutions where you don't have to teach yourself anything new, solutions such as Graffiti, Fitaly, and the twiddler keyboard are designed to provide mobile device users with a greater productivity possibility by making devices that are optimized for mobile tasks. We need such solutions in order to take full advantage of our Pocket PCs; otherwise our pretty little Pocket PCs will be virtually useless for any serious kind of task. Sadly, these solutions don't come without a price: They require us to learn new techniques and methods for doing something that we most likely already know how to do on our desktops. <br /><br />On paper this doesn't seem like much of a problem, but when you go to use a new system, it becomes a problem of massive proportions. We are creatures of habit, and thus it is really hard, if not impossible, to get us to learn a new method of typing or writing. <br /><br />What do you think the perfect balance between innovative design (with a learning curve) and adaptations of the same standards that don't require you to learn anything new? What would you suggest to the developer of an innovative new input or interface that might require users to learn a new and contrary system. Finally, to what extent do you believe developers should maintain backwards compatibility?

[Russ Smith]

I've thought about this a fair bit too. One reason I prefered WordLogic over FITALY was that it retained the familiar QWERTY design which made it less likely for me to be hunting to find a particular letter. The thing is, that nothing really works as fast, for large amounts of data entry, to a touch-typist, as a full-sized keyboard. If you could find something with a relatively short learning curve that still would allow 60words per minute, I'd be the first in line to buy it (and stock in the company as well).

What we have are compromises. That's not bad in itself, but it is reality. Either it takes a while to extract the keyboard and hook it up (and then you really want a flat surface) or it's a bit slower because it's smaller or it's a bit slower because you can't be moving the next finger to the key even as you're typing the current one because you're using a stylus to "type." Handwriting recognition only works well for people who write faster than they type. Voice recognition doesn't work...yet.

Even if we do get something thouroughly workable, there are still some issues. Foremost among them is the fact that that [] SIP keeps poping up, stealing my screen real estate, even when I'm using an external keyboard. The UI is going to have to be "tolerant" of alternate input on a new level for it to be as useful as it can be.

[karen]

Ideally there shouldn't be any learning curve, and this is why qwerty keyboards are appealing. Almost every computer user knows instinctively how to use one, and so these options are successful, despite not really being optimized or at peak efficiency for anything less than full sized keyboards,

Actually, QWERTY isn't even optimal for full size keyboards. The QWERTY layout was specifically designed to SLOW DOWN typists so that typewriters wouldn't jam up from typing so fast (the letters would jam together in front of th paper).

Since the move to keyboards over typewriters, there have been improved layout designs that would allow much faster typing. However, as you point out, most typist will not take the time to learn this faster layout.

[M]

Good design allows potentially powerful and complex capabilities to be accessed in simple and intuitive ways. Innovation is the mechanism for creating new capabilities. Unfortunately, good design and innovation don't often occur together. In many cases, innovation makes a leap forward, but the accessibility of the innovative capability is limited by a poorly designed (or not designed at all) interface (and it is really more than just interface; what about an innovative technology that works great on its own, but not with anything around it? How often have we seen that in computing?). Part of the reason is that making something work for people (vs. them working for it) is an interative process. The evolution of the GUI, particularly the PocketPC GUI, is a good example. The other part of the problem is that engineers and computer scientists aren't generally taught design. A lot of problems could be nipped in the bud if they were.