[Oberon] Re (2): Project Oberon: New Edition

[eas lab]

]>  short-term memory limited to ca. 3 items;  recognision is not limited by
]> memory.
]> This automatically leads to the menu-concept, which TUI has.

> I think you'll find that the short-term memory item number is closer to
> 7-8 items. 8-digit telephone numbers are pushing the limit.

That's not short-term-memory, like 6 names flashing past in 10 seconds.

> A book that I have recommended previously for those interested in the
> design of man-machine interfaces was written by Alan Cooper (the "Father
> of Visual Basic").

I often wanted to see if 'visual-basic' confirms my claims.

]> Most non-trival tasks needs 4,5,6 files visible/accessible at once.

>Not focusing on the human psychology though, are they?

Who 'they'? The tasks? The <potential> tasks emerge spontaneously via entropy.
eg. my new kick is not to read big-complex texts; but to lie down and listen to
TextToSpeech when I'm tired. So far I'm using a 6v-Acco powered rPi, where the
sole control to (remove-from-stack or demote-to-later-play) the *.wav files
is the on/off-switch, switched during the applicable prompt.

When I put new sound-files on the play-stack and clean-out old ones, I need
to see: the play-stack, the source-text, the corresponding sound-file
all together on the same screen; plus the menu of applicable commands.
If I lose sight for 1 second to switch views, chaos ensues!

Training yourself to do repetative tasks is not, the same as having the
tools to handle a new complex task.

The fact that the PC market gravitated to monster-browsers which do:
http-fetch, mail, USEnet, and display various formats so that all
facilities are 'at hand', confirms that people can't be expected
to remember where stuff is saved.

But the monster-app approach is wrong for serious computing.
The correct order of importance is:
 you, your knowledge, your data, your file system, your utiltiy/s=last.

The utilities need to be able to roam around your file system,
like the secretary used to visit the filing cabinets.
If the secretary dies/utility-is-replaced, your data still survives.
LEO is especially good for this. You can navigate your file-tree eg. via
the VISUAL/TUI mc [clone of the DOS:nc], and then launch a new LEO at the
appropriate directory, which contains the emails, articles, diagrams..etc.,
for that specific project. But of course, entropy ensures that other files
outside of the directory of the project will need to be accessed, and
seen together on the SAME-screen, which LEO handles too.

Or if it's a simple task, you can launch a new LEO <from the canteen, where
he's having his lunch, and he can reach out to all the dir-nodes needed,
from there>, which is what linux-based:V4 does.