[Here's something I last updated in 1999. Had a home at gulic.org - until amd77 finally dug it up and sent it to me through IRC, sorry, Telegram.
(Don't get it? You're not that old, then.)
Anyway, here is the text:]
This page is by Lucas Gonzalez [very old email, professionally related] -- last updated in November 1999.
- Thinking is using your intelligence and tools. Cothinking is
using your intelligence, tools and communication. Natural thinking,
deliberate thinking (with tools), meditation, storytelling and other
things are not mutually exclusive. I like thinking to be positive,
constructive, creative and enjoyable. Communication is important, and
often you need to communicate with yourself.
- Some may like to use Edward de Bono’s
thinking tools and frameworks: CoRT (which I have translated into
Spanish), Six Hats and Lateral Thinking. In his site there are pages
with the Northern Ireland Design Conference, and also a Creative Team.
He may sound too comercial for your taste, but why not use commercial
wheels and can-openers when available?
- I have a project to create a "free software" outliner, which I call sole: simple out-line editor. My references are MaxThink, Hybris, Think and Kibble. I’d like to be able to download news and comments from places like Slashdot, Squishdot and Technocrat – in outline format, so I can do some thinking (harvesting and creativity) at home. I keep the project in the gulic site.
- Together with Jeff and Josh, we are developing the Open Idea Project,
which speaks for its own. It started with a vision by Reha Ayata to
give "thinking aid" to Turkey after the earthquakes in 1999 - posted by
Edward de Bono. The OIP can and should be replicated for places and
goals.
- I like GNU/Linux: both the operative system and the gift culture. I tend to use the Debian distribution. I think GNU/Linux is a form of co-thinking - there can be others. Small contributions add up - or multiply wide.
---------------
SOLE : Simple Out-Line
Editor
(c) Lucas González Santa Cruz [very old email address].
December 1999. You may distribute this document as long as you
don't change its content. I you have ideas to improve it, please
tell me about them. Thanks.
Motivation - What it is
for
Outline editors (OLE) are a little like line editors. But
lines, called
nodes, are organized as a tree:
there's a root node, which has children nodes, which in turn have
grandchildren nodes, etc.
I can see at least for
uses for an OLE, each one
quite "powerful":
- A person on his/her own, can use an OLE to
organize to-do lists; to revise a subject for an exam; to
think about the structure of a piece of software; or to
write the hierarchical manual of such a piece of
software.
- That person can share his outline with someone else,
and receive criticism and suggestions. Later, the author
uses some or all the contributions, acknowledges them,
and goes on working on his own.
- Another possibility is receiving a structured
document, at least the manual of a piece of software, and
translate it. If the document is organized in outline
format, a follow-up of translations can be done (how many
nodes left to complete the translation), highlight only
the paragraphs that change from one version to the next
(they are the only ones he should translate), etc.
- It's also possible to create an outline, from the
start, in cooperation. (I tend to call this cothinking
with outlines. It's only one of the ways of
cothinking.) It's something similar to using a CVS to
create a complex piece of software with many programmers'
contributions. Imagine we are thinking about the traffic
problems in our town: some would develop the "ideas
to reduce the number of cars" branch; others would
work on the "ideas to improve public transport"
branch; and so on. Finally, we'd have a "collective
idea tree", from which all would be able to take,
prioritize, vote, develop it further, etc.
In the following pages I explore the possibility of
developping a Simple Out-Line
Editor (SOLE),
as free software (GPL or
similar license), starting with a personal use OLE and able to be
developped further to allow the more ambitious functionalities.
Proposal - Plan
The important thing is to develop the program and
make it work.
- I think we should start by looking up the code of some
free line-oriented text editor, written in some
programming language that can be compiled in multiple
arquitectures, or easy to translate into other
programming languages.
- First we should create the SOLE - Simple Out-Line
Editor. It would have the minimal functionalities and
a data structure as simple as possible. I've already
started such a project. You can download the .ZIP file or the .TAR.GZ file. It doesn't do much yet. It's GPL'ed.
- Later, we could develop the data structure and the
functionalities, and maybe create some external
programs (adapt the e-mail processors to share
out-lines like we share the messages in a mailing list).
- Gradually, we would get to the point of developping advanced
versions, capable of helping human translators, or
letting many "cothinkers" create communal idea
trees.
Here follows a draft of the data structure and the minimal
functionalities, to create the first version of SOLE. As soon as
I'm in touch with some interested programmers, I'd like to
discuss it to see if it's valid, do-able, and useful.
Data structure
From what I've seen and thought until now, I think the
simplest way to
represent an out-line AS A FILE is like
Emacs does it in its
mode-outline: there's a node in
each line; depth levels are represented as "leading
stars"; and descendants go after each parent in a nested
way. It would be something like this:
City traffic
*Starting information
**There are many private cars
**There are more each day
**Public transport is a disgrace
*Possible aims
**Reduce private cars
***Buy less new cars
****ideas
****developping
****the general idea
****of buying less cars
***Share private cars
****more developement ...
***Need cars less
**Improve public transport
To
represent an out-line IN MEMORY, I think it would be
done like I suggest next. But I'm not a programmer and, really, I
don't have a clue if it could be done in a better way. My idea
would be something like this:
Each node would be represented by a data structure made of a
few elements. The out-line would be an array of such structures.
The elements would be like this:
- The text of the node. As I'd prefer to keep it simple at
first, it would be a fixed length string of characters.
For the time being, the length will be 75, which is less
than the line length in my screen.
- An integer holding the position of this node's parent in
the array. If it holds a zero, then this node is the root
node.
- An integer holding this node's number of descendants. If
it's zero, then it's a terminal node.
- A list of descendants. A fixed length array of integer
numbers, each holding the position of a descendant in the
array.
There might be need to keep a global memory pointing to the
root node, though generally it would just be number one.
As I say, probably both the
FILE representation and the MEMORY representation can be
improved. But they are useful to start with if there are no
better ideas. I know that other programs use XML or nested
lists - but I think they would only add complexity at this
stage.
In a second phase of the program's
developement, the data structure should include, apart from
the "content" of the nodes, some
"meta-content".
The "meta-content" would include
several elements:
- information about the date of creation
or last edition of each node.
- author information.
- permission to read ("hidden
nodes"), edit, create and sort nodes and
subtrees.
- historical order of inclussion in the
out-line (node 0.3.1.2 may have been included after
75 nodes had been created - it would be,
historically, number 76).
- alternative sorting for
"preferendums" (alt-sort:ACEDB,
alt-sort:ECDAB, etc).
- links to files (text, image, sound) or
URLs
- qualification of a given node as a
"fence". This would allow for
"segmented lists", which is something in
between a list and an out-line.
- tag to know if a given node should be
printed with numbers, in which format, etc.
- and other elements.
Also, within the "content" there
might be underline, bold, etc.
User interface
User interface is, up to a point, very personal. Here I give
my own "tastes" (or prejudices).
Regarding
looks:
I'd rather have a text-only SOLE. This would allow it
to work in a wider scope of operating systems, computer power,
etc. More than that: I prefer it if there's nothing in between my
ideas and me, and I don't want to have to put my hands away from
the keyboard.
An outline can have two levels (root node and its sons) or
many levels.
I'd rather see only two levels at a time.
That is: if I'm focusing on the third chapter of the document, I
want to see the title of that chapter and the immediate lower
nodes - I'm not interested in grandparents or in grandchildren. I
believe that if each "pair of levels" (first and
second, second and third, etc) is okay, then the outline as a
whole will be okay (whatever okay may mean).
Furthermore, when nodes (e.g. the paragraphs of the chapter in
focus) take more than one line, y may want to
see the first
line only, to be able to focus on the structure of the
chapter as such.
Or else I may want to see the whole
paragraphs, and focus in their content. This would be
activated via a switch.
So the
screen would
have:
- a title at the top (for example "third
chapter"),
- then a list of nodes (maybe with a character or
color that would tell that there are deeper levels) and,
- finally, some relevant information about the outline
and the available options. This information would be
something like this:
- options ("save", "quit",
etc.) and suboptions ("save before quitting
(Y/N)?").
- whether we are in "navigate" mode or in
"edit" mode.
- within "edit" mode, whether we are in
"insert" mode or in
"overwrite" mode.
- whether we are in "show only first line of
each paragraph" mode or in "show all
text" mode.
- the name of the outline as a disk file. For
example: "sole.ol".
- the absolute address of the current node. For
example, the second son of root node's third son
would be "0.3.2".
Functionalities
What follow are the minimal functionalities to have a ...
minimally funcionally SOLE.
In brackets, I summarize some other functionalities that
might turn the initial program into something even more
versatile. At the end of this section, I suggest some other
"expansions".
Navigate:
When we are not "editting" a node, we can move
around the outline using the four arrow keys.
Up to go to
the immediate elder brother, and
Down to go to the
immediate younger brother.
Left to go to the father, and
Right
to move to the deeper level. (When we are seeing levels 2 and 3
and we go deeper, we then see levels 3 and 4.)
(Other options: we might have
"search", "jump" and "fence
jumps" as alternative ways to move around the outline. Searches
can be as complex as we like, with regexp, boolean searches,
etc. Jumps can be done to the absolute address - eg
"0.3.2" -, or relative to the current node - eg
jump to the beginning of the third chapter -. We could also
do fence jumps, within a segmented list.)
Process:
Edit node:
After navigating (or seaching or jumping), we may want to
modify a node. So we press the apropriate key and we enter "
edit
mode", edit the node (like in any text editor), and
finally come back to "
navigation mode"
pressing "escape". (These "modes" are similar
to the modes in the *nix editor called
vi.)
When we are editting a node, we may want to
split it in
half at the point where the cursor is, thus creating two nodes
where there was only one. This way, "
this sentence"
would become "
this" "sentence". The
cursor would stay, in edit mode, at the beginning of the second
node.
(In the future, another functionality would
be to divide a node in sentences, lines or words.)
Join nodes:
The opposite of splitting a node would be to join to or more
nodes, creating one. To do this we would have to "mark a
sublist" first (see below) and then issue the "make
them one" command.
Add node:
We can create a new node, and stay with the cursor at the
first character of an initially empty text, and in edit mode.
This new node can be created:
- before current node.
- after current node.
- as a son to current node.
(There are other options that can be
implemented in more advanced versions of the program, such as
"create an uncle": I am thinking about foods to put
under the "breakfast" node, and I realise that
"lunch" and "dinner" are also meals -
brothers to "breakfast".)
Select:
The immediate descendants of a node form a
list.
A subset of a list is called a
sublist (eg from
node 0.3.2 until 0.3.7, not counting their descendants). We
select a sublist marking the initial node and the final node of
the wanted sublist.
When we select a sublist, we also select all the descendants
of the nodes that make up the sublist.
(Other selections could be the
"gathering": we navigate the outline marking the
nodes we're interested in, and then we copy or move them to a
suitable place in the outline. For instance, we may have many
To-Do things in a really complex tree; but today we'll only
be able to do the more urgent things in each branch. So we
navigate our huge outline, marking the more urgent nodes, and
we then "gather" them somewhere, possibly under the
"today" title.)
Delete node:
The node or the selection is deleted. Usually all descendants
are deleted too.
(One might want to delete only the descendants.
In this case, we'd end up just with the titles of the chapters,
but without their content.)
Copy node:
The copy may be done: after current node, before current node,
or as current node's son. Unlike with "add node", we
don't want to automatically enter "edit mode".
Move node:
Moving is like copying, but deleting the source.
("Move" may mean more things, and
very interesting ones: we may sort a list or a sublist
[alphabetically or in some other ways], shuffle/unsort it in
a random way, prioritize it [with human criteria],
basket-sort it [also with human criteria], flatten it
[creating "fences" where there were
"categories"], categorise it [using
"fences" as "categories"], and maybe some
other options. What we do with a sublist [usually] won't
affect deeper descendents.)
Files:
Read file:
When we read a file from disk, we may use it to replace the
outline that's currently in memory, or insert it as the older
brother, as the younger brother, or as a son of the current node.
(If the file is a plain text file, without
the structure of an outline file, we may try and
"swallow" it and then reformat it "by
hand" to convert it into an outline.)
Save file:
We may save to disk the whole of the outline currently in
memory, or just a selection. We must give the name of the file we
want to create.
If we have selected a group of nodes (a sublist), then we have
to give some text to act as "root node", because there
can only be one "root node" for each outline.
Print file:
To make things simple, I think maybe we should
pseudo-print
to a file in disk. This file can then be imported to a text
processor, print it, etc.
There might be a few formats: with and without numbers (before
each node, different for each level), indentation, page size,
line size, etc..
If the destination file exists already, we may choose to
replace it or add the new text to the old file.
(A feature similar to printing and saving
is to write the outline in some of the other possible
formats: XML, nested lists, or whatever. We could also export
to HTML, Mind Maps, and other formats.)
System:
Shell: we may get out to the
system shell for many purposes.
Quit: eventually, we'll have to
do this, won't we? :-)
"Expanded"
features:
These features wouldn't be implemented in
the basic SOLE, but are very interesting.
- There could be two outlines in memory
at once, one with a document in the original
language, and the other with our translation,
and each in its window. If we navigate one outline,
we automatically navigate the other
("simultaneous scrolling"). Pressing a key,
we could translate the word under the cursor, swap
the current word with the next, etc. We would be able
to "delete until the end of the sentence",
and also activate a translation or translation-aid
plug in. If a list of words pop up as possible
translations of the current word, we might be able to
sort that list so that in another ocasion it will
choose the most likely translation.
- Outlines could be shared with a group
of people. This would be "co-thinking with
outlines". [There's also "co-thinking
with wiki documents", "co-thinking with
web-logs", and other ways of co-thinking.] This
would call for adjusting the data structure, with
"meta-content" to identify authors,
permissions, dates, etc. We would also have to
develop the software utilities to "merge"
contributions, and to resend the changes (or the
whole outline) to the co-thinkers. A lot of thinking
should go into the different scenarios: with/without
moderators, small respectful comitee, a thousand
anonymous co-thinkers, the possibility of keeping
ideas secret and then unveil them simultaneously,
etc. Two big different scenarios also require some
thinking: centrally kept outlines (changes happen in
real time), or distributed outlines (changes may
clash with each other).
- Weblog software like Slashdot
and Squishdot may have some features added, to
allow downloading "news + comments" in
outline format. That way, there would be readers that
would contribute their summaries - more or less
biassed, so there would be more than one summary by
different users. This would require changes in the
S*dot side, and it would be useful even if SOLE had
only the minimal functionalities. And it would give
some notoriety to SOLE, and more "social
usefulness" to S*dot.
- The code for SOLE might be included
inside "free" text editors.
- Versions of SOLE might be
created for PDAs, internet street kiosks in which
ideas are input via voice recognition, and for other
situations.
- Some"plug-ins" might
be added with, for example, a random word generator
to be used as stimuly for creativity (see Edward de
Bono's work about Lateral Thinking).
- "Templates" might be
created, so that standard headings would be created -
and developped later. For example, I might want to
include CoRT Thinking Tools (by Edward de
Bono), such as PMI: positive points, minus points,
and interesting points - and then I'd only have to
fill them in. Another example would be the 5 W's:
"what, when, who, where, why", used by
journalists. It would be possible even to force the
user to fill in each item in a predefined time;
that way I would be forced to consider for one minute
the bad points of my favourite idea.
- A version of SOLE would not have text,
but graphic elements added in a tree-like way
from a "root node" that would be a blank
page.
- Minimal
"hipertext"elements might be added in
order to have cross references and the like.
- Another possible addition would be "macros",
"links" (to files or to URLs), "help",
and possibly other things.
Links
Hybris:
http://hybris.netpedia.net
(I have 2 pages there; you may be interested in having a look)
Outline editor using (GTK, perl, C - in different generations)
and nested lists. GPL.
Think:
http://www.duke.edu/~pat4/think/
Outline editor under Gnome. GPL. It used to use a data structure
like Emacs', is developping one based on XML [and will use Emacs'
too, again].
Kibble:
http://wish.student.harvard.edu/kibble
Outline editor using GTK. GPL.
Edward de Bono:
http://www.edwdebono.com
Author of books and teaching programs about "thinking".
In his website there's a Northern Ireland Design Conference, and
a Creative Team that uses Motet as conference software. He
suggests setting up Thinking Clubs.
Slashdot:
http://slashdot.org
News for Nerds - Stuff that Really Matters.
This page:
http://www.gulic.org/copensar/sole.html
A previous version of this page, in Spanish:
http://www.gulic.org/copensar/pepe.html
