Warren Teitelman described a lot of the great work done at Xerox PARC in "Ten Years of Window Systems - A Retrospective View" in the book "Methodology of Window Management," Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985.
"Both James Gosling and I currently work for SUN and the reason for my wanting to talk before he does is that I am talking about the past and James is talking about the future. I have been connected with eight window systems as a user, or as an implementer, or by being in the same building! I have been asked to give a historical view and my talk looks at window systems over ten years and features: the Smalltalk, DLisp (Interlisp), Interlisp-D, Tajo (Mesa Development Environment), Docs (Cedar), Viewers (Cedar), SunWindows and SunDew systems. The talk focuses on key ideas, where they came from, how they are connected and how they evolved." -Warren Teitelman
It's a wonderful book with many interesting articles and working group discussions about window management and user interface architecture, that gives great perspective on a wide variety of approaches. I'm glad that it's finally available online!
This volume is a record of the Workshop on Window Management held at the Rutherford Appleton Laboratory's Cosener's House between 29 April and 1 May 1985. The main impetus for the Workshop came from the Alvey Programme's Man-Machine Interface Director who was concerned at the lack of a formal definition of window management and the lack of focus for research activities in this area. Window Management per se is not the complete problem in understanding interaction. However, the appearance of bitmap displays from a variety of vendors enabling an operator to work simultaneously with a number of applications on a single display has focussed attention on what the overall architecture for such a system should be and also on what the interfaces to both the application and operator should be.
The format of the Workshop was to spend the first day with presentations from a number of invited speakers. The aim was to get the participants aware of the current state of the art and to highlight the main outstanding issues. The second day consisted of the Workshop participants splitting into three groups and discussing specific issues in depth. Plenary sessions helped to keep the individual groups working on similar lines. The third day concentrated on the individual groups presenting their results and interacting with the other groups to identify main areas of consensus and also a framework for future work.
Part I of this volume gives the background to the Workshop, its scope and goals.
Part II consists of position papers, the invited presentations and an edited version of the discussion following each. The set of speakers covers a significant part of the expertise currently available. This section provided a useful summary of the state-of-the-art for the Workshop and highlighted the issues.
Each participant was asked to identify his major areas of concern prior to the Workshop. These have been condensed and integrated to give a view of the problems prior to the Workshop. Lists of issues were also generated from these contributions and the invited presentations. These formed an initial basis for the Working Group discussions reported in the next part.
Part III concentrates on the work carried out in the Working Groups with particular attention focussed on the Working Group conclusions and questions requiring further study.
Part IV presents the main conclusions of the Workshop and includes an Open List of questions requiring further study. This list indicates the current limits to the understanding achieved at the Workshop. As always, more questions were raised than conclusions reached. This part also includes a bibliography of the area and a glossary of terms used in the book.
The discussion sessions have been heavily edited. The Editors hope that no remarks have been attributed to individuals incorrectly. Copies of the typescript were sent to all participants for comment prior to publication.
The contents of this volume should not be considered as definitive conclusions but as a contribution to the study of methodology in human-computer interaction particularly with respect to single user workstations.
This book should be of interest to anybody with an interest in graphics and interaction in general. Many of the issues discussed have a more general applicability than the particular area under discussion. However, the primary audience is those directly involved in the area of the human factors and design of systems on high-powered single user workstations.
Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3.
One thing I like about Brad Meyers is that he's a strong programmer, as well as an excellent researcher, so he had a first-hand understanding of the real-world issues involved in programming languages and user interface architecture, unlike many academics who talk a lot of theory but never get their hands dirty. Brad Meyers understands where the rubber hits the road, and how important it is to have good tires.
At the time I worked on it, Garnet didn't have pretty graphics like Flash, but the underlying programming system had some advanced features that are sorely lacking from most modern user interface development environments.
Laszlo is an modern open source GUI programming system, with many of Garnet's advanced "natural programming" features like prototypes and constraints. Laszlo currently uses Flash as its virtual machine, but it's a much higher level way to program dynamic interactive web based applications, without using the proprietary Flash authoring tool.
Garnet had a true prototype based OOP system (somewhat like Self), which is great for gui programming, because guis have so many objects that look and behave like each other except for a few little customizations (like the layout, graphical style, data source and call-back behavior).
Garnet also had an automatic constraint system, which enabled you to simply define any attribute as a formula that depend on other attributes, without needing to worry about how and when the values were calculated. Garnet's constraint system automatically figured out the dependences of each formula, and automatically and efficiently recalculated and cached any values that needed to be updated, but only when necessary.
With constraints, you can make a button inside a window, and define its left edge to be ((parent.width - self.width) / 2), and it will automatically remain horizontally centered in the window from then on, without you (the programmer) having to worry about what to do when the parent window's size changes.
Without constraints, you have to manually write all the code that changes the button position whenever the window size changes, which results in code scattered all over the place in different classes and handlers and intermediate objects.
Constraints are much easier to use and more general purpose than resize handlers, springs and struts, complex MVC updating schemes, and other Rube Goldberg devices.
Constraints are especially useful for user interface programming, because they save you from having to write lots of annoying boiler plate and error prone code for handling updates (registering, chasing down dependencies, detecting changes, notifying updates, all happens automatically).
Constraints make GUI programming much easier, but they're also useful anywhere in your program where one value is defined in terms of other values that might change at any time.
Once you've tasted a programming language with constraints, you will not want to go back. Programming without constraints is like writing in machine language: error prone, low level, tedious, inefficient and mind numbing.
Constraints are like structured programming for variables: In the same way that it's better to use loops and conditionals instead of gotos, it's also better to use declarative programming that says what you mean, instead of imperative peeks and pokes and side effects.
Constraints let you write easy to read code, and concentrate on the interesting high level stuff that matters. You can go back later and change the layout of a complex GUI, without rewriting lots of fragile layout and event hanling code. Look at any MFC program to see how bad it can get without constraints.
Constraints are natural and close to the way you think, because they let you declare a variable and the formula that defines its value in one place, instead of scattered all around the code. They off-load the tedious task of tracking down and maintaining all the dependencies from the programmer to the computer, which is much better at that kind of stuff.
Garbage collection is like constraints: the computer can do a much better job than the human at performing the task perfectly, so spending some cpu time on automatic garbage collection and constraint maintenance is well worth the significant increase in programmer productivity and software reliability.
Garnet had a prototype based object system. It was implemented in Lisp with a system called KR (Knowledge Representation, classic AI "frames" with slots and inheritance). KR was extended with an automatic constraint system that parsed the formula expressions (written in Lisp macros), figured out the dependences, wired up and maintained the dependency graph.
An expression like "((parent.width - self.width) / 2)" would depend on self's width slot, self's parent slot, and parent's width slot. If any of them changed, then that formula would be automatically invalidated, and only recalculated on demand when it (or something that depended on it) is required.
The cool thing was that you can make a prototype object, like a button, which has sub-structures like a label, border, drop shadow, etc. The sub-structures can be constrained to the button's dimensions, the label is centered in the border, and the drop shadow floats below and to the right, so the button's layout is automatically updated when it moves or resizes.
The text color and border fill can depend on the button's "hilight" variable, so they automatically switch between bright and dark when you press the button (the input handler just toggles the "highlight" variable, and the graphics that depend on it are automatically updated).
Now that you've composed and constrained a button to look and feel how you want, you can use it as a prototype to make other similar customizable buttons instances. Each instance can itself override the prototype's graphical properties, label text, action, etc.
Instances of a prototype all magically inherit (instances of) the sub-structure of the prototype! It all just works the way you'd expect it to (with a lot of plumbing going on automatically behind the scenes). There's no need to make a separate class for each different style of button or action - prototypes let you customize any instance itself!
Like Garnet, Laszlo is an advanced open source user interface development environment that supports prototype based OOP with constraints.
Unlike Garnet, Laszlo deeply integrates recent trendy technologies like XML, JavaScript, Flash, data binding, networking, XML/RPC, SOAP, ReST, Java and Tomcat.
Laszlo has a class/prototype based object system, and it (currently) uses the JavaScript runtime in Flash as its virtual machine. But it's more than just another way to program Flash.
Unlike raw Flash, The Laszlo language is easy to learn and Laszlo programs are easy to read and write thanks to prototypes, constraints, declarative programming, and instance-first development.
I wrote that article about nine years ago, and OpenLaszlo never took over the world the way I hoped it would, but Max Carlson, one of its chief architects, is working on reimplementing the good parts in JavaScript/CoffeeScript, without all the baggage. It's a work in progress and not very well documented, but it embodies some wonderful ideas!
Oliver Steele, another of OpenLaszlo's architects, has written some great stuff about "Instance First Development", a declarative, prototype and constraint based approach to programming modular components that OpenLaszlo supports.
And no SQL keywords allowed in passwords. Because they like to advertise that they don't bother escaping user input before concatenating sql strings to store plain text passwords in the database.
The PHP manual pages are full of user comments with helpful suggestions just like that, which incompetent programmers copy and paste into production systems. But I think of it as a good thing, an instance of evolution in action, because banks that hire such stupid programmers deserve to have all their money stolen from them.
And don't forget to immediately revoke your old marriage certificate, reissue a new one, and invalidate all your old keys and cookies, or else your relationship is vulnerable to a man in the middle attack, like Dr. Frank-N-Furter did to Brad and Janet! [1]
Well Ted Nugent (not to mention Ann Coulter) got away with calling Obama a "monkey," and he's the highly respected darling of the GOP, whose endorsement is sought after and appreciated by not only Republican senators and congressmen, but Mitt Romney himself.
(I'm not endorsing anyone's behavior here, just pointing out how low the right hand side of modern American politics has degenerated, to provide some perspective.)
At the National Air and Space Museum reception during Washington DC EduCom in 1988, I took a big bite out of one lobe at the bottom of a three lobed red bell pepper so it looked like an alien's face, and held it up to Steve Jobs, and said "Earthman, give me your seed!"
"Both James Gosling and I currently work for SUN and the reason for my wanting to talk before he does is that I am talking about the past and James is talking about the future. I have been connected with eight window systems as a user, or as an implementer, or by being in the same building! I have been asked to give a historical view and my talk looks at window systems over ten years and features: the Smalltalk, DLisp (Interlisp), Interlisp-D, Tajo (Mesa Development Environment), Docs (Cedar), Viewers (Cedar), SunWindows and SunDew systems. The talk focuses on key ideas, where they came from, how they are connected and how they evolved." -Warren Teitelman
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
It's a wonderful book with many interesting articles and working group discussions about window management and user interface architecture, that gives great perspective on a wide variety of approaches. I'm glad that it's finally available online!
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Preface
This volume is a record of the Workshop on Window Management held at the Rutherford Appleton Laboratory's Cosener's House between 29 April and 1 May 1985. The main impetus for the Workshop came from the Alvey Programme's Man-Machine Interface Director who was concerned at the lack of a formal definition of window management and the lack of focus for research activities in this area. Window Management per se is not the complete problem in understanding interaction. However, the appearance of bitmap displays from a variety of vendors enabling an operator to work simultaneously with a number of applications on a single display has focussed attention on what the overall architecture for such a system should be and also on what the interfaces to both the application and operator should be.
The format of the Workshop was to spend the first day with presentations from a number of invited speakers. The aim was to get the participants aware of the current state of the art and to highlight the main outstanding issues. The second day consisted of the Workshop participants splitting into three groups and discussing specific issues in depth. Plenary sessions helped to keep the individual groups working on similar lines. The third day concentrated on the individual groups presenting their results and interacting with the other groups to identify main areas of consensus and also a framework for future work.
Part I of this volume gives the background to the Workshop, its scope and goals.
Part II consists of position papers, the invited presentations and an edited version of the discussion following each. The set of speakers covers a significant part of the expertise currently available. This section provided a useful summary of the state-of-the-art for the Workshop and highlighted the issues.
Each participant was asked to identify his major areas of concern prior to the Workshop. These have been condensed and integrated to give a view of the problems prior to the Workshop. Lists of issues were also generated from these contributions and the invited presentations. These formed an initial basis for the Working Group discussions reported in the next part.
Part III concentrates on the work carried out in the Working Groups with particular attention focussed on the Working Group conclusions and questions requiring further study.
Part IV presents the main conclusions of the Workshop and includes an Open List of questions requiring further study. This list indicates the current limits to the understanding achieved at the Workshop. As always, more questions were raised than conclusions reached. This part also includes a bibliography of the area and a glossary of terms used in the book.
The discussion sessions have been heavily edited. The Editors hope that no remarks have been attributed to individuals incorrectly. Copies of the typescript were sent to all participants for comment prior to publication.
The contents of this volume should not be considered as definitive conclusions but as a contribution to the study of methodology in human-computer interaction particularly with respect to single user workstations.
This book should be of interest to anybody with an interest in graphics and interaction in general. Many of the issues discussed have a more general applicability than the particular area under discussion. However, the primary audience is those directly involved in the area of the human factors and design of systems on high-powered single user workstations.