Instantly loading programs — How to achieve that? —OR— Why humans still outrun machines in interaction

Probably from the beginning on, computers suffered a common lack: latency on user action. Therefore a computer, some time old, will always feel slow regardless how quick it was regarded once.

I’ve got an old i286 PC/AT here. Currently it has a 40 MB disk in it (I guess). As I want to get id of it but not just throw it away, I pondered whether I should put a 400 MB disk into it and see what nice software I could put there too.

Then I realized, despite the smalliness of the software I’d put there and how quickly it would load and exec on a current machine, there — of course — it would be awfully slow. Which brought me to the original insight.

However, I wonder whether it’d be possible to speed up software in general, including current one on current machines, especially the situation of latency you’re encountering everywhere and always, until now and probably also in future — but let’s think this one through.

As the latency becomes experiencable mostly and most easily in programs people interact with, yes, especially those programs I have in mind. Even more specifically, programs that have a graphical user interface (GUI), such as any GNOME programs. Of course, people do experience latency effects on text user interface (TUI) programs too, and even on service programs that don’t feature a immediate user interaction. — Once we’ll be got over start up latencies, of course, that should be tackled too. But for the moment, please let’s focus on programs with a graphical user interface.

I imagine, the process of loading and making a program ready to use, i.e. to interact with it, in general could be speed up by preloading every possible [GUI] program. On a averagely set up computer, that will probably a lot of programs to load, and even more probably that will eat up a huge share of memory — if it won’t make your machine swap immediately. Plus, you need to hide all those programs and make sure they’ll keep sitting in the background until the user actually wants to use any of them. So, if any such program might get bored for some reason (”No user interaction since xxx minutes. Shall I quit?”) you must make sure it does not fire up any distracting popup right in front of the user.
 

So far, now we’ve got two issues: #1, loading all possible programs would eat up a lot of memory, probably go to swap, thus slow the machine down in general (although that way lack in responsivity might slip through unnoticedly). #2, programs need to be enforced to sit invisible in the background — and stay there. I see chances to get rid of both, with a little help of either the maintainers of the respective programs or by figuring out and applying the necessary patches all ourselves.

So, what’d need to be done?

The user interacting with a program experiences something that probably is a bit different from what the average user might think they experience. At first glance, most people probably would assume they have — or at least demand — a linear user experience. That means, once you get into a program you’d have a steady (linear) stream of interaction. But that’s not the case: Today, we’ve got machines that are a million times faster but their cousins from twenty years ago, but still they lack — you guess — responsivity. Which exactly hints to what’s going on instead of linearity in interaction: a dialog.

The user does something, say, launch a program by clicking an icon. Then the user waits for the program’s upcoming next action. This clearly is the moment where lack in responsivity kicks in, you wait for some reaction. But the point is: Even if you’d speak with a real person, after saying something you’d expect a reaction from the other side. There you’d wait also. So, it’s a natural, thus familiar, habit to wait for a reaction once you initiated an action. Even below the level of human interaction this takes place in nature: If you release a bottle of water from your hand, you expect it to drop to the ground. Although there you probably won’t have to wait too long till that takes place.

The point I wanted to make clear by that was that there is a natural break in the flow of interaction of [at least] humans, and it’s so common, it’s fully integrated into our flow of habit’s we don’t even notice. But that implies, your flow of action/interaction simply is not linearly but stepped.

So, the user launches a program, waits until it’s loaded, then orient — another delay in interaction –, then decides, then perform another step of interaction, wait for another reaction, and so on. — By that, for the vast memory usage ignited by #1 — loading all available GUI programs at once –, to get rid of it by still loading all the programs at once, but not in complete.

Let’s look at that for a single program: As the user needs to orient themselves anyways, instead of loading the whole program at once it might suffice to load the GUI only, first. That even might reduce to some picture instead of a real program, then. Which would result in a “Whoa!” user experience since the programs would seem to load instantly, i.e. without any latency here. — Loading a picture only, of course, would cause the latency to take place the moment the user really wants to interact with the program, say make use of the sensitive areas of the user interface, menu, buttons, click fields, hovering interactions (”hint windows”).

So we’ve got two alternatives here: Either start with a small part of the program like indeed a picture of the user interface, then load the remainder in the background once the user starts interacting with a particular program (which would avoid to run out of memory). — Or: Load only a small share of the program, until the next predictable break in the users interaction. To get some notion for that, I’d call the user interaction between two (predictable) break in user interaction a ’stage’. This refers to the time the user needs to get from one user interaction break to the next one but also to the according part(s) of the program which enable the user to perform that move [from one interaction break to the next one]. Once the user makes a decision, they leave the interaction break and enter another stage.

As a stage may allow several interactions to get initiated (such as drawing a line, flipping a picture, selecting a new drawing tool in a painting program) a stage, by the users part of view end by a single interaction break — but not by the program’s part of view: For the program the stage may end by diverse set of interaction breaks. So, despite you’ve got a single entry point for a stage, most times you’ll have a multitude of exit points (thus, if you imagine it, you get some kind of triangular shape for a stage, not a line-wise or rectangular one).

Loading the program only in stages probably can get extended to the whole program. I imagine even the old machines could handle that, therefore get rid of interaction latencies. At least with a little help of the program loader.
 

Let me utter one more word about the interaction breaks: You might imagine that every time a user needs to make a decision an interaction break takes place. That’s true for inexperienced users since encountering the menu (or any other initial choosing alternative) might enforce them to get oriented first before making a decision. But obviously that does not happen for experienced users: They already have a picture of the choosing alternative in mind and therefore pre-plan their interactions beforehand. For such users it’s most likely they outrun the machine/program, simply because the machine insists on drawing the menu instead of taking up the user’s approach of ignoring the accomplishment of menu drawing. — Because of that you’d need to choose interaction breaks for your program carefully: Probably the best chances to get a match [between presumed and real interaction break] is for every situation where the user needs to orient themselves before they can make the decision. — This probably can get optimized even more. However, I think this approach might find a good use on multi-core or other parallelized machines.

Back to the issue #2, programs to sit invisible in the background: Well, I hope it’d simply vanish once developers get used to the idea their program might get loaded [partitially] without being used ever.

However, to make this approach work, we’d either need to apply this for programs or we’d need to get some help from the program loader/operating system/desktop environment. Also because they might help on determining where stages might end.

What about a discussion, below, in the comments?