(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.
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.
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.
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
No hay comentarios:
Publicar un comentario