So, after almost two-month break we continue our discussion.

During this period I was able to celebrate my birthday. In honour of it I have ordered Alan Cooper's books "The inmates are running the asylum" and "About interfaces" which for a long time already I wished to read.

So, from the first book we have learnt that asylum is the world in which the software starts to play the increasing role, and inmates are developers. From them eventually depends how much convenient for us will these products. Often programmers write so as comfortable for them, and for people such as they. The logical conclusion from this: programmers should not be engaged in interaction design at all. Interaction designers should start the work before code writing. Certainly, from any rule there are exceptions, it is necessary to remember that Alan Cooper - in the past the programmer. That is why I still believe that my attempt to combine in itself both the programmer, and the designer for this project can be not unsuccessful.

The most important thing that I have taken out from both books is a method goal-directed design grounded on personas creation. Personas are invented users of your system who eventually help to be oriented to their specific goals and to avoid a problem so-called "Elastic user". The user becomes elastic when we arguing necessary functions like "the user may need the command line" (may need, but may be not). Personas get rid of this annoying ambiguity to the clear thinking like "John will use the command line, and here it precisely is not necessary to Ann. But our product is more aimed at Ann...".

Therefore in the future we waits curious enough task of creation of the whole family of personas to make our attempt of design unDE more purposeful.

As to the second book the half its makes detailed retelling of technical details of techniques described in the first book. Here already there are no those fine examples of designing and in general all process in details seems not so romantic :-) You start to understand that the designer work is very hard.

From second half of book "About face" I expected much more, than simply listing of all existing interaction units and actually a little was disappointed.

Nevertheless I will tell about the most interesting thoughts arisen in process of reading. First, reading about cancel system, I have suddenly understood that typical operation of removal of the text is too cancel, text entering cancel. It is theoretically possible to implement cancel so that BackSpace became not simply removal, namely cancel in the selected context. Thus with the first pressing it may cancel formatting in the text selection, and already the second -- input of various fragments of this text. Redoing (e.g., in the form of Insert key) will be strictly responsible for reentering before removed text and its repeated formatting.

Such idiom at good elaboration may become excellent turn in perfection of cancel system.

Other thought which was accurately stated by Alan Cooper on pages of the book is a positive feedback in the audio form. It means, it is necessary to make sounds for not negative events of errors, but for positive events of system (successful job finish etc.). Alan Cooper asserts that sounds in computers usually irritate not because it is nasty, but because they accompany always negative events. Negative events should be accompanied by silence. Actually I and earlier thought that the sounds in games in many respects helps to handle characters, unlike work software. Including vocal hints like "You are under attack" or "Not enough money" appear rather useful. But why in working environment it is all not so cheerfully I did not understand.

If to speak about matching of ideas of Jef Raskin and Alan Cooper it is important to mark that Jef Raskin - in many respects the designer of the whole computers and operating systems, and Alan Cooper specialises on concrete solutions usually for Windows OS. Often they proceeding from different premises come to one conclusion. For example Jef Raskin tell "no" to dialog boxes with one button "ОК" on the basis of its zero information volume for system and because it creates yet another mode. Alan Cooper gives reason for the position that thus the developer accuses the user in errors of program, or program boasts of achievements (here I have thought that in the dialog box like "file saved successfully" is short of buttons "Attaboy!" and "Take a pie on a shelf ") and, certainly, such message is capable to break a flow of consciousness of the user.

Also Jef Raskin somewhere wrote that scrollbars are obviously not an intuitive component of the interface. I, of course, would not believe Jef if myself did not see as the person far from computers, meaning that the document needs to be scrolled down, showed hands upwards (having in view movement of document, instead of camera). Alan Cooper considers it as a good idiom of modern interfaces though does not recommend to use horizontal scrolling for the text data.

Jef Raskin describes the Zoom-interface as a fine idiom of interaction. Alan Cooper says that Zoom is usually clear only to IT experts, and logical Zoom is at all clear only to developers.

Jef Raskin writes that the idea of applications is not so good and that close integration is necessary to user, but Alan Cooper does mention nothing similar.

In this connection it is possible to come to a conclusion what to have the own opinion always useful and it is impossible to rely on masters of designing of interaction always.

Coming back to Blender 3D, I will tell that having read Alan Cooper's books, I have suddenly understood that its powerful interface which it is impossible to understand without the detailed documentation, is a consequence of bad (absent) designing. As a matter of fact in many respects it is simple a heap of functions. However it is impossible to forget also that initially it was designed for usage in a narrow circle of designers for which it was the professional tool. Initially many Blender functions were are accessible only with shortcuts. Certainly, it partially justifies such design, nevertheless improving of a product for an average user you in many respects do better and for professional.

На изображениях статьи вы можете видеть всю мощь процедурных текстур: это морской пейзаж, горный ночной пейзаж, ковёр. Апофеозом этих возможностей является модель глаза. Она примечательна не только тем, что полностью состоит из процедурных текстур, но также обладает эффектом красного глаза, когда источник света светит в зрачок прямо. Вены на глазу видны только с краёв, даже если мы попытаемся посмотреть на него сбоку. Наконец легко сделать так, чтобы расширение зрачка регулировалось одним единственным числом (от 0,0 для максимально расширенного зрачка до 1,0 для максимально суженного). На рисунках вы можете видеть кошачий глаз с расширением 0,44 и 1,0. On images of article you can see all power of procedural textures: it is sea landscape, mountain night landscape, carpet. Apotheosis of these possibilities is the eye-ball model. It is not only completely consists of procedural textures, but also possesses effect of a red eye when light shines to pupil directly. Veins on an eye are visible only from edges even if we will try to look at it sideways. At last it is easy to make so that the pupil extension was regulated by a number (from 0,0 for as much as possible expanded pupil to 1,0 for as much as possible narrowed). On images you can see cat eye-ball with 0,44 extension and 1,0.

To a great regret all miracles of procedural textures are not accessible at rendering in real time in game engine mode (all textures then remain simply grey). All effects which it is possible to see on these images are reached with long and painful calculation of the processor without involvement of graphic accelerator. Naturally such state of affairs does not suit for the project purposes. I still should learn how it is necessary to use textures that they were visible in game engine.

Certainly, we are still very far from practice, but having read Alan Cooper's whole book, in which thread runs that designing should be detailed and should be made before code writing, I do not want to hurry. I hope that those 5,5 readers who read this blog consistently not too will take offence at such circumstance of affairs. But when coding will start and the project becomes known already nothing will stop it.