Global Mask Swadeshi

This idea is silly enough to make me come back to posting ... a blog entry ... in July 2020.

Ok, so the name says it: global mask swadeshi. By which we'd mean, what, that people all over the world should be able to make their own masks, right?

Oh, no, not just that. It's also about being able to make the cloth or filters needed to make the masks in the first place.

And being able to test that cloth, those filters, those masks, for filtration capacity and for fit (in the case of a particular mask on a particular face).

So, it's happening in a few days. A number of people will put their brains together to design a machine to make masks. My guess is at some point someone might be able to push it to get it certified somewhere, thereby increasing acceptability.

When I first looked at Ebola and came up with this crazy, silly, maybe even dangerous idea of the Excubator, I totally had to go and write the PandemicOSAT page, and, much later, the More_better_PPE (all of that is at appropedia.org).

In any case, this is happening. The textile mask is already designed. It accepts filters in a pocket. A machine might be designed, made, even work.

We'll see!


Should I go back to blogging?

In these past years, I've blogged a couple of times in medium. Used Twitter a lot. Eventually stopped writing notebooks. So I don't know. Och, well!


Thinking and cothinking with outline editors: a very old project

[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.
  1. 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.
  2. 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.
  3. 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).
  4. 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
          ****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 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".

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".
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.)
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".)
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.)
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.)
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.

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


Cognitive Insufficiency

I know someone who bought a new phone because he didn't notice he could have replaced the old phone's battery.
Actually it's a bit more messy than that because the old phone had other issues which muddled the decision. And the battery was changed, and the replacement was also faulty.

But if you look at the chain of problems, it was a non-working phone because of a faulty battery because he didn't think well because his mind was in other subjects.

We all make expensive mistakes all the time.

And collectively, as a species, we may be approaching, not future shock, but future crash. Or maybe not.

How do you solve this? Meditation, help from conversation, better health in terms of sleep, food, exercise, etc? Flowcharts and thinking tools? Reduce inputs by living simply ("thinning")? Pass?

Today, I pass. But I'm seriously considering meditation and thinning. And a little conversation, but then we overload each other instead of attacking the noise at its source.

Thanks for listening.


Speech to subtitles and translations: a streamlined process

I've translated quite a bit, just because I started a long time ago. Old age!

Over several years, I translated two thousand pages of Edward de Bono's educational material into Spanish. It used to be in edwdebono.com/spanish but I have no idea where it is now, or if it even exists. I did learned about the thinking tools. :shrug:

I only work very openly now. I've always done stuff so I might learn (from the very first page), and recently because it is just easier to translate and link than to tell 200 hundred friends one by one. Lazy! :-)

So, I may be missing something, but at least I've done some fluwiki texts, some open source ecology videos and texts, an akvo set of documents on "water day" (*link*), Hans Rosling's "200 countries x 200 years in 4 minutes" (more than 40 languages), and videos by Vinay Gupta (too many to mention, but see a recent what and how) and EdgeRyders. Also, one short piece about the scaffolding of imagination. Have I learned!

I've also translated some of my own videos, fooling around with mindmapping while I speak, and then translating that. It's a cool way to convey ideas, but I have yet to use that to my fullest, and for example do my own "complex systems" talk. (Give me some time, later in the year ... oops!)

I'll add links to all of this later, and of course you can just look at what Amara.org, TED.com and others are doing - but just let me tell you about the process itself:
  • Upload video to youtube. It does pay to have good sound, so use a good microphone close to the person speaking.
  • Use Google2SRT.sf.net to download automatic transcription. (Folks, we need an open tool for speech-to-text. Any links?)
  • Polish the transcription. You probably need to get rid of timestamps; I usually do, and there's some script in my hard-disk somewhere. For the actual text editting, if you work alone, use oTranscribe.com or Amara.org itself. If you work with other people, use Etherpad.org as in this animation.
  • Cut the transcription to 42 characters per line, as suggested by Amara. (I guess that advice comes from practice and is shared by other subtitle platforms such as *fill in name, was it dotsub or something like it?*).
  • Upload to amara and synchronise video and sound there.
  • Now, in Amara, you (and people you don't know!) can translate into whatever number of languages. (Did I say Rosling's has more than 40 languages? Yes I did. See above.)
You need to check at every stage, but it's not like you can break much, so just have fun while you learn and cooperate. Ah, a tip from my experience: do only the easy half, and never do the second half. It's too expensive, and others can do it so much better than you, so just ask for help!

Ok so, while we're at it, can you lend a hand with our current project, which is a talk by Vinay Gupta on leveraging BitCoin and other blockchain tools to, well, "do poverty"? The etherpad instance is http://piratepad.net/vinaygupta-bitcoin-2. Thanks!

PS: I'd also love to do New World Order but they may be doing it already, and differently. :-?


#WHP1: exploring a thinking tool

#WHP1 is Want, Have, Possibilities, 1st step. It can be a mindmap or a set of lists or a conversation. It's a thinking tool because it helps you focus on one aspect at a time, yet build a fuller picture. It's a loop if you make it so; I do.

(It's an action tool too. Not that neurons are different for thinking and acting. It's just that some neurons are connected to muscles. But I disgress. Anyway.)

Say our current focus/center is "a better room". Wants is experience, function, purpose: a place to hide, work, talk, cook, give to ourselves, or whatever. Haves is square meters, windows, existing furniture; but also some money, friends to ask advice from, and any other resources we can muster. Possibilities include making, buying, giving away, repositioning, and maybe even swapping rooms. First step is you select what you can do in 2-5 minutes, one afternoon, or a week. Give the whole round 3-10 minutes, or a few days. Then you go back to Wants, and see how it's now enriched.

Try it on a few examples, maybe working together with other people, or first round alone and then ask and listen. You now own the tool. It can stay in your toolbox, unused. Yours.

I've used #OODA, John Boyd's Observe, Orient, Decide, Act loop, which is good for objective, complex, extra-personal situations. I used it together with SCIM (Vinay Gupta's Simple Critical Infrastructure Maps) for severe pandemic influenza, because SCIM is great for "orientation" around Needs and Provision. It's linked from http://ResilienceMaps.org and, frankly, may we never ever need it. (But I'm glad I did my homework.)

OODA is different from WHP1. I wonder if parallel teams, sharing output, would give us some interesting insights. But in my experience any tool is often better than no tool... Even if, or particularly when, you find the tool doesn't cover the thinking you feel is needed for that particular situation. As in "hey, #WHP1 doesn't let me look at this-and-that".

That's probably why I wrote the "I'm not my phone" song, over at http://imacan.bandcamp.com/album/evolution, and the Acceptable Fairies Observation elsewhere in this blog. Because we stay limited in our thinking, no matter what we do: small photographic cameras, huge-moving-smelly landscape. But you already knew.

Anyway, I hope this helps somewhat. :shrug: :-)