The Story of GUI Development (WIP Title)
The history of GUI development is almost as old as computers. In the late 30s, Vannevar Bush envisioned a electromechanical device called Memex which would contain an individual's books, records, communications, and associate trails of links and personal annotations. Bush envisioned it as looking like a desk with two touch screen graphical displays, a keyboard, and a scanner attached to it. This is essentially a tablet as we think of it today. Bush gave details his idea in an article titled As We May Think.
One of the people who read that article was a computer scientist named Douglas Engelbart. He was heavily inspired by this article and early in his career, he made the decision to develop ways to enhance the human-computer relationship. He and his colleagues at Stanford Research Institute worked for years to develop the first graphical user interface. In 1968, they presented their work in front of thousands of people. Their system was called oN-Line System (NLS). NLS had many of the landmark features of modern computers; windows, hypertext, graphics, mouse, collaborative editing, video conferencing, and many more. It's astounding that the modern GUI was invented all at once. We still use many of the concepts used in that demo today. This demo was later called The Mother of All Demos. Here's a short version of the demo where you can see some of these things.
Douglas Engelbart's presentation inspired engineers and companies to pursue a better interface for their devices. One of the first companies to do that was Xerox. Xerox upper management realised the unavoidable paperless future and they wanted to control this new technology to ensure the longevity and profitability of their business. In 1970, Xerox founded the Palo Alto Research Center (PARC) to work on cutting edge technology to improve their product lines.
PARC provided a unique environment for scientists and engineers where they can come in and work on their dream projects. So, lack of talent was not a problem for PARC. With all the brain power they had, it's not surprising that many inventions came out of PARC. The first major invention to come out of PARC was the laser printer. However such a printer demanded a different, more graphical way for computer to prepare the documents. But such a device did not existed at the time. So, like the ambitious geniuses they were, they invented their own screen to solve that problem and Alto was born. Alto had a display the same size as a printed page and featured full raster-based, bitmapped graphics at a resolution of 606x808.
The next natural step in the evolution of Alto was the development of a graphical operation system for users to interact with and prepare their documents for printing. Alto had a word processor, a bitmapped graphics editor like Paint, and a few fundamental apps. Prior to the invention of Alto, most apps and OSs were text based. When we think of UX we usually think of graphical user interface these days but UX is just as important for text based applications as well. And people had been doing it enough to develop a sense of good and bad, and also tools around it to make it easy to develop text based applications.
Text based programs and GUIs have different dynamics and goals. The information density in a text based program may not be that distracting and may even be preferred. Or a text based application may not even have a long running UI but rather work with commands and pipe inputs and outputs. Not all the concepts in a text based program can directly be mapped to a GUI program.
The information density in a text based program is more practical than the one in a GUI program. You can a dozens of different actions in a single screen. If you show an end user the UI of Oberon, it's very likely that they will be lost and give up in a matter of minutes.
If you look at a modern app, you will notice a much different experience. Information density is carefully controlled to not bog down the user. You are often presented with just a few data points (unless you are looking at pages like dashboards.), and it's easier for an everyday person to pick it up and start using it faster.
Understanding this distinction and knowing that they need a new way to write consistent user interfaces, researches at PARC realized that they can't keep developing the user interfaces the same way they've been doing before. So, in the true spirit of trailblazers, they created a new programming language and development environment to tackle this problem. Their next invention was Smalltalk.
Smalltalk is the first object-oriented programming language and environment. When Steve Jobs famously visited Xerox PARC, the Smalltalk GUI inspired him on how the Lisa and Macintosh should work . Smalltalk is a classic example of how certain problems require a complete new way of thinking to be solved. When the tools at your disposal are not sufficient to solve a problem, as an engineer you create new tools. And that's exactly what researchers at PARC did.
" Show a context menu in Smalltalk " menu := PopUpMenu labelArray: #('circle' 'oval' 'square' 'rectangle' 'triangle') lines: #(2 4). menu startUpWithCaption: 'Choose a shape'
The next step in the evolution of UI development is the domain specific languages (DSL) for
describing a UI which then gets translated to the native code. XAML, Qt's
.ui format, and many
others. One thing that you'll
notice in these DSLs is that they are all utterly unreadable by a human. They are all meant to be
used by an interface builder.
In my experience, and the experience of people I've worked with, these interface builders are rarely useful and most of the UI work is done by a developer who prefers his text editor to the interface builder. So, these interface builders mostly serve as a way to quickly put together a UI for prototypes or sample codes. In complex projects, I see code more often than DSLs for describing the UI.
<!-- The same menu representation in Qt's *.ui format. --> <widget class="QMenu" name="choose_a_shape"> <property name="title"> <string>Choose a shape</string> </property> <addaction name="actioncircle"/> <addaction name="actionoval"/> <addaction name="actionsquare"/> <addaction name="actionrectangle"/> <addaction name="actiontriangle"/> </widget>