|
LOBOTOMY PROJECT
|
|
SYNAPSE PROJECT
|
Dejavu
(v0.1, 21.2.2008)
Abstract
Speculations about a cronologically oriented taskbar...
Summary:
Introduction
In current desktop environment you daily handle a taskbar, the little application which permits to manage windows of other running applications. This is good, because you can run multiple programs at same time and easily switch from one to another. This is good...?
Why taskbar is bad
Taskbar is not bad. Motivations of its existance are. Taskbar exists to supply three main defects of modern graphical environments: lack of integration between applications, state switching in the process execution, and multitasking.
About integration: windows are isolated each other, so you find yourself to run separately the mail client, the IM client, the address book, and a browser with a maps web application just to find and contact your two friends and date them for launch. Of course, many programs contains many sub-functions having common usage (a groupware program as Evolution, for example), but when you move a little more out of the scope you have to fire up another window, tipically with different interface and different usage approach, and have to jump back to the first window when the information is retrived. No matter about how many functions can contains a single software: it cannot contains everything.
The sentence about "state switching" can be not so immediately recognizable, but is clear when speaking about initialization and finalization of applications, and different modes, panels and tabs into the same context. Every time the mail client is opened it has to allocate graphic structures, parse the mail archive, the address book, the GPG keyring and more to build the final rappresentation, but closing it the functionality of fetching mails is lost; in the other hand the program require hardware resources to run, also when in idle: primary memory to host the visual and internal structures, CPU cycles everytime the window is refreshed (it means: also when overlapped by another window, without real interaction), and so on. The pure functionality is embedded into the application, and, by definition, the application is monolithic: I cannot close she, so I have to fire up it once and back to that window when needed.
What about multitasking? Is perhaps this goal of modern computation a bad thing? Are schedulers to be wiped out from kernels? Of course no, and the reference is about the usage of different program at same time by the user: when the person is in front of the monitor, with an hand on keyboard and the other on mouse, he is trying to accomplish a single job a time, not multiple, so (by logic) is not needed to have multiple applications running concurrently. At least, not multiple graphic applications: the mp3 player can reproduce music on background, the RSS aggregator can continue to fetch feeds, but only one window a time has the screen focus (and the user's "locus").
In this scenario, the "taskbar" word is misused, just because this familiar desktop item is not to manage tasks, but apps. Can we drive the concept to its original lexical sense?
What is a task
Having to think about taskbar, lets think about the task.
As described in the page "Split to Integrate", the final Lobotomy environment will have to be a unique MVC model: the filesystem provides data (model), Synapse renders views described by ad hoc XSL trasformations (viewer), and common and hidden functionalities are implemented by dedicated daemons, once in the whole system, controlled by front-ends (controller). What is a task? The list of the current model (the query from which the working result set have been generated), the current view (a reference to the trasformation applied to model) and, in some case, the identity of the currently selected item. No more than a string and a pair of numbers.
Separating "data" from "applications", "information" from "ways to handle information", "mail" from "receiving, sending, reading, sorting mails", is easy to reduce the single task ("receiving mails from that account", "sending a mail to that friend", "reading a mail from that mailing list"...) to its essence. And to reproduce it when needed.
Step forward, step backward
We already have spoke about the single-tasking of the user, which handle a single set of informations at a time. He works on something, then switch to another work, sometime turns back: everytime there is a present, a past, and a future. Why don't handle this in cronological way, rather than in unordered chaos compressed in a bar on bottom side of screen?
Lets assume to be able to navigate our tasks as in the browser's history: we can look for code about a particular project (task #1: search), select and open an item for editing (task #2: edit), forgot parameters to pass to the function and check documentation (task #3: man statfs), and back to the file... Clicking on an arrow on top left corner of the screen! Nothing more than that arrow is needed to switch previous works, and nothing more than a pair of items to jump next: a field where input the new search criteria for a new result set, and the button which permits changing current view.
No buttons describing unsorted previous tasks, or idle applications running to maintain the function needed: just a past and a future. The rest of the screen is dedicated to the present, the current job.
To offer a complete control over the previous informations managed, we can hypotize a whole panel rappresenting a timeline and/or the jobs sequence, also with search and filtering capabilities to match just the desidered old screen.
Selecting a task the system will rebuild the involved result set, represent it on the relative stored view, in a word reproduce exactly the previously abandoned graphic to the user. It is important to note that this operation is different than close and re-open an application, just because no "applications" (as in modern desktop environment meaning) are here involved: as described above functional elements are split into essential tokens, to backing to the screen used to manage mails is just building the front-end (the viewer) to the mails daemon which never stop to run on the backgorund (the controller).
Conclusions
The idea here described is, at least, extremely simple: handle tasks as tasks. As things did and to do. No more.
Applying a cronological order to sort works accomplished by user, user can better navigate his own mental stream, remembering what he was doing a minute or one hour ago.
And, of course, at design level graphical objects to rappresent this approach are limited in area occupied on the screen: a button is enough to go back!
