Path dependency: case of the QWERTZ keyboard

Image

Image

(photos from http://en.wikipedia.org/wiki/German_keyboard_layout)

It is not that often that knowledge, competence, and experience in collecting computers would offer a new perspective to comment a text by a journalist, but then it is perhaps also not that often that such texts would exhibit same attention to details than collecting does.

In this Saturday’s Helsingin Sanomat, a columnist reports about a tablet computer that he has bought due to its cheaper price from a German online store. However, his password is not working even after a several attempts. Eventually, he discovers the reason: “The letters Z and Y are both found in the wrong place on the platform of the keyboard.” He continues, “the assembly line seems have been a little bit busy during Christmas”. Later the text asks, “whether a Chinese worker loses her sleep because slipping Z and Y to the wrong place”.

From these observations, the column then moves to consider the wastefulness of Finnish households and the fate of electronic waste — an interesting connection that I will not discuss more here. Instead, I want to note that the premise of the column could have been more accurate. As anyone who has owned retro or other computers from Central European countries would point out, the two letters Z and Y are not actually in the “wrong place”.  Like Wikipedia could also tell us, they merely represent a different standard for organizing the keyboard.

More theoretically, drawing on economics and social science, the issue here can be named as path dependency. There is an expanding research literature on this concept, but let me try to offer my own explanation: technologies are path-dependent in so far as some, although rarely all, of their features stem from technologies that have been invented in the past and then standardized through various channels like patents, standards, education, and practices of everyday use. Such dependencies, while persistent and often not questioned in the context of everyday life, have furthermore in many cases little or nothing to do with the functionality of the current technology.

For instance, as I realized and blogged after seeing a typewriter in a museum, the shift, the caps lock, and the (carriage) return keys of current keyboards derive their names from very physical functions of the typewriter: “shift” actually shifted a mechanism that punches letters, “caps lock” locked this same mechanism, and “return” physically moved a sheet of a paper.  Partly due to conventionality — but much more directly, due to patenting, standardization, training, and user skills as I will discuss soon — the names have persisted even if we might legimately name these keys something else today.

With shift, caps lock, and return, the current practices of keyboard use are still somewhat present in the keys’ names. However, this is not accurate for the order of keys on the keyboard. There is — and it seems, never even has been — a direct ergonomic or other usability reason for ordering keys in the currently popular QWERTY order. On the contrary, this ordering has been often deemed as counter-productive for typing speed. According to Wikipedia, the QWERTY order was only gradually invented to minimize jamming issues in the 19th century typewriters. Such issues are clearly not important for current computer keyboards; however, the order is still commonly deployed because it was first patented and then later standardized and established in education.

Here, a path was formed because specific institutional practices helped maintain it — while patents can expire, standards and education tend to have long duration measured by their effects. For a user, it can be both time consuming and even irritating to relearn typing a keyboard, for example, as anyone having traveled would probably note. But having said that, the concept of path dependency should still not suggest that there was only one path or that a path offers no room for alternative designs. One matter is that different actors like inventors, entrepreneurs, and standardization bodies have always tried to establish different standards with an interest in the different imagined ways of using technology; another matter, probably more relevant here, is that sometimes such actors have also successfully shifted the already established standard for their own needs.

Such seems to be precisely the case with the QWERTZ keyboard, which is based on German standard DIN 2137-2 and is also popular for example in Switzerland, Austria, and Slovenia. Several other popular variations also exist including the AZERTY keyboard prominent in France and the more thorough redeployments such as the simplified Dvorak order patented already in 1936.

These and other diverse ways of designing and standardizing technologies are not simply manufacturing errors or slippages — although from an everyday perspective where technologies have become almost obviated, they may certainly seem like that. They are co-existing, but still established kinds of technological design. They are partly maintained by standards, but also significantly by technology users who have grown attached to a particular learned way of deploying the keyboard, or a software, or even an entire operating system. To me, all of this suggests that while many internationally adopted standards certainly exist — the Internet offering many useful examples from HTML to PHP — sensitivity to the local practices of technology use remains important as ever.

Advertisements

Dingoo A320: extremely simple reset button

Reset from one of the screws

I recently discovered this video which shows how to make your own reset button to the Dingoo A320, a charming little portable emulator handheld, which unfortunately is lacking such a button by default. Specifically, the reset is hidden behind a miniscule outlet, which means that you must have a needle or some other sharp stick-like object to push it, which you furthermore need to do relatively often as this is the only way to resume operations after transfering files from your PC. However, luckily, it is fairly simple to create your own button as shown by the video: you just need to open the apparatus and fit something into the reset outlet to serve as a button that then presses the actual switch located on the circuit board. Finally, you will of course have to clam the handheld back together, with all its buttons intact, which was a bit of a challenge at least for me but succeeded after a while.

I followed the video pretty closely–however, lacking any other suitable small object, I just used one of the four screws that normally holds the Dingoo together. It works fair enough, but predictably, the button is a little bit sharp. Maybe one should have used a plastic screw like in the video or at least attach a bolt to the screw. We’ll see if I I have the patience to open it up again if I can find some suitable plastic object…

Also swept the whole portable with cleaning liquid for eye glasses and it looks good and clean now. Currently am looking to purchase a plastic screen shield in hope of covering some of the most visible scratches on the screen–something which this handheld seems to attract a lot for some reason.

CyanogenMod 7 on an HTC Legend

HTC_cyanogen_7

After some initial concerns about if this process requires Windows — and it does — I managed to install a modified Android to my aging HTC Legend. The end result is excellent especially given that the manufacturer has not updated operating system for almost two years.

To do the modification, I followed the instructions in this link.

The good thing is that HTC has opened the process of unlocking your phone’s bootloader. You no longer need to format a special SD card (a “gold card”) with  hex editors or such — which was slightly difficult to begin with. The somewhat less fortunate thing is that these tools by HTC require a real computer with Windows. No tinkering with a virtual computer on Mac OS X seemed to help here.

Somewhat ironically, getting a Windows to run turned to be the most time-consuming part. I finally decided to let go of my six-year old Asus Mini laptop, where Windows XP installs and runs but not very fast. Therefore, the above tools — including the unlocker as well as a programme called HTC Sync which is essential for communications — took two to three hours to install albeit they did their tasks eventually.

After that, however, all went fluidly. I won’t repeat the instructions above as they worked fine.

During the past few days, I have been very happy to have a modified Android for several reasons:

  • The phone runs slightly faster especially with the Launcher Pro interface.
  • More memory is now available as most programmes can be installed on the SD card and there seems to be little software that is “enforced” (unlike before).  I installed a couple of games I would not have before and even bought my first game for the phone (Canabalt HD) — I never felt like buying before even after having it for 2.5 years.
  • The phone now has a much more modern operating system and software (e.g. Youtube, browsers, games).
  • There are new ring tones and themes, which makes the phone feel new.
  • The operating system shall be updated also in the future.
  • It was a good opportunity to learn about how Android works.

All in all, I am satisfied with going through this process. It is good to be in control of your own phone that you use all the time. And excluding the two afternoons I spent doing this also with help of a friend, all of this was for free (and legit). As Christmas approaches, television and newspapers are bombarding us with advertisements about new tabs and smart phones. No doubt they would be glad to supply me with one if I  pay. However, my old HTC just got an extension probably for many years. For many practical purposes, it feels like a new phone. Rather than buying new phone and throwing the old out with garbage, I could for instance buy quite a many games from the App Store with the money I just saved. Or save money to travel, for instance.

Just a few caveats should be mentioned. The operating system or maybe the launcher is slightly buggy, does odd things every once in a while (restarts, loses icons), and the whole phone had to be rebooted once. Similar glitchiness is true for the picture gallery (which is nice other wise). Also, the battery life has not improved, but it was pretty bad to begin with. I may just have to change the battery. Anyway these are minor caveats — for the bugs, they are something one accepts when running experimental software.

Raspberry Pi: initial impressions

A friend bought and supplied me with a Raspberry Pi, an embedded ARM Gnu/Linux system. Many thanks for this!

The initial impressions are good indeed: seems to be a highly suitable platform for creative tinkering and technical experimenting. But before I continue, here is what have done with it so far.

Setting it up. I downloaded the Raspbian “wheezy” Linux disk image here and set it up on an SD memory card with my laptop and a card reader with the instructions here. All went fine.

Running for the first time. The following list will be online in a number of places, but no harm done repeating. In addition to the system, you will need:

  • An SD memory card, minimum 2 GB, but preferably 4 GB or more as at least the above Linux distribution takes almost the 2 GB.
  • An RCA cable and a mini plug sound cable or a HDMI cable for picture/sound.
  • An Ethernet cable for Internet connectivity.
  • An USB keyboard (more on this below).
  • An USB mouse (optional).
  • A power source and a micro USB cable. The AC adapter I use outputs 5V and 1A.

Inserted the SD card to the Raspberry, plugged all cables in, looked for a picture in my television/monitor, and then let the install finish itself. No problems here. The installation program let me select a local keyboard layout, change the password, setup an SSH server, and make use the whole SD card (the disk image was 2 GB while my SD card is 4 GB).

First test. Picture works, sound too. Was able start the X server. Internet is connected. Downloaded software with apt-get. Plays MP3’s all right (using the Alsa standard). And surprisingly, mplayer was able to show a low-res movie (320×240) relatively well — albeit no hardware scaling here so you only get a small picture. A while later after installing more software mplayer no longer shows anything, I will have to see about it later.

Coding. Of course thought about porting my code here. In particular, I’ve programmed a small music programme for mobile platforms years ago which should work fine here too. It compiles indeed all right, but the handling of the screen is somehow different from standard SDL; still needs some work. As for future possibilities, it may be interesting to know that the Raspberry also supports a version of the OpenGL standard, examples found in Raspbian in /opt/vc/src/hello_pi.

Bluetooth keyboard. I had no expectations that this would work at all and certainly not this easily. I have a Bluetooth USB adapter by Clas Ohlson (the adapter is Class 2 and model GUBTRC42I, could be made by Toshiba originally). Plugged it it in to the Raspberry USB port and then used apt-get to install bluez-utils, the Bluetooth utilities, and blueman, a graphical Bluetooth manager. Started the X server and ran blueman there. This involved a bit of a hassle given that Raspberry has two USB ports, one is now taken by the USB adapter and only one is available for both the keyboard and the mouse. Ended up alternating the keyboard and mouse based on which I needed in blueman — it worked 🙂 Searched for an Apple Bluetooth keyboard, needed to “pair” it a couple of times which is of course not unusual with Bluetooth. Was surprised nonetheless when the keyboard paired, connected, and worked. The OS asked me whether I want always to accept this device and I did. When I quit the X server, the system crashed; however, I was very surprised when I booted and the Bluetooth keyboard still worked. More positively, still, it has also worked ever since: just power the keyboard and start typing after booting Raspberry. Happy thing.

Battery power.  As said the Raspberry runs with an AC adapter or electrical power from your laptop etc. However, recently, I bought an “emergency” external battery pack for my smart phone, which now runs out of electrical charge pretty instantly as I use it to listen to streaming music when I walk to work and while working.  This battery pack by Oyama outputs 5V and 1A (the electrical charge of the battery is 1500 mAh). Plugged it in to the Raspberry power connector just to try and everything works fine — thus there you have a mobile Raspberry with a battery 🙂 I thought about testing how long this would last; however, one may not want to try a power outage in Linux (it may risk the SD card) so this may really be more of a gimmick.

Here is a picture and description of the whole setup as it stands currently.

1. SD card (4 GB)
2. An RCA cable that connects to a television/monitor.
3. A mini stereo cable that connects to the same television/monitor.
4. The Clas Ohlson brand USB Bluetooth adapter.
5. Ethernet cable for Internet.
6. An Apple Bluetooth keyboard.
7. Power cable (from an AC adapter 5V and 1A).
8. The HDMI connection for picture (and sound?) is not in use yet.

All in all, in my humble opinion, what works so well and gives the platform so many possibilities is that it functions like an actual computer with open tools. Hence, for one, programming tools are free, standard, and available. There is no need to purchase or even download an “embedded suite” or a “developing kit”. No eclectic “simulation” environments to first learn and then use to develop code. No need to use Windows unless you want to. Indeed you do not even need to cross-compile: gcc runs on Raspberry fine, and you can code remote with SSH.  For all practical purposes, this feels like a real computer rather than some appliance that just happens to have Internet connectivity. Look much forward to doing more with it.

Demo authoring

I counted I’ve programmed over 20 demos in my life. See the Wikipedia article for “demoscene” to learn more if you have not heard about the demo subculture. By programming, I mean writing code in C and Assembler, but also designing the look of the demo, and composing music lot of the time.

Demos are a great platform for experimenting with certain things, especially more technical. They also seem to teach you a programming style that is experimental, pragmatic, and often highly efficient. For example, recently, I tinkered with OpenGL pixel shaders for one afternoon and got some simple demonstration working quite soon.

It is a demo cliche to say that it is much more difficult to add a plot, a narrative, a design, or an idea to a demo. In terms of what to do if I make another demo in my life, I think I am beginning to concur.

Most time demo making is about crafting minute details: optimizing inner loops, finding how computer screen “buffers” are structured, coming up ways to make visuals appear more complex than they are, or learning to program new computers from archaic to the modern as a challenge.

Yet, almost none of my demos that were well received were well received because of such technicalities in themselves. Rather, people seemed to like their overall look, style, how things moved, the rudimentary story lines, music, and such. Ironically, it seems that the best received demos were perhaps the most technically simple.

The point then is: it may make sense to spend more time on the look and idea of a demo at the expense of technicalities, or have someone else handle the technicalities for me.

In this context, a decade ago, things got a lot easier with the OpenGL library. It gives you three dimensional mathematics and a way to draw simple shapes, and now even access to each pixel of a shape through so-called pixel shaders (mentioned above). What it does not give is, how to show a complex three dimensional object (maybe even such that was designed in another software) or how to make objects move (using e.g. software physics to make it appear more realistic). Things like that are not easy to learn and do yourself and while libraries exist, it may take time to install them and again, learn to use them. I do want to have something a little bit more abstract to use.

I was considering Unity 3D a while until I realized that the development environment does not work in Linux at least yet. What other possibilities are there? How do designers “script” visuals on computers, for games for example? Let’s find out…

Technical complaints

image

I am taking photos and keeping a blog with my smart phone and doing all of the writing on a train.

That may be a lot and it surely may not even be my right to complain. But given the technical possibilities, one perhaps just starts to pay attention to minor recurring annoyances.

These include:

The phone’s battery is dead within a few hours. I feel like I am constantly running against the red bar that indicates diminishing power.

The Wifi in the train is quite unreliable.

The mobile Internet that I pay for either does or does not work, seems to do that pretty randomly. I use this connection however because it seems to be somewhat less unreliable than the Wifi.

I don’t know if the Wifi “supports” my phone or something. But I’ve had no problems with wireless in universities and hotels while traveling.

The blog client on the phone has bugs.

Some pictures appear, some don’t in blog posts.

The client also crashes (it did when I was writing this post and tried to take a picture with the camera and add it to the post. If the picture appears now, it is because I went around the client and just took the picture with the regular camera app).

All in all, the phone is just a bit too slow to work fluidly.

Perhaps it is one thing to be blogging on a train… another to feel it really works…