Software Is Film

"Software is a branch of movies. Movies enact events on a screen that affect the heart and mind of a viewer. Software enacts events on a screen which affect the heart and mind of a user, AND INTERACT. Much of software is about affecting the heart and mind of a user, and the interaction is an additional dimension to its moviehood. The technicalities of programming are no more relevant to the design of software than the mechanics of cameras are relevant to designing a movie: providing constraints and tradeoffs, but otherwise largely irrelevant. I believe that training in film-making is important to software design." --TedNelson (http://xanadu.com/zigzag/fw99/zxInternals.html)

With such a dismissive attitude of "the technicalities of programming", no wonder Xanadu was so successful.

Agreed. Such minor technicalities of film technology as the encoding of sound on the film for playback had no effect on the art of film.....

These criticisms of Nelson's statement miss the point. The point is that the value of software is determined by how well its users can understand it and take advantage of it. Nelson is not saying that technical achievement is worthless; he is saying that technical achievement alone does nothing to help users. All software developers need to understand how to communicate with users, not just how to make computers jump through hoops.

No, what Nelson is saying is that an understanding of the characteristics of the medium of software is largely irrelevant, and he couldn't be more wrong. The "technicalities of programming" are tremendously important to communicating with users: They determine what are the most effective ways to communicate. No medium is infinitely plastic. Anybody who thinks so belongs in academia, not out in the real world where we try to make actual things that are useful for actual people.

Remember that when Nelson uses the word "design", he is not talking about internal architecture or other implementation details. He is talking about what might be termed InterfaceDesign? or InteractionDesign, which truly does have nothing to do with the technicalities of programming.

There is nothing in Nelson's statement that implies that anything is "infinitely plastic". The technicalities of programming don't matter to users. Users need to know what the computer can and can't do, but that has little to do with whether the programmers are using Java or C++, or whether they are using binary trees or linked lists, or object-oriented vs. procedural programming.

Great films don't come from technicians doing great sound, great lighting, great makeup, etc. The technical work is a vital part, but what makes a film great has more to do with the filmmakers' understanding of what needs to be on the screen, rather than how to put it there.

To users, most software is nothing more than images moving on a screen. The screen is the medium between computer and user. Unfortunately, most programmers don't use that medium to communicate effectively. They know how to put stuff on screen, but don't know what stuff should be there. A study of how filmmakers and artists in other visual media work effectively would be beneficial to software designers.

Nelson may be full of it, but I think the critics on this page are guilty of focusing on one tiny part of his statement and inflating it into something ridiculous.

Okay, maybe I'm being unfair to Nelson's statement. Here's what bugs me about it, though: Throughout my life I've been involved (peripherally) in the development & critical discourses of many nascent media. And I'm sick to death of sloppy formal attempts to describe a new form (and its critical language) in terms of an old form. Role-playing games are theatre. Comic books are cinema. Programming is math. New media art is video. These comparisons always, always fail.

Nelson says training in film-making is important to software design, but I'm not exactly sure how that would work. Why should I go to film school, and learn about mise-en-scene, blocking, lighting, and scriptwriting, so I can design software, either as a programmer or as an interaction designer?

Yes, the user is paramount. Yes, we should value the user's needs over the programmer's cleverness. But how do we discover those user needs? By admitting we know close-to-nothing and studying the fields immediately related to ours? Or by brushing up on our Godard? -- francis

I think that learning about technical details like lighting would be against the sort of study that Nelson suggests. Nelson doesn't seem to be talking about the technical details. He's talking about aspects of filmmaking like increasing tension, visual metaphor, or how to tell a story visually. These are all things that software developers could definitely learn from, IMHO. -- BrentNewhall

Visual metaphor, and how to tell a story visually, can be learned much more directly from direct, less "creative" forms of communication. Instructional comic books and diagrams, graphic design, etc. EdwardTufte will be of more use here than, say, TerryGilliam. As far as increasing tension, I don't understand why that would be of use in software. Tension as in any sort of narrative medium serves to involve the viewer more fully in the story, song, etc ... Why do we want to involve the user that fully in our software? Shouldn't software just solve your problems quickly and elegantly so you can get on with living your life? -- francis

I can think of two answers to that: (1) Not all software is problem-solving. (2) Solving a problem can be a very complex process (for example, scientific modelling, which no matter what tools are available, requires a lot of construction and manipulation). The principle of rising tension can be an invaluable principle when approaching that sort of task. Note that the interesting bit is the principle of rising tension, not the emotion itself. -- BrentNewhall