MY MANIFESTO FOR A BETTER COMPUTING SYSTEM

[gusl]

This morning I woke up pissed off because Windows rebooted overnight, forever erasing some notes I had. This motivated me to refine my ongoing manifesto, so it could be LJed. The ideas here are obvious, but it looks like they have escaped pretty much EVERYBODY who ever designed large computing systems.

I used to dream of starting a system from scratch, and writing all my programs for my system, so that over time it would develop into an optimized environment for its user (i.e. me). For a while, I had faith that Linux with all its open-source goodness, had done that most of the work for me, and all I would have to do was implement my ideas. Unfortunately, I never became well-versed enough with the system to find out if that was going to be possible. A year or two ago, I ran into the TUNES website, and realized that I wasn't the only one with a dream. In fact, these guys have been way ahead of me for a long time. Anyway, I think it's a good idea to write down *MY REASONS* for wanting a different approach to human-serving cybernetic systems (i.e. personal computers).


If you know of any systems implementing my ideas or solutions to any of my concerns on a Windows platform, please leave a comment. My goals fall short of Faré's goals. (btw, this website is definitely worth checking). Faré actually calls his ideal "computing liberalism" (in the sense of "libertarianism"), and accuses present systems of computing statism / conservatism, but I fail to see the analogy.


How computing systems should be, but aren't:

User control over the machine
All I want is to be able to access all inputs and outputs of my machine, with suitable abstractions. This shouldn't be too hard, as there already exist thousands of drivers out there for most data media, both input and output. Yet, it never seems trivial for the programmer to access these ports. Many of my frustrations have had to with finding graphics and sound libraries for different languages.

Programs should be written flexibly
As a rule, analysts and programmers can't predict how their users will want to use their system. People who spend a lot of time using the same program end up becoming experts at it, but at the same time, they eventually run into a wall, and can't improve their efficiency further. This is when they start noticing the limitations of the program. Thus, programs should be written in fine-grained open-source modules, so that they can be easily customized. Compilation and packaging shouldn't protect users from acessing internal functions of a program. The user should be able to EASILY change how the system and its programs do anything.

Meta-programming and Scripting
People today do many repetitive things on their computers. In fact, we have developed typing/clicking scripts in our heads to get through these annoying processes. This is a sign that the user and the system are not communicating properly. It is an incentive for the user to enter input without thinking, which can be a dangerous thing. The user already has to sort out his own problems: communicating with the machine shouldn't be another problem on his mind (even if this communication problem tends to consist of dumb, busy work). Through meta-programming and scripts, users would be free to optimize their actions. In Windows, there exist scripting options, e.g. Unisyn AutoMate, but since 99% of programs have closed interfaces, it becomes a huge pain in the ass to program scripts to click in the right spot on the screen given the right conditions, etc, etc.

Program Editing at Run-time
Users should be able to change the programs they are using at run-time. The current paradigm of edit-compile-run does not allow this. I think some people at TUNES are trying to solve this with a Lisp-like language. Programs would run by constantly interpreting their script. Any changes on this script would be reflected in the program's execution. Voilà.

Backtracking
A history of the state of the system (and all subsystems, e.g. individual processes) should be kept. It should be easy to go backwards and forwards through all user actions. It should be easy to combine aspects of different historical states.

The System Should Always Listen to the User
User input processes should have absolutely first priority. A frozen system is inexcusable. A command to end a process should be obeyed immediately.

Consistent Programming Interfaces (TUNES: Unification)
For the programmer, as well as for the user, there should be no difference between accessing something from memory or something from the hard disk. I can probably come up with similar examples.

Files and Stuff: Where Things Are
On my ideal system, files, objects, etc on disk/memory are multiply indexed for search purposes, each index as specified by the user, and there may be many directory trees, if this is found to be convenient. Files are not inside directories: everything is shortcuts. To each file, the user can attach information of any structure, which is searchable in a virtual "database of files". See AskSam.

Orthogonal Persistence
Files should be saved automatically as you type them. If you're not sure you want to commit to your changes, you should work on a copy. A user's work should never be lost due to not saving it on time!

End Modal Dialogs
Remember: the user is the boss. Modal dialogs prevent the user from accessing the information they need. I often need to close them and check the info I need before I can re-open them and finally do what I intended to do.


IDEAS ABOUT MEDIA / SOME USEFUL USER AIDS:

Planning of User Activities
Program to assist the user in planning his to-do list and specifying his goals
(chunked tree of goals, subgoals, etc. with most details unspecified, kinda like the "MS Project tree")

