TaskOE

A Task-centric, Configurable, Extensible Personal Computing Environment

Those who use Linux are familiar with "workspaces". By clicking on a workspace icon, usually at the bottom right of your screen, you can select a different workspace. Possibly you use this feature now to organize your activities. Workspace one might contain your browser. Workspace two might contain your editor, three your file browser and four your Skype. Now imagine that you can cluster your activities by workspace. If you are writing software, you might have an editor open on one or more files. You might also have a browser open to some specification. You might also have an open PDF on the workspace -- and more.

Now imagine that you close your computer and re-open it. Where did your work go? The workspace you used is empty and you must load everything all over again just to get back to work. Now suppose the workspace remembered itself and presented you with all of your apps all ready for you to use. Suppose further that you could type notes directly onto the workspace screen that is before you. Some of these notes might indicate the nature of the work being done in that space. Others might indicate where you left off last time in your thinking, or what your plans are for your next efforts.

But we are not yet out of "what ifs". What if your text on the workspace screen also contained hyperlinks to related workspaces -- perhaps other, similar projects, or hyperlinks to index workspaces that could take you many places. What if you could display a history, like in a browser, to take you back to former workspaces. What if you could bring up a tag index or tag cloud in that workspace that would help you find collections of workspaces on your PC, LAN and cloud? What if you could bring up a list of apps you might add to the workspace? What if you could copy the workspace and then modify it to suit a similar task?

To create an analogy to these familiar ideas, I have renamed the workspace a "screenful" and apps as "elements". This will help think of them in a new way without too much carryover from the old ideas.

Most computer and internet users are familiar now with a Wiki environment. It consists of pages of content hyperlinked together. Content such as text, photos, videos, music, tables and other forms of information or entertainment. A Wiki page even exists that functions as a web browser. It is possible to launch applications from a Wiki page. (cf. Tiddywiki)

The pages of a wiki are often referred to as microcontent. This suggests that information in the Wiki is being broken up into, or created in, small bits. These pages are commonly hyperlinked together which allows for all sorts of organizational schemes.

Another useful mechanism for organization is tagging. By adding tags to each page, one has the ability to produce lists of pages by tag. By combining hyperlinking and tagging, a very powerful organizational system is achieved.

In the early days of computing, the Operating System (OS) was conceived as the man-machine interface. Most of the effort of an OS was directed toward storing information in files, and executing programs. Though we have greatly improved the human interfaces to computing devices we are still bound to this noun-ish verb-ish paradigm. Operating environments have become increasingly prettier or more wobbly, but not measurably more organized.

Through the use of a personal Wiki over the past several years, I have come to be doing more and more of my work inside the Wiki rather than outside it. The superb organization it offers virtually guarantees that I will never lose track of old efforts. This makes my work modular in the sense that I can leverage past accomplishments to do current tasks.

The question logically follows: Why not a Wiki as an Operating System? The following is a functional specification for such an OS, or operating environment. Please feel free to send comments to my email address below. Anyone who wishes to code such a system is welcome to use these ideas and expand upon them.

I envision that the code can be executed within a browser window for prototyping purposes, as a shell for adaptability to existing kernels, and as itself running on top of the bare machine. The working name is TaskOE, suggesting the set of task oriented features upon which the system is formulated.

SYSTEM

• A TaskOE system consists of Screenfuls, Element plugins, Indicators, and Configurators.
• The system is built upon a machine abstraction layer "virtual machine" to achieve cross-platform compatibility.
• The abstraction layer is language agnostic.
• The system may be prototyped within a browser by providing the abstraction layer in the browser.
• The abstraction layer can run at various levels, system kernel, GUI shell, application, or browser application.
• The system will function identically at any level except for speed.
• The system is extensible by adding or replacing Elements.
• Element wizards help create Elements and Element frameworks for applications.
• A protected "sandbox" environment is available to test new Elements.
• A migration Element is available to package the system for movement to a new physical location.
• The entire system can be copied by copying the initial Screenful, as everything is linked.
• A namespace facility will allow users to quickly discover functionality groupings of Screenfuls or Elements.

SCREENFUL

• A Screenful is the entire visible screen at any one time.
• A Screenful is task-centric by design.
• A Screenful may be created by the user pertinent to any task.
• A Screenful may be created by creating a link to it and by invoking the link.
• A Screenful hosts Elements.
• Screenfuls, when Elements are added, altered, or deleted, are dynamically auto-saved within the system.
• Screenfuls can be locally designated as read-only, invisible and passworded, or open.
• Screenfuls can be locked by local or global passwords.
• A Screenful may be scaled or panned to fit monitors, under user configuration.
• A Screenful may be hosted on the local PC, or across a network of any kind.
• A Screenful may be copied or deleted by its owner.
• A history of the Screenful is accessible via a history Element mechanism.
• A Screenful can have a background image or color or animation, or can portray an Element.
• Screenfuls that currently host running processes (Elements) need not be visible on the currently viewed Screenful.
• A Screenful contains Elements which can consist of text, media, graphics, links, applications and other plugin Elements.
• When a Screenful is invoked (navigated to) via a link, a page kernel reads in the page and installs all the Element plugins and their data.
• The page kernel provides storage management, message passing, and resource sharing.

