Keyboards were invented for typewriters. Typewriters are mechanical machines used by humans to avoid handwriting. Since the first typewriters were invented somewhere around the 18th century, they were rather clumsy, and the machinery used wasn’t really working too well, which is why something as awkward as the QWERTY-layout was invented. The QWERTY-layout, still used today, had its justification in the fact that early typewriters had problems when adjacent keys were used simultaneously, which lead to those keys blocking each other. At this point, in the year 1867, keyboard innovation stalled. No real invention has ever had an effect on any keyboard that is widely used until today. There have been some, like the Dvorak layout, a proposed alternative to the QWERTY-layout, but none of these made it’s way to the mainstream, unfortunately.

Today, we are using beautiful, ultra-turbo-high-speed computers that are still equipped with QWERTY-keyboards. And the nonsense doesn’t stop here, we even shrunk those keyboards down to create digital equivalents. This is just ridiculous. I am in no way doubting that a trained writer can actually write fast using an iPhone, iPad or Android Keyboard, but the reason is certainly not the superior design of those keyboards, but our ability to adapt to even the worst of circumstances.

Of course, numerous attempts have been made to improve the typing experience by adding suggestions, which is done on both Android and iOS, and by invisibly changing the “Hit Box” of each key, which is also done on both platforms. I have done qwerted, which did that highlighting both extremely and visually. There have been similar attempts to do this by Thickbuttons, and maybe some others. IBM recently filed a patent that deals with arranging the keys on a touch keyboard to adapt to a specific user, certainly interesting. But it just masks the fact that this approach is seriously flawed, as it still relies on the basic QWERTY-pattern, instead of something better.

Another approach that has become quite popular lately is the Swype‘s approach. When using Swype ( or SlideIT, and there are certainly a few other similar apps for all systems except stock iOS ), the user just moves over the keys the input consists of. Their homepage has some demo videos if you are curious. Again, the foundation is the old-school QWERTY-keyboard, and even though this concept is highly interesting and working reportedly very well, I consider it broken by design.

The question is: why are we wasting a huge amount of screen real estate displaying keys that won’t ever be typed ( or touched over ) ? Take for example Q and X. Those keys are so rarely used after a word has started, it’s unnecessary that they are displayed by default. But it’s getting better: We can even predict very reliably which words are likely to be typed even after a few words or letters have been typed. If you don’t trust me on this one, you should try Google Scribe. The techniques used here are based on n-grams ( at least a part of it ). N-Grams describe a set of n words, which can then be evaluated in terms of probability. Google has extracted a huge set of n-grams from their datasets which can be obtained at the LDC.

Someone must have come up with a great idea to revolutionize touch input. Like, not some fancy new feature, no, a completely new approach. Do you know Dasher? Something like that, of course massively polished.

I hope you are getting my point here, and I’m sorry I don’t have anything more to offer but a few entry points if you want to read further. This is really interesting field and, if time allows, I’d like to do some work here. What are your ideas?

There are some things I’d like to adress in a short here. First of all, iPhone indeed has some kind of resizing of the touch areas for specific keys, but it’s not as extensive as qwerted’s resizing. Just try it ( I did )! Overall, qwerted and all other android keyboards do have a special problem, and that is that screen estate is fairly limited, and at least on my devices ( g1, google ion ) the screen is notably smaller than the iphone’s.

The next issue is word suggestions. Many people approached me with that wish. I’m currently in the process of building “more necessary” things, like a dictionary installer, and qwerted will get suggested words after that. But I guess not in the plain way you know word suggestions. Maybe context aware, maybe something else. But they are definitely on the agenda.

A word on pricing. I set up a small survey for beta users ( If you’re one of those, the survey is on google ), and the results at this point indicate a selling price of about $2.49. I think this is quite fair and reasonable.

I’m sorry if I forgot to answer some mails or didn’t reply to questions, it’s been a few busy days, and I’m still overwhelmed, amazed and thrilled by the way the whole qwerted-thing developed. And it’s just the start.

Finally: I guess I’m going to make the end-of-january deadline!

I am looking for beta testers, so if you want to test it, please let me know!

iType Demo Video from Moritz Haarmann on Vimeo.

Related Blogs

• Related Blogs on android
• Mplayit Launches Android App Store | AndroidGuys
• Nexus One Video Walkthrough | AndroidGuys
• 'NPR News' Arrives for Android! | AndroidGuys
• Motorola Cliq is Latest Android Handset to Get Rooted | AndroidGuys
• Health Blog