Let the user organize his current processes as he desires. Imagine a user doing 3 unrelated jobs at once, each involving a browser, an email message and a document editor. Most interfaces would organize the processes by application, which makes no sense. The user can get lost trying to find his precious window, because it is not in the right place.

Diagram Maker: Simple application for editing arbitrary structures (usually special cases of Graph) as a diagrammatic aid for the user. Maybe it could work as a semantics for the content. Maybe these documents coule be considered as records for search in super-queries

Links between applications: all we have today is Copy / Paste. Dragging should be encouraged.

In some programs, actions or commands can be awfully hard to find. It should take only keystroke to search for a command. Shell-command interfaces can be a good alternative to menus or pop-up lists.

Customizable interfaces: Self-Editable Programs
As part of optimizing his experience, the user should be allowed to change menus, shortcuts, etc. from within the program's normal interface. By holding a special key, the user can preview what an action will do, and change it if desired. Maybe SmallTalk does something similar to that.

I welcome any questions, comments, suggestions, etc.

Addition:

RELATED LINKS:

Windows Annoyances

Dertouzos: Author of "The Unfinished Revolution"

David Gelernter: THE SECOND COMING — A MANIFESTO


Comments by John McCarthy

"Unfortunately, the making of computer systems and software is dominated by the ideology of the omnipotent programmer (or web site designer) who knows how the user (regarded as a child) should think and reduces the user's control to pointing and clicking. This ideology has left even the most sophisticated users in a helpless position compared to where they were 40 years ago in the late 1950s." -John McCarthy

Comments

[pyran.livejournal.com]

This is very, very interesting, and as soon as I get some more time (such as when I'm not about to go off to bed) I plan on following all of the links, something I suspect will take awhile. :-) However, at first glance one issue immediately springs to mind: customizability vs. ease of use.

Most of the problems that I see with most applications (including, I must admit, programs that I myself write) stem from the issue of who you're writing the app for. In a very broad sense, there are two basic types of users in the world: the ones who want to customize everything until it's just perfect, and the ones who are pretty much happy with the app as it comes (I'm over-generalizing deliberately -- for the most part even those people who fall somewhat in-between and customize using options/settings are generally happy with the app out of the box, with only a few exceptions). The more customizable a program is, the more complicated it inevitably gets, and the more complicated it gets, the more overwhelming it is to users who are generally happy with how the app functioned right out of the box. So a major issue is how to make an application as customizable as possible -- even, as you point out, to the extent of being able to change core functionality -- without making it so loaded with customizable scripts and options that it's overwhelming to the average user.

I call this the "Grandmother Test". If my grandmother can look at a program and stand a reasonable chance of learning how to use it, the application can be assumed to be useful in the mainstream. If not, it should be targeted primarily at power-users.

As an aside, I think this is one area in the Windows-Linux-Mac debates that is often overlooked by one camp or another (although I find it most often overlooked by the Linux camp). One reason Macs are popular is that the OS is so simple to use that anyone can figure it out pretty quickly. On the other side of the spectrum is Linux, which is so configurable as to be able to become nearly anything, at the cost of ease-of-use -- learning how to use it is not necessarily a simple task. Unfortunately, Windows isn't much of a middle ground: it tends to go 80-20 towards ease of use; that is, it is not quite as easy to use as a Mac, but nowhere near as customizable as Linux.

This may have turned out to be more long-winded than I had intended, but my point is that in the quest for greater customization of applications towards the user, it should not be forgotten that the perfect program that is nigh-impossible to learn to use and customize correctly is effectively useless.

Once I get a chance to follow up on all of the links, I'll add more thoughts here as I think of them.

[gustavolacerda.livejournal.com]

I'm glad you're interested. I love to spread these computer revolution memes.

If you consider programs as static, then indeed, there exists a dichotomy of ease-of-use vs customizability. But, ideally, the program (at least the visible part of the program) evolves with the user. Whenever a user runs into a "wall" (as described in my post above), he could either unlock the advanced options he wants or write his own commands (hopefully in an intuitive visual language tying program variables to "user variables" in obvious ways).

Seriously, a small FAQ about how to optimize the commonest use cases would be a huge improvement in many existing applications. I kinda feel like my suggestions are an extra luxury, given what's missing today.

The reason some programs are hard for the beginning user, e.g. your grandmother, is that they give the user too many choices, and it becomes hard to find the simplest commands.

Maybe the above statements don't apply to some kinds of programs. Can you help me think this through?

[pyran.livejournal.com]

Absolutely I'll help think this through -- I think the ideas you've presented are very, very good, although there are still some major hurdles that need to be cleared for them to really be able to take hold.

I've begun reading some of the links you provided, and I find TUNES especially intriguing. However, I'm still having a hard time with one thing: the assumption is that the average user can do all of this.

You're absolutely right -- often the reason people think a program is over-complicated is that they are presented with far too many options. Hell, look at MS Office -- let's face it, the settings screen for damn near everything is overwhelming. However, is it really any better to present the user with an entire language to allow them to change a program? If people wanted to script everything, they'd all be programmers. Most people have neither the time nor the inclination to do so. However, what if the application could make these changes transparently? Really, you'd just need baby steps -- change small things one piece at a time. Take an example: if the user constantly needs to be prompted to save their work on exit, and they always click yes, then why not auto-save on exit? A little pattern recognition by the app would go a long way towards transparently customizing a program, in much the same way a Tivo records some TV shows without prompting based on what it thinks you would like to see.

There is something to be said here for inertia. Many people don't care to customize a program, as they don't really give a damn what it does, provided that it does what it's supposed to. So often if you're going to customize a program, there shouldn't be prompting and scripting. Of course there should be an option to do so, but once again, take my grandmother: if you ask her to write a script to change stuff, she'll say no. But if the program does what she wants it to do without her prompting, she'll be thrilled.

So my point is that perhaps there shouldn't be an explicit wall for a user to run into -- if an app gets to a point where the user is stuck, the app isn't really doing its job. Instead, the app should be constantly adjusting to accomodate the user, all the while giving the user the ability (e.g., through scripting or whatnot) to make large-scale, non-trivial changes if necessary.

Or am I going too far here?

[gustavolacerda.livejournal.com]

I am trying to bridge the gap between user and programmer. I tend to become a power user at anything I use long enough (i.e. I become restricted by my tools, no longer by my ability), and I guess the only way to improve one's tools is to be a programmer in some form or another.

A user who isn't willing to be a programmer (i.e. work on his tools), should accept the tools he already has (either that or depend on somebody else's help). Programming doesn't necessarily have to involve messing with ugly code in a text form. In fact, given a smart enough environment, one can program by demonstration (see Henry Lieberman), by answering questions, or using some graphical programming language (though I haven't heard of the latter two)(granted, text-based programming is the most powerful, at least for now). The idea is to allow laymen to be programmers without too much effort. But all of this is far from a satisfactory solution to my concerns.