ELEMENT PLUGINS

• Elements are plugins.
• The Element plugin interface is language agnostic.
• Plugins may be local or global.
• Local plugins override global plugins.
• All system interaction is done via Element plugins.
• Elements may be locked by password.
• Element types are menu, text, graphic, media, links, lists, tables, histories, applications, Element wizards, and indicators.
• New Element types may be created.
• Elements communicate by message passing.
• Under configuration, Elements may be hidden and invokable by the user, or permanently visible.
• Elements are created or copied to exist within the Screenful, which Elements are re-sizable and movable and scrollable.
• Element contents may be configured as new Elements.
• Elements may be dynamically replaced by new Elements, inheriting the data of the old Element.
• Under configuration, global and local Elements exist to unify the appearance of Elements, and are under user control.
• Elements may be configured to synchronize with Elements on other Screenfuls.
• Text can be typed anywhere on the screen, which text has permanency as an Element.
• Text thus typed is an Element with boundaries which can be altered by moving the container Elements.
• Text within such a bounded Element reflows to fit.
• Graphic Elements may be created anywhere on a Screenful, which graphics have permanency.
• When Elements exceed the bounds of their initial container, a scrolling mechanism appears.
• A link is an Element.
• Links to other Screenfuls or external content may be placed within a Screenful and/or other Elements.
• External link sources may or may not serve live content within a Screenful.
• Image Elements may be simply graphical, or they may constitute control Elements.
• Control mechanisms may be bound to Elements or portions thereof.
• A menu Element for invoking a list of applications exists, from which an application can be invoked.
• A menu Element may be hidden or permanent by configuration.
• Menu Elements may be created, copied edited and deleted.
• When an application is invoked, it appears as, or within, an Element within the Screenful.
• Such an application may be transient or permanent.
• An application may present itself as any Element type.
• An application may be simple or complex in appearance.
• An application can have more than one visible Element.
• History Elements are available so that previous states and actions can be re-invoked.
• History is an editable list.
• History can be passed as data.
• A mechanism exists to link any Screenful to any other Screenful.
• All Elements of a Screenful, such as media, text, applications, or graphics, have local scope within the Screenful.
• Specific Elements within a Screenful, such as text applications or graphics, can have global scope.
• Specific Elements within a Screenful can be created to affect any other Screenful.
• The scope of a plugin can be locally designated.
• Wrapper Elements may render any legacy application within a plugin, including cross-platform applications.
• An Element wizard is an Element.

INDICATORS

• Indicators are an Element type that provides information about the system and processes.
• Running Elements in other Screenfuls are indicated by floating Indicators.
• Floating Indicators contain a link to the Screenful which hosts the running application.
• Floating Indicators may be rendered visible/invisible, moved, created, deleted,and/or resized.
• Floating Indicators may have audible Elements.

CONFIGURATORS

• Configurators are an Element type that provides local or global configuration control.
• Under configuration, Element boundaries can be visible or invisible.
• Under configuration, Elements can have opacity controls.
• Under configuration, Elements can have backgrounds.
• Under configuration, Elements can have alarms.
• Under configuration, Elements can communicate with each other.

SYSTEM ORGANIZATION

A conventional windowed computer system is organized through the mechanism of directories, sometimes called folders. A hyperlinked system self-organizes. But tagging allows many types of organization to take place. So even though hyperlinking can lead from a headword Screenful, to other Screenfuls, tagging is more powerful. This is because a particular Screenful can have any number of tags associated with it, allowing the user to display a link to the Screenful from many points of view.

To give an example, say there is Screenful "books" dedicated to reading mystery novels in Ebook format. The Screenful "books" contains an Element that is an index to Ebook Elements. Each Ebook may be written by a different author. So the Screenful "books" is accessible by the tags, book, ebook, johngardner, ianfleming, reading, reader, mystery, novel, and more if desired. It is easy to see that invoking a list Element giving the Screenfuls that contain the tag "mystery" would give a different organization to the resources than would be produced by listing the Screenfuls for tags, "johngardner", or "novel". Tagging allows us the ability to create sets that are more versatile than the sets created by folderizing data. Tags may be added, edited and removed in association with any Screenful.

You might be asking, "Why can't we do all of this in our browser? It would be easier to build this functionality in HTML5, for example." You are right. And that is possibly where we should start. But I envision a faster environment that would run as a window manager, and a yet faster one that might run right on top of the kernel. If TaskOE is a better operating environment, it might better serve us as the underpinnings of enhanced functionality and organization.