A dream or a nightmare in code?

Scott Rosenberg seems to be enjoying himself at lot at the moment writing pieces on failed (or at least tormented) software projects. I have been reading his book “Dreaming in Code” on the recommendation of Joel Splosky who wrote an excellent review that gives a good overview of the “plot” – but more on that later.

Do take the time to take a look at Charlie Brookers (UK) Guardian piece on Apple computers if you did not catch it via Reddit. I have definitely been feeling the worse for the continuous Apple marketing hype recently – even if I did make a small contribution after the phone launch. Oh and I’m getting more than a bit bored by the endless Internet posts on Microsoft Vista as well – OK, it is here, people will buy it and we developers will have to take it under our wing and write code that runs on it – end of story. I suppose that anyone interested in a fresh look at operating systems – well the User Interface (UI) anyway should take a look at Beryl which is very impressive although I am not convinced that further developments of the existing desktop metaphor is necessarily the right way forward. The worrying thing is that, like the western keyboard layout, it might become “stuck” in peoples minds as a defining attribute of a PC user interface. We might remain forever saddled with it – just as we are with the keyboard reflecting the user interface of mechanical typewriters even though I am pretty sure we could individually convert to a more efficient keyboard layout in two or three days.

On the subject of keyboards and my flirtation with the Fujitsu Siemens smart-phone, I had decided to code up a programmer’s calculator for the device as the existing calculator is pretty naff and the available commercial replacements do not seem to be able to manage the small screen area available on this device. To maximise the limited screen space I want to be able to utilise the numeric keys on the keyboard. As with all such miniature keyboards numeric keys are “shifted” and share duty with letters and symbols on the same physical key. Now the designers of this device clearly felt driven to maximise the phone like experience so they overlaid the numeric keys on the keyboard in a standard phone layout (1,2,3 at the top and 0 by itself at the bottom). However it was the zero key that presented the designers with a “real-estate” problem. They solved their problem by getting one key to share three characters. A neat solution for a designer with a single mind set but a disaster for a more generic programming environment as the three characters are 0 (zero), . (full stop or decimal point) and the colon. On my count that is two crucial numeric characters on the same key. So my plan to accept numeric key presses as numbers irrespective of the various shift keys was blown away.

It is an interesting thought that there might be a button based replacement for the keyboards used for desktop computers and mobile devices just waiting to be discovered. I suppose persuading folks to “risk” acquiring the required skill could be an uphill task but once a certain critical mass is achieved it could be the answer to all of our needs. Still I suppose the endless drive to patent everything would stifle any truly new approach before it could get underway. Of course the solution could be created in software instead making use of the existing pointing devices of mouse and stylus. There was a lot of original work done for the Apple Newton later carried over to the early Palm PDAs on converting stylised “gestures” into unambiguous characters and that approach might have gone a lot further if the less effective but more marketable “handwriting recognition” attempts had not pushed this approach to one side. I am taking a look at Dasher which is a clever, multilingual approach to the issue; applying software and “pointing” to the task of text generation. The merging of text recognition, text to speech with software text entry may result in a true UI revolution without having to solve all of the inherent semantic problems associated with speech recognition by itself.

One mechanical keyboard option is the BAT device. Here you press keys in “chords” to make individual letters (or indeed whole commands). I can’t say I’ve tried it but I do remember using a manual keypunch to create punch cards. That required the manipulation of up to three keys in combination in order to produce characters from the ASCII set and I also remember that with very little practice it was possible to punch the cards at quite a pace. Not as fast as a modern keyboard but you have to allow for the fact that the key presses actually had to punch clear and accurate holes in a piece of card. So, simplified keyboards could be the answer – indeed youthful phone “texters” demonstrate this every minute of every day – particularly when their input is coupled to some sort of text prediction software.

There was a brilliant post by Jeff Atwood of “Coding Horror” fame on using the Windows CE/ Smartphone software emulators to test your web site from browsers scaled to this small devices. The article link is here but scroll down to the details of this useful feature. I suspect that mobile small screen access to web sites is going to become increasingly important – particularly where information or social interaction is a key component of the relationship between the user and the site. We are certainly working on getting our site suitable for effective mobile use – plus we are also building a prototype web application designed from the outset to be accessed exclusively from a PDA.

So “Dreaming in Code” – unfortunately the subtitle rather gives away the ending - “Two dozen programmers, three years, 4,732 bugs and one quest for transcendent code” - but it is a very good description of the problems and difficulties in running any software development project. On that basis, perhaps it should be required reading for all non IT managers faced with involvement or oversight of such a project. The particular case of the OSAF Chandler project sounds superficially non typical but I suspect that in reality it’s vague initial objectives and it’s seemingly endless incapacity to define a solid specification is much more representative than one would hope. As the main themes of the book have been well reviewed elsewhere I will confine myself to a future post or two on subjects where the book has triggered some thought on my part. I intend to start with the thorny issue of task time estimating.

You can check on how the preview release of Chandler (version 0.7) is coming along at the builds page – they are hoping for an April 2007 date for this release just a year later than their published timeline anticipates. Read the book – this project is a case history still in the making.