gusl: (Default)
gusl ([personal profile] gusl) wrote2003-03-15 12:48 am
Entry tags:

MY MANIFESTO FOR A BETTER COMPUTING SYSTEM

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

[identity profile] pyran.livejournal.com 2003-03-15 01:17 am (UTC)(link)
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.

[identity profile] jetcat.livejournal.com 2003-03-15 08:00 am (UTC)(link)
> 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!

i don't really know anything about programming, but i'm one of those few ppl who isn't satisfied w/ either Windows/MacOS or linux. as such, i have one windows box and one linux box. i have copies of certain files on both systems--those that i like to be able to read/update on both systems, and those that are important enough that i want them backed up, but more accessible than if i were to burn them to cd, for example. anyways, i've always thought it would be REALLY nice if when i have the two (or multiple) computers networked, i had the option to say that i want to have certain files "linked," so that when i make (and save) changes to the file on one computer, the copy of the file on the other computer is automatically updated and saved. would this be possible?

[identity profile] selfishgene.livejournal.com 2003-03-15 11:48 am (UTC)(link)
Cool ideas, Gus.
I like that whole list; especially the part about frozen systems. I drives me crazy when I type a sentence and the screen stops echoing my characters for 5 seconds while some other processes gets control. I thought preemptive multi-tasking was supposed to stop that issue.
One (hardware) thing you didn't mention was larger screens. I think a lot of hassles will go away when we have cheap flat panel screens, preferably concave to allow constant focal length. I would like a screen literally as wide as my arms can reach. This kind of screen will allow users to simply drag stuff into or our of the central focus but still be able to look at items on the periphery.

[identity profile] simonfunk.livejournal.com 2003-12-10 01:43 pm (UTC)(link)
Hey, finally a moment to comment (mostly related to the language/programming aspects):

I share your goals completely, and those of Tunes, but I have been frustrated over the years at the brittleness of any direct approaches to these problems and at this point I believe they need to be tackled at a more fundamental level. Tunes, for instance, claims it is just a matter of integrating all the existing pieces. But I believe it is the manner of integration itself that is the true missing piece.

What you are looking for, I think, is not more attributes to your programming language, but new fundamentals benieth it.

To be concrete: existing code, in any current useable language, specifies How, but not What or Why. Look at the comments above methods or prototypes in well-documented code, and you will find they are more useful, and longer-lasting, than the code itself. The code will be rewritten from context to context, but the comments often stay the same. Why? Because the comments express, as a chunk of knowledge, What the code does--and that is the real code, or should be. That is the chunk of knowledge that reflects what is in our heads, and it is how we think about the code, and how we decide when to use it and why (and that is what integration is all about...).

Imagine if we thought about our code in terms of the bodies of methods -- we would be unable to do anything more abstract with them. Yet imagine if I gave you a function foo(a, b, c) and didn't tell you what was in it -- it would be useless to you. This is the world visible to any modern compiler.

So, I ask: if you read the body of a method and/or the comments above it and understand what it does, what is that understanding, and how can it be written down? Can it be made more accurate than english, but more general and concise than code?

(And is the answer to that question necessarily full AI, or could it be just another programing paradigm? And can TUNES really succeed without answering that question? I realize it's not immediately obvious on the surface why not, but my suspicion is not.)


Anyway, my two cents. I reserve the right to change my mind about anything and everything on a moment's notice. :)