• Related Blogs on eclair
• Senator Ben Nelson Takes Last Éclair « PA Pundits – International
• Article de Nord Eclair sur le Front de Lys – Christian Vanneste …
• Download: CDMA Hero Android 2.1 v1.5 Eclair [BETA] « Geek For Me …
• Groovement: TOKIMONSTA / ECLAIR FIFI podcast (Hoya Hoya takeover …

• Related Blogs on iType
• RTTI and enumerators

• Related Blogs on keyboard
• BTstack Keyboard jailbreak app provides iPhone text entry | World …
• iPhone gets Bluetooth keyboard driver «

• Related Blogs on programming
• e-Books Baba » UNIX Network Programming, Volume 2: Interprocess …
• Holiday Programming on Channel 8 TV « KUCB
• Holiday Programming Note… | Cherrybombed
• Apple TV To Host Slew of Programming Options
• Aura Dallas

• Related Blogs on useful
• Effective Tips On Yoga – Useful Information
• Why a Free Tax Course is So Useful « noank6.com
• A Guide To Pickling – Useful Information

• Related Blogs on work
• Workers Comp Kit Blog Workers Blog Archive » NEW ZEALAND Rehab at …
• Work From Home Opportunities For The Unemployed | Philip Harman's …

Let’s explain it. Using RandomAccessFile, you have both Interfaces, DataInput and DataOutput ( and Closeable ) at your service. Wonderful, I thought, and started to use them. Well, two weeks and endless debugging sessions later I figured out why nothing worked the way it should: RandomAccessFile.

This little class is unable to provide the most simple functionality: Write a byte value, say 42, to a certain position, say 11223 in a file, then seek back to 11223, read a byte value, and make sure it’s the same. The reason for this odd, strange, undesired, undocumented feature? No shared buffers. In fact, no buffers, just for the explicit read and write operations ( they are mapped to native methods anyway ). So basically, everything should work fine in an unbuffered environment, with an operating system directly writing everything down on file.

Because virtually no operating system works unbuffered, RandomAccessFile doesn’t work. The working workaround is to sleep for some time or something alike.

By the way, I was only able to figure it out by looking at the openJDK source, an excellent source in case you’re wondering about some Java behaviour. And thanks to Marc Seeger for his help!

I ran the benchmarks on two different machines. One of them is a xen-based virtual machine with 4gb of RAM and a dedicated CPU. The MySQL server runs on a seperate VM on the same physical device. The first graph shows the results at a concurrency level of 2, the second one a concurrency level of 5.

The second run was performed on the machine where this blog is hosted. All benchmarks are running against WordPress’ index.php, to not allow caching to falsify the results. The machine is also a virtual machine, enough RAM, slow cpu though. Please keep in mind that most people are using that kind of machines for their blogging, because dedicated machines are not exactly.. cheap. Anyhow, concurrency level 2. I didn’t bother to check what level 5 would have changed, because the time taken for the first one was already 20 minutes.

For the sake of being mean to all PHP-lovers, I included a bench of an Rails-Application served from the very same VM as the first benchmarks. Of course, you can’t compare Rails to PHP. But still interesting, I think.

So this is, from my point of view, a very much strategic decision, placed just at the right time. Android’s finally deployed to a number of new devices, not only by HTC, but also Samsung and other vendors are now adopting it. So after this first hurdle being taken, Google realized that there is more to mobile devices than PIM functionality and a browser, plus some location based gimmicks. Games are a massively growing market inside the mobile universe. And they want to have a part of that cake, but without a Native Development Kit and the ability to interface graphics directly from real machine code, the speed impacts induced by using a Virtual Machine to execute code are still too high for big games. Can I prove it? Well, no need to, to cite google here:

In a future release we hope to support linking with OpenGL ES and audio libraries, which should enable high-performance games.

By releasing this kit, Google finally opens Android to all those people not willing to write Java Code that perfoms well ( which is not the way Java is handled anywhere else ) and let’s developers to the optimizing of raw code themselves. I’m really looking forward to seeing some of the results.

And, tada, I’ve been spending the last few weeks just entering Rails ( a Ghetto? maybe ) a bit more than I did before. As always, there are cool things to tell. And not so cool things, too. Start with the good ones.

Rails has proven to work extremely well in pre-production mode. No framework-sourced flaws, bugs, whatever. Just nice, and with some caching-salt, speed hasn’t been an issue, in contrast, it has been amazing.

That’s the good part of it. The bad part is that Rails claims to be capable of working in a distributed environment, providing services ( they don’t call them Web Services anymore ) addressable via REST ( buzzzz ) over HTTP, of course. Well, that’s not quite true. If you stick with the example given in the docs, and are in fact happy with a remote object capable of experiencing an unauthenticated change of some first name, this is nothing but true. But when it comes to some other features, e.g. associations or caching, one question came up: are they serious?

Let’s do some demos. In case you want to include objects of a has-many relationship, the way of choice is ( according to the ActiveRecord::Serialization docs ) either to call to_xml with really ugly parameters ( such as @ship.to_xml :include=>[:passengers, :sailors ] ) in a non-dry manner or to override to_xml, both not being exactly Rails-like, ugly, hard to maintain and only loosely coupled with real-world requirements.

The other part, the consuming part where ActiveResource is indeed responsible for handling everything, has been consequently kept free of useful stuff. This could on the one hand be a pro for people hating Rails’ magic, but it’s just quite far away from being usable. And it has nothing in common with the way ActiveRecord behaves. Any options? Sure.

At the moment, I’m sticking with HyperactiveResource, the funniest named plugin ever. It extends ActiveResource to play a bit more nice, yet it’s not the ultimate answer, but a great extension, still. If you’re into some serious Rails stuff with some distributed thingies, you should give it a try.

So what’s missing? The feeling to work with something that has been designed by someone who actually uses it doing more than changing first names. I’m really disappointed by having to deal with the framework, something I wasn’t used to with Rails before in that intensity. And while Java EE may be a pain, for distributed stuff, it’s still a very good way if you need reliable and consistent, proven-to-work solutions.

In my next post, I’ll talk about my android experiences so far. Love it

I’m still exploring the API, and Android as a complete product, and the more I learn, the more I’m getting caught by it. And I’m sure that a few years from now, many people now using costly, unhandy notebooks will be using devices based on something like Android.

But let’s try to stick to the title of this post. First of all, I’m really looking forward to Google I/O. I booked a flight, it’s my 2nd time in San Francisco ( I don’t know where to sleep yet, but there’s some time left to figure it out, hints welcome ), excited. And I’m working towards finishing my own keyboard implementation to show it off. I’m not going to talk about it in detail as long as there is no working demo available, and it will take some time, trust me.

I’m also waiting for Cupcake. Cupcake, for the ones of you who are not familiar with Android, is a read-only development branch, meant to publish non open-source development efforts. These efforts also include the creation of an Interface to implement custom Input Methods, be it a Keyboard or anything else that allows for input of textual data. One could very well think of a Morse-to-Text button ( idea for a tutorial ), a rotate-to-write or an application using an artificial neural network to do some lip-reading using the phones camera. Though the last one will be quite resource-consuming, the point is, anything can be done using the very generic API.

Once again, if you want to use it, get yourself the Cupcake Sources. It’s well explained at source.android.com. I somehow made it, without spending more than about 30 minutes, to build emulator images and the rest i needed to get going. And although the Eclipse plugin reports an error, it’s working even for cupcake.

Luckily, when building the stuff you need the docs are also being created, explaining what you need. I especially recommend to take a look at the built-in keyboard’s implementation, as it’s very readable and self-explaining.

I’m really hoping to find some time to publish a tutorial on this topic, but I’m not able to promise anything.

At least for me, this fun suddenly ends when it comes to controllers and their more-or-less tight integration to according views. The traditional, but still largely used, MVC-pattern worked perfect for monolithic, big pages with each one having a clearly defined function.

Today, the world changed. AJAX is still hot shit, and using it without a) blowing up the lines of code in both the view and the controller requires either writing a lot of unreusable helper-functions or depending on templates ( or partials ), anyhow, prepared lines of view code.