I guess my goal is to create (development) tools to help people to improve their (application) tools. But this requires the application to be written in specific nice ways.

However, what if the application could make these changes transparently? Really, you'd just need baby steps -- change small things one piece at a time. Take an example: if the user constantly needs to be prompted to save their work on exit, and they always click yes, then why not auto-save on exit? A little pattern recognition by the app would go a long way towards transparently customizing a program, in much the same way a Tivo records some TV shows without prompting based on what it thinks you would like to see.

I, for one, like my programs to be predictable. I don't want them learning my behaviors without my control or supervision, since they could learn wrong behaviors. Besides, some user behaviors may be too complex to be figured out statistically. Not only that, but some improvements (probably the most important ones) involving adding new concepts, and are inherently more complex than changing a yes/no setting (such as "Save Automatically?"), and would require a new *programmed* module for modeling the new concept (dumb example: you want to improve Notepad so that it uses multiple fonts on the same document, you would have to re-create the concept of font (in this case the font becomes a property of each character, instead of the document): the program will never learn that by observation).
Basically, you can't get away from logic.

But then again, yours is a good idea in some cases. Maybe the program could warn the user before using its new, learned behavior. Microsoft sometimes does this, but without warning: remember how only the most used apps in would show in Windows XP's Start Menu, unless you clicked for more? I hate that.


Or am I going too far here?

No. It's only too far when you lose sight of what you are doing there. ;-)

I want to study more cases of "walls", and see where my theories need more work.

Learning and reversibility

[fare.livejournal.com]

I, for one, like my programs to be predictable. I don't want them learning my behaviors without my control or supervision, since they could learn wrong behaviors.

One simple solution to this problem is in reversible computing, not unrelated to the "backtracking" feature you mentionned: never learn any behaviour that isn't reversible, and have the learning be reversible itself. Hence, you can undo any change that was brought by the program learning something, and you can undo this learning and prevent it from happening again. This adds the "control and supervision" you need before you may accept learning. On the other hand, special care should be taken to avoid the user committing a change that means more than he thinks, or otherwise being confused by reversible changes that would nonetheless corrupt results of computations in a subtle way. In other words, learned behaviour should never alter misleadingly the perception by the user of the underlying documents being manipulated.