[###style:css-sidetoc]

Ethering: why?


< RFC+ >
 
Revisions:
    20201023 SLO stub
    20201024 translate + overview
    20210822 re-read for MZ
    20240425 re-read for doug
About pads & a general “philosophy” of using these tools.


"Can this be used by analphabets?"
"Will I have to clean up after people?"



0) If you ever worked on document projects with a dynamic group of people, especially in a non-hierarchical and explorative context ... you've experienced the problems.


1) There can be no simpler tool than pads.

In the simplest sense:
    You arrive, and start pressing buttons on a computer and the letters appear on the screen. It's a text editor.


2) The more you know, the better it gets.

To make headers, tables of contents, lists, internal and external links, and even graphs is not exactly rocket science; and honestly, no more than in word / gdocs.


3) ... but it is true that people are used to some specifics of those mainline tools.

The mainline tools have “momentum”, as capital imposed them through the decades following their cooption and subsequent destruction of the “Xerox PARC” laboratory.

 
###[!!**] lol bad e2h bug here :(
This link fucks up also e2h-test...
   [###https://www.youtube.com/watch?v=yJDv-zdhzMY###The Mother of All Demos, presented by Douglas Engelbart (1968)].
   Engelbart is a top 3 hypermedia/computing classic. (Bill Gates and Steve Jobs are not).

Have a look at this for some persepective of what I mean:
   https://www.youtube.com/watch?v=yJDv-zdhzMY : "The Mother of All Demos", presented by Douglas Engelbart, 1968. (Engelbart is a top 3 hypermedia/computing classic. Bill Gates and Steve Jobs are not, neither is Tim Berners-Lee).



In short ...

* It's good that we don't use the mainline tools: we are de-mainlining, prefer to be "self-sufficient", to "roll our own"

* It's honestly not very difficult to learn whatever needs to be learnt here

* Learning happens best in a collaborative—exchange—mentoring form:
    And this happens to be the relation you will need to perfect in any case when doing actual work together. It is not something "additional" or "external", so it will inevitably catalyze the wider relationships in the correct direction.

* The majority of the both possible and neccessary learning is not about where the buttons are, what the keyboard shortcuts are, or working around tiny glitches, but in the continuous mastery of the oblique collaboration strategies, co-evolved within the collaborative system, with the other collaborants.


Let me illustrate this on a case:

Yes — screw up a few square brackets in E2h, and the whole page (in view mode) will fail.

So what?

You can still use edit mode. And the error was yours, you're in a game, and following the rules, even if "they are not easy" or "you don't like them". This is just a tacit reminder you're within a system with its own rules. If you're unable or unwilling to adopt systems, you're probably better off doing something else than trying to collaborate with people, at least at a high level.
### If this glitch wouldn't exist, it would have to be invented. And since it's platform-provided, the anarchists can't even blame a person.

Some users react with harassing me to "fix" this specific "bug". No chance! Every person worth working with should be able to, for example, consistently adopt new punctuation — and have somebody look after them insofar as they don't. And indeed, with our writers, we go through a phase where they learn to correct these errors very quickly, and become consistent.

This whole situation with needing "mentoring" — assisted learning about the tool from a superior user — is not a bug in the system. A level of "simplicity" within a tool that wouldn't need it, would prevent us from achieving *quality*, non-generic end results in any case.
., or, would impose prohibitive exclusion criteria.

The "mentoring" is a feature.



Capitalistic "simplification" is degenerative

Take the following example:
    * First of all, Etherpad is older than gdocs. (As a matter of fact, gdocs started when the Etherpad's team was poached to create it; the open source project had to restart with a new one!)
    * Until ~ 2016, gdocs looked like the old Etherpad — no "A4 format" paper margin, silly styling, etc.
    * But some time later, it became like MS Word (to "simplify").
    * Now in 2020, the new versions of Etherpad are trying to "simplify" to look like gdocs! They adopted a default style with a "paper"-like margin.

Remember what Ted Nelson, the OG of hypermedia, said about MS Word / PDFs already back in the 1980s:
    "WE ALMOST ESCAPED THE PRISON OF PAPER — FOUR WALLS, YOU KNOW".

Because capital's inherent toxicity — manifested via the dogmatism of tired relation of "users" of "products" — these degenerated tools are still tying us down. At least Etherpad is free software, where of course you can turn the "simplifications" off.



We need to create our own media

And to actually stop just sometimes saying that, and actually do it.

Deciding to adopt "imperfect" media is a first step of that process of making autonomy. The next ones are, together, learning to teach—learn, navigating our options & making the right decisions.



"User manuals" can help mastering tools

But as already said, using these tools effectively goes beyond just "tool instructions".
(###as we also saw in the first Spider call),

All tools, especially software tools, especially in teams, especially in fluid/ad hoc teams, are co-produced. Conventions are re-established each time.
This then especially and essentially characterizes all voluntary, activist & artistic activity, in contrast to more stable corporate employment (### tho what's up with precarious stuff? oh yeah—lack of quality).

The important thing, then, really is a "co-education" — a sustainable, continous transfering, reproducing of good practices.
### as "concoradance" and "standards" in @@documentarianism

Real, non-cynical efforts towards a superior quality in collaborative relations are the only way to birth results that are unique, non-trivial, continuous, pristine, common — beyond a template. This is the difference between ipad's diatonic synth apps ("everything you press sounds good huh!") vs analog synthesizer music. Or IKEA vs hand-made pottery.


I believe in:

1) Somewhat "paranormal" user interfaces

2) Somewhat "enchanted" user manuals

3) People - not "users" - enthusiastically willing to co-ordinate, study & experiment:
    (Rather that moan to "support staff" and "developers" because they are exposed to something Other than apple/microsoft/google)
what they might be acquainted with)
 than apple or ms)
    (By the way, in parallel - a healthy cultivation and maintenance of hatred towards mainline institutions is essential — We are different, and we are better!)

4) That in the end, somebody will always be "cleaning up" after people, no matter how many "forms" are specified, softwares "simplified", manuals & instructions & schemas & protocols "provided for reference":
or try to "apply to the production process":
    It will be messy, but must never stay that way for very long.

5) It is both necessary & good to inform the people you had to "clean after" you needed to do it:
     However, when you've had to tell them already 5x, 10x times, or 3x in a single week... Ultimately, they will either get annoyed & leave, or learn to apologize, keep trying & develop a sense of dedication. If glitchy tools can help catalyze one of these two inevitable outcomes, so much for the better.

In this way, these systems become a complex culture of beyond just writing:
writing in its extended sense:
, full-spectre, "kompakt" 
    A continous thinking together & constructively relating to each other, authoring, editing, publishing, maintaining, establishing and consolidating patterns & routines — but also integrity, resolve, patience, hope & respect.



(For a more feature-based conversation...)

see → 🔗pads-are-better




In short...

A bit of initial difficulties, will be overcome with the right and neccessary attitude!





Edit Site

Edit CSS