But the core idiom of AJAX, the ability to exchange single parts of a website without touching the rest of it, is and cannot be addressed efficiently using these two methods, at least not with the claim that development is fun. It’s not fun ( at least not here.. again ) to include templates over and over and over again. Web development is still, tell me I’m wrong, struggling with the Presentation rather than solving complicated Model-related tasks. And there is either no one concerned or I am way to stupid to get the point.

I’m really looking for a metalanguage describing a web-interface, with all it’s bindings to data, to related controllers and a framework being able to process such a thing ( including caching and so on ), making it straightforward to develop an ajax-based interface, tailored to one’s needs.

For those of you pointing at one of the many JavaScript Frameworks, like GWT, enabling such a functionality: It’s not what I mean. It’s a more general, server-side processed approach, enabling slim clients and fast page processing.

Edit: I know, editing posts is not best practice, but this small additions isn’t wort another post. So I was really thinking a lot about what I wrote here, and I’m quite confident that the main point is indeed the fact the code that logically belongs to the viewer ( something that loads a list for an autocompleter ) is still around in the controller which creates a scenario we usually try to avoid using MVC.. view code in the controller. And updating the view once again requires updating the controller code, most likely at least. What is the other option? To let that simple code be created by a helper at the time it’s needed. Same for Content-type switching orgies to format the output properly. I’m on it, to make coding a little more fun.

And if I’ve been missing some hot new thing ( I’ve been playing with CouchDB, jiha ), please let me know.