Computer graphics and user interfaces

The key to creating your own graphical user interfaces (GUIs) is apparent in the first letter of the acronym. The key is to create your own graphics. You can go a long way relying on pre built widgets, but then you aren't really creating your own GUI you are just using someone else's pre built graphics libraries as a crutch. By the same token you aren't doing programming your own way unless you create your own compiler.

The same is true for rather you are programming for a desktop application or a mobile device. Consequently, that is another area that can be universalized. In the same way that the JVM universalised computation, it is possible a universal API for graphics could be created (OpenGL presumably). There still will always be some interface differences between desktop and mobile devices, but they still share the same common graphical foundations.

The key to creating computer graphics in turn is a combination of geometry and mathematics on the one side and colour management and painting issues on the other. The mathematics used here is interesting because of its heavy use of geometry. In a sense computer graphics is just applied geometry, which makes nice for prospective geometers.

What would creating your own graphical components look in practice? In Swing this involves subclassing JComponent to make your own components. The key role of Java 2D then emerges here because you can then access it by overriding the paintComponent method to give your own component your own custom graphics. This is why Java 2D is so important to Java desktop applications.

Games are another area where custom graphics programming is essential. There is hardly any game that can be developed without doing a lot of custom graphics. You might be able to get fine making some desktop applications without doing custom graphics, but to me it is still essential. It is the center piece of any client side application really. So there is plently of motivation to look into computer graphics.

The evolution of computer input models

Keyboard era

Typewriters were created in the 19 century, and at that time the QWERTY layout begun to define keyboard layouts, and it still largely does to this day. QWERTY was designed to prevent jams in these early typewritters, so it is an inefficient layout and it is relatively hard to learn.

The keyboard was an important technology even before then invention of computers, and then when computers where invented, they played an important role in defining their input models.

At first computers couldn't even accept input from keyboards themselves, so you had to use them to separetly created punched cards to input into the computer. This was known as the batch input model.

The next development was the CLI input model, in which computers directly accepted keyboard input and responded to it in various ways, first with printers, and later with CRT displays like the one the IBM 5100 had. The CLI computers were generally used for programming in Basic or some other programming language.

The first challenge to the use of the keyboard as an input device came from indirect pointing devices like the mouse, however, the mouse alone is far from a challenge to the dominance of the keyboard. The PARC input model, based upon the introduction of the mouse, was introduced to the world with the Apple Macintosh and it subsequently came dominate the computing world for nearly thirty years. Most PARC based computers used a desktop environment with windows, menus, toolbars, and icons.

Post-keyboard era
The "tablet revolution" was partially launched by the introduction of the Apple iPad in April 2010, is based upon multitouch and voice input. These input methods allow you to avoid using hard keyboard using at least three separate means:

1) The use of a virtual keyboard or optical character recognition to input text through the touch screen.

2) The use of speech recognition to input text through voice sensors.

These two methods allow you to eliminate the use of hard keyboards in most cases. One of effect of this is that Laptops are now obsolete, since they carry hard keyboards which exerted extra weight, and which aren't ergonomic either. I have given away all of my laptops so that I can use tablets instead.

Now I require that all the keyboards that I use are ergonomic keyboards with a dvorak layout, which will significantly reduce the strain on my fingers, in order to prevent me from acquiring repetitive strain injury, which is a symptom that effects most heavy computer users from the keyboard age. Now that we have tablets, which are no longer dependent upon hard keyboards, I have directions in which I think we should head:

1) Transition from the old WIMP GUI to a multitouch ZUI and effectively do away with all sorts of popups, including menus and dialog windows, which will have the added effect of moving us towards eliminating the distinction web applications and desktop applications.

2) Make commands rather then applications central to the user interface using NLP algorithms and command packages. Commands can be accessed using speech recognition. One important command should be undo, so that the system can forgive mistakes.

These two ideas were first proposed by design expert Jef Raskins, however, he didn't yet realise that they are best implemented on tablet systems with multitouch input to the ZUI and speech input to the commands. I look forward to seeing these ideas implemented in the future.

Dvorak

For years I was a qwerty typist, and I used Algol-based languages such as C, Perl, and JavaScript, which benefit from the position of the punctuation keys on qwerty. Now, I have discovered a superior keyboard layout: dvorak.

The most important letters are placed on the home row and all of the other letters are placed in accessible positions. This makes typing English much easier, which is especially helpful when typing lisp, as lisp is essentially english words structured with parenthesis.

Dvorak moves the dash symbol to the home row which is a big boost to lispers, as we use the dash as our separator, on the other hand it is only used for subtraction in most programming languages.

The semicolon is moved off of the homerow to the inaccessible position below the left pinky. The other brackets are also moved further away. This is fine for lispers, the parenthesis are what matter anyways.