The (more or less) forgotten Amiga technologies
The Amiga is the cat of computing. The bird Phoenix. The zombie that refuses to stay in the grave. It seems to have lived multiple lives and died multiple deaths. And each time, it has been taking a lot of unique design ideas and technologies with it into the grave.
On this page I shall attempt to describe some of the things I miss, hoping that some day, someone will pick it up and carry on where the Amiga left. I may also describe things that did survive, but are now so rare that I think they need to be exposed further.
Many applications have some sort of scripting engine. This scripting engine usually resides within the host application. On the Amiga it was the other way around: The scripting language is the host, calling whatever applications it needs from the same script. This is achieved by exposing a so-called Rexx Port, that the script then connects to. Once connected, the functionality of the application becomes available as a set of additional commands that are seemlessly added to the existing Rexx syntax. This approach has numerous benefits:
I have been informed that AppleScript serves the same purpose, but I would like to confirm this by 1st hand experience before elaborating on any similiarities.
- The user only has to learn one scripting language in order to control applications from multiple vendors.
- One single script can easily access multiple applications, drawing on functionality from all these.
- Application developers do not need to spend time implementing a scripting language. All they have to do is allowing Rexx to control their application by exposing a Rexx port. Thus, on the Amiga it was common for modern applications to be scriptable, because the extra development overhead of adding scripting support was much smaller.
- Because the scripting language and syntax is the same no matter what program you're addressing, it becomes easier to learn to script everything.
- Rexx resembles english more than most other programming languages, making it easier for non-programmers to learn.
Every single application should not need to have an import/export filter (loader/saver) for every single fileformat on earth. This should simply be a part of the operating system, as it was on the Amiga. This way new file formats will be accessible to all applications - even old ones - as soon as the proper Datatypes module is installed.
Example: Once you've added a PNG Datatypes loader, all graphics applications, browsers etc. will then support PNG.
Wide use of the IFF format
A vast majority of Amiga software reads and writes IFF files. IFF resembles XML files, but is binary and thus less prone to encoding and spelling mistakes. It also uses much less space. IFF files are typically both forwards and backwards compatible, that is, new software can read old files and vice versa. To identify any IFF file, you only need to read the first 12 bytes of the file.
Before the PC had noticeable graphics abilities, all graphics software on the Amiga used the IFF ILBM format. This way you never had to deal with conversions, as all software used the same format. More.
File type detection
The Amiga looks at the file header when deciding what filetype something is. So even if you loose the file extension, or don't even have file extensions, everything still works perfectly.
Focusing a window does not bring it on top
That's right, you had to do this yourself on the Amiga. Now this might sound like you'll have to spend a lot of extra time clicking the right windows in front of each other, but having used this GUI for over 10 years, I sincerely beleive that dealing with this yourself is actually faster than not being in control of window placement.
My favorite example is this: Imagine using a text editor in fullscreen. You need to calculate several values for the document at hand, so you bring up a little calculator. Upon clicking the document to type in the first value, the calculator now dissappears behind the text editor. This goes on everytime you need the calculator.
On Windows, you're sometimes presented with an option "Always on top", which is obviously a feature designed to overcome the above problem. I do find this approach somewhat suboptimal compared to never having these issues to begin with.
On some Unix window managers, there is a feature called "focus follows mouse" which also addresses and solves this problem, but you suddenly have to pay too much attention to the placement of the mouse, which I find equally troublesome to use. I still to this day prefer the Amiga solution, even though I've had over 10 years to get used to Windows' way of doing this.
Now I'm well aware this is also a matter of taste, but because no current operating system / window manager (except KDE) currently offers this, I find that many people are missing a chance to try something I find very efficient. And at least this yet another example of the Amiga not just copying other companies, but rather boldly rethinking fundamental usability concepts.
US + Western Europe keyboard
The Amiga had the entire iso-8859-1 character set mapped onto it's standard US layout. Of course you could change the keyboard layout like on any other modern OS, but if you left it at US, it was still quite easy to reach german, swedish, danish, spanish and french letters, without having to type in ascii codes or hurt your fingers.
No modal dialogs
If you have a Windows machine, try this: Open notepad. Press Ctrl-O to bring up the file dialog. Notice that while it is open, the main notepad window is completely frozen. You cannot move or resize it.
This is called a "modal dialog", and is a design limitation that occurs because resizing and moving a window requires the attention of the application itself. On the amiga, resizing and moving a window is handled by the operating system. This is why you are never troubled by these "frozen windows" on the amiga.
This feature originates from VMS. Even though all aspects of this was never entirely well implemented on the Amiga, it allowed you to assign (create) a virtual device name (something that resembles a drive letter on a PC) that points to several destination folders. The somewhat similar feature called "Linked Folders" in Windows is less elegant, as it just shows the list of destination folders. In Unix you can achieve something similar using softlinks, but it can be troublesome administrating this, and it's less dynamic than Multiple Assigns.
HAM - Hold And Modify
Perhaps not entirely as usable today, this technology still is somewhat fascinating as it allowed 4096 colors using only 6 bits per pixel, 262144 colors using 8 bits per pixel and, in theory, full truecolor 16777216 colors using only 10 bits per pixel. Decoding this format is extremely fast if you scan the file from left to right, top down.
Original image, typical JPEG compression
HAM-8 (8 bits per pixel) as seen on an Amiga 1200 or 4000
HAM-6 (6 bits per pixel) as seen on an Amiga 500, 600, 2000 or 3000
The last image shows the maximum possible graphical quality that could be displayed on an Amiga in 1985. Maximum resolution back then was appx. 720 x 576 (PAL). This was only a year after EGA and just two years before the introduction of VGA (which was still only 256 colors at 640x480.)
This section needs to be written
The concept "virtual desktops" is attempting to mimic parts of what "screens" on the Amiga did. Unfortunately it oversees many interesting usability concepts covered by the Amiga's screens.
This still needs to be written:
- Explain how screens were completely isolated, creating an experience of working on multiple computers rather than one machine.
- Screens could have different resolutions and numbers of colors. Explain why this is partially relevant today.
- Conjure up a demonstration video of screens in action, in order to demonstrate. Windows and Mac users are not used to this concept, and need a good visual presentation of this rather alien phenomena.
Found an error or a mistake? Let me know so that I can fix it: joachip at gmail dot com
Website by Joachim Michaelis