www.rinner.st

the blog/wiki/website/homepage/internetpräsenz of Stefan Rinner

the current situtation

First, this document describes the situation in a very ‘black and white’ way. Yes, there are programmers who have a design education or at least care about design. Sure, there are designers who do programming themselves or understand the idea and the needs of programming.
However, usually programmers and designers do not share any common knowledge; they just share a common task. Both have to develop new ideas and they even do it in a very similar way.
Kent Beck, author of ‘Extreme programming explained: embrace change’, describes, for instance, the importance and benefits of drawing in the software-development-process: ‘First, there is nothing wrong with designing software using explicit pictures instead of purely mental or textual models of the system, and there is much to be said for a graphical approach. Trouble drawing the pictures can give you subtle clues about the health of a design. If you find it impossible to reduce the number of elements in the picture to manageable levels; if there is an obvious asymmetry; if there are many more lines than there are boxes. All of these are clues to a bad design that become evident from a graphical representation of the design.’ ([BE] p. 111)
In a common multimedia project, design and programming are seen as different steps in the process. First, the design concept is created. After its production, the finished screens are handed over to the programmers, and now everything should be moving and be interactive.
The designer is responsible for the ‘look’, the programmer adds some interactivity, and nobody cares about the result of this combination. Without a perfect look and feel, the project will not be successful. Projects will ‘work’ even if programmer and designers do not speak with each other at all – but something will be missing. ‘Programming is the process of abstracting a graphic form into its fundamental geometric components’ ([MA] p. 446)
In fact, it is not important that every designer can program and that every programmer is able to design. A huge step would be if both would appreciate the other’s work and would share common knowledge about the things which make multimedia so special – interactivity and motion. If both understand this, designers will develop applications which are more than a slideshow of nicely designed screens, and programmers will invest more work than just programming some tri-state-buttons and some nifty, but hidden gimmicks.
It would help if both think about multimedia development like game development – multimedia should offer a really h3 impact regarding visuals and interactivity, multimedia has to be immersive and not just informative or entertaining. André La Mothe defines a game and its development as: ‘A video game is more than a program; it is a conduit into another dimension, a dimension synthesized by the imagination and realized by sheer will. Technically, a video game is nothing less than a work of art.’ ([LM1] p. xxvii)

THE DESIGNERS’ VIEW

Multimedia is still a new medium and therefore many designers think the screen is just another type of paper or canvas. They think their task within multimedia projects is to place objects by using rules derived from centuries of experience in print design.
Sure, universities and other organizations have started initiatives to teach and explore multimedia. Most have concentrated again on the visual part of the design. Some have thought about reusing well-known rules from print design. Several new ideas of visual representations have been developed. Many have thought that the new and exciting part of multimedia is video, sound and non-linear content. But the idea that makes multimedia really special is sophisticated interactivity and motion – the things that evolve out of programming. Without code, multimedia is more or less the same as present day television.
Even if designers start to develop ideas about interactivity, it is hard for them to attain – or just to scribble their thoughts. To develop ideas for visual design, designers have perfect tools – their sketchbook and a pen. A sketchbook is not just handy for the development of a vision, it is also useful for presenting ideas. Designers use their sketches to express ideas which they can not describe verbally. Illustrating interactivity or motion in full detail using the traditional tools is rather impossible – ‘Writing programs to create illustrations never makes much sense to students because they can be drawn much more easily by hand. However, as interactions are introduced, the differences between paper and computer become clear to students of any level.’ ([MA] p. 430).

Talking about ideas concerning interactivity or motion is even harder due to the fact that no defined and common vocabulary has been established up to now. Designers have to rely absolutely on the programmers for creating their envisioned way of interactivity and therefore presenting their ideas in a concise way is crucial. Demonstrating ideas to clients is even harder and that is why a tool for easy and fast creation of prototypes is needed.
The current professional tools used for creating multimedia applications are designed for programmers. These tools – their metaphors and their graphical user interface - are intended for fast and smooth production and not for experiments. Although they allow a lot of manipulation via the user interface, more complex tasks, but even quite simple interactivity, rely on heavy scripting.
Other tools intended for experimentation, for instance Design by Numbers, are widely unknown, don’t offer any compatibility with industry standard tools and are often restricted in several ways – for instance customizability or extendibility.

THE PROGRAMMERS’ VIEW

Programmers are rarely involved in the design process. In some cases, there is even no contact and communication between the designers and programmers due to big and complex company structures or outsourcing.
Usually during the conception stage of a project programmers are solely concerned with requirements, schedules or cost estimations. Programmers who are interested in adding additional value to a project by using innovative techniques of interactivity have at least a way to develop and sketch their ideas, but the mostly low visual impact of their proposals doesn’t impress any designer.
Schedules in multimedia projects rarely work and the person responsible for programming is the last one in the production chain. Usually no time to follow one’s own experiments is available and programmers are mostly very defensive against ideas which sound complicated and time consuming. Everything which cannot be done by using some standard library, can become potentially time consuming.

For programming languages that are widely used in academia and industry a vast amount of ready-to-use algorithms is available and a huge number of papers and books discuss and explain various problems.
The industry standard tool in multimedia is Macromedia Director. Its programming language is so primitive that no computing science graduate would ever touch it and offers such a bad performance and so many awkward bugs that no one trained in high-level languages would ever think about using it.
Compared to C, C++ or Java the user-base is ridiculously small and therefore the number of public-accessible sources and amount of documentation is not sufficient. Programmers using Director have to rely on initiatives from other talented and philanthropic programmers on the web, presentations at various meetings and gatherings, reverse engineering of the competitor’s stunning works or on books intended for people using high-level languages.