Has TiddlyWiki affected the way you READ?

#1

If not, check out this proof of concept. A new way to read. Surface level text that you can read as a running text, but also hidden content that can contain: supporting arguments and evidence, expansion of the basic idea in the surface level text, sources, lists and tables, etc.

Think of the surface level text as the skeleton of the argument, and the hidden text as the meat on the bones.

https://giffmex.org/experiments/proof.of.concept.Acts.7.html

Unfortunately I need to get the bugs out of the CSS upon exporting to static. I have a span class=“indent1” for the content under each red header, and also all of the red header sections should be indented from the first three lines, but it is not working yet.

Here is a taste of what it looks like in edit template:

<span class='indent1'>

<span class='burgundy'>General information</span>

<span class="indent1"><<blurbtext tid:"proof inclusio gloria">><<blurbtext tid:"proof identifying with hearers">><<blurbtext tid:"proof no xn elements">><<blurbtext tid:"proof stuff not in AT">><<blurbtext tid:"proof list OT refs">></span>

<span class='burgundy'>Themes</span>

<span class="indent1"><<blurbtext tid:"proof God act outside Israel">><<blurbtext tid:"proof themes opposition">><<blurbtext tid:"proof themes lack of recognition">></span>

<span class='burgundy'>7.2</span>

The TW used to generate this is at Proof of concept, Acts 7. About halfway down is the link to the proof of concept tiddler.

#2

Interesting idea. Reminds me of StretchText, which to my knowledge has never been fully realised at a large scale. There is a lot of noise at the moment (i.e. lots of tags and macros) in terms of typing this in. I wonder if that could be reduced in any way?

1 Like
#3

Actually once of my motivations for this was to AVOID a lot of noise while writing. Neither the surface text nor the hidden text is visible in the edit template. Just the macro with short tiddler titles.

The span classes and the indents are what create the noise in the code in the OP. But those are added at the end of the writing process.

Also, I use an editor toolbar button to add the macros one per line when writing, and only at the end do I gather them all on one line, which looks a bit messy. But during the writing it is easy to read. Paste, add tiddler title, then go to view mode, click a button (which is not visible in the static html, and fill in the tiddler.

I played around with stretch text. There are actually two almost identical plugins, the other I think is called TextStretch (I bet you would have never guessed!) :slight_smile: Very nice, but had limitations I wanted to overcome. Blessings.

1 Like
#4

I very much like this idea.

I think it works well for all sorts of data. As a programmer, I would love to see various documentation written this way. And I would want this to nest the way an outline might, so you can have hidden content inside hidden content, and so on.

I would love it, though, if it could be written much more simply, using some sort of parser that allows for something like:

<<stretch-outline """

General information

  + proof inclusio gloria
  + proof identifying with hearers
  + proof no xn elements
  + proof stuff not in AT
  + proof list OT refs

Themes

  + proof God act outside Israel
  + proof themes opposition
  + proof themes lack of recognition

7.2

  + Stephen's non-response
  + Abraham's call

7.7

  + altered Exodus quote

7.8

  + spiritual circumcision

7.15-16

  + Hebron or Shechem

7.17-20

  + Moses/Jesus parallels

7.37

  + play on Deutoronomy 18.15

""" >>

where each of the + title notations does the same thing you do with <<blurbtext ...>>, and indentation in the document translates to proper nesting in the output. While that doesn’t sound trivial, it does sound reasonably straightforward.

On a side note, although I wasn’t planning on doing it myself, I thought that a mixture of Biblical text and commentary would be a logical extension to the work I’ve been doing in my Bible wiki. I’ve been trying to build it in a way that makes it easy to extend in various directions. Second in my mind only to dealing with different translations was to consider such commentary.

1 Like
#5

I like Scott’s example - that’s what I was going for in my comment above, but the idea hadn’t crystallised as beautifully! It would be much harder though.

If I could add - I think ++ instead of indentation would be preferable for most users, as we are used to typing ** / ## for lower-level lists for example.

In an implementation like this, long-term you could perhaps extend Saq’s Editor-Autolist to do the +'s for you.

1 Like
#6

That stretch outline would be cool indeed! No clue how to do it, but it would be very clean.

#7

I started looking at this, and got to a reasonable stopping point. It is only an initial JS-sketch, nothing that is ready to include in TW. The goal was to see how to convert something like the format I gave into a usable outline in the style Dave presented.

You can see the work in http://scott.sauyet.com/Tiddlywiki/Demo/Outline/v1/. There are three files there:

  • input.txt is the data in the format above. I made a few changes, using !! for headers and :: to separate out the display names from tiddler titles if needed. Note that there is an additional top-level heading there simply to test deeper nesting. The text in this file would be fed to an eventual widget/procedure/something.

  • index.js is the code to convert this. You can run it in node with node index ./input.txt >output.html. If you skip the output file name, it just writes the HTML to the console.

  • output.html is what gets generated. You will note that things that in an actual TW would be transcluded are just listed here surrounded with {{curly braces}}.

This is only a rough draft, even of its limited capability. I would want to handle multiple different types of headers, to allow limited customization of the generated markup, to consider RevealWidgets in place of <details...>. But I think it’s enough of a draft to show the idea.

I am not going to have time this week, and will be on a two-week device-free vacation after that. So I have no plans on trying to implement this anytime soon. Perhaps I never will, or perhaps I’ll dig into it when I return. But if anyone finds this compelling, please feel free to use any of this code.

#8

Isn’t stretch text just what we would all sliders, or more details?

  • The main issue seems to me is delimiting the end of the heading and block to be opened.
#9

You can implement stretch text with either of those. In fact, my partial implementation is built—as was Dave’s original—on details/summary blocks. But the core idea is simply that it should be trivial to zoom in and out between different levels of details of your text… without leaving your document. What we’re discussing (and perhaps starting to implement) here isn’t quite the same as what I think of as true stretch text because the expanded view shows up alongside the compressed one rather than supplanting it. But I think it’s still relatively close in spirit.

#10

Cool! Just a note - I think you understand this, and I don’t want to insult your intelligence, but just to be on the safe side I’ll mention it - that the short phrases in my partial outline above which you included in your file, are from the EDIT mode. What shows in view mode are the summary fields of each tiddler, which is longer and can be formatted. This is what makes my approach now so different from my Subsume plugin or the simple title / transclusion you have in your file.

I like the idea of the EDIT template mode being more clean, just pluses. And I think that was Yan’s point too. So it surprised me that what was shown in your file looks like VIEW Template mode. Or maybe I am misreading your file.

At any rate, I love what you are doing with this. I also envy your upcoming device-free vacation. Have a wonderful time. I am taking two weeks in August to go to Michigan for vacation, but as a low level administrator I don’t have the freedom to leave devices at home. I am currently reading Deep Work by Cal Newport, and recently read his Slow Productivity, which makes my envy even greater. :slight_smile:

Blessings.

#11

Stretch text is where you click on something inside a paragraph or sentence, and the text opens horizontally to reveal an inline span containing hidden text. And if I remember correctly you can have multiple levels of expansions, like a Russian doll.

See here for the three available ones: TiddlyWiki toolmap - Dynalist

#12

I do keep meaning to implement this around maths and Physics problems and explanations.

Have the maths genius version displayed and then each stretch opens up the inbetween steps.

One day…

#13

Well, yes, I did assume that, but I didn’t think all the data was available. Somehow in the OP, I saw your sample edit markup and the output, but I didn’t actually see the source document. I’m not sure how I missed it, unless I just assumed the two links were to the same places.

I’ve made another version:

http://scott.sauyet.com/Tiddlywiki/Demo/Outline/v2/

This one fixes the problem noted above by mocking up some fake tiddlers, with just title, text, and summary information It’s at

The data there is not in wikitext; it’s just a mockup of the HTML that TW would generate from appropriate wikitext.

This necessitated some minor changes to index.js, and I also took some time to clean up a little bit and add CSS to come close to the formatting in your original.

The goal is still code that can convert input.txt into output.html. And further, the code should be written in such a way that a conversion to a TW widget/macro/procedure should be straightforward. (It’s still not trivial, and I haven’t considered all the details, but I’m pretty sure it wouldn’t be overwhelming.)

I took some liberties with the input data:

  • I removed all the hardcoded + links in the summaries, and added them instead to the CSS for the <summary> tag. This also allowed me to replace them with – tags when the details are open. It also simplifies the entry of the summary material. (Edit: I originally forgot to upload the version that had this+/- behavior. It’s there now, but might take a hard refresh to see it.)

  • Although I cannot find them now, I swear I saw some places where there was a superscripted link at the end of the summary or text. They seemed to be invisible, and I took the liberty of removing them.

  • I stole the CSS rules from the static document, but took the liberty of simplifying a number of them.

  • I kept my additional “Nested” entry, to show how the outline doesn’t have to be top-level only. But I moved it to the bottom of the input.

The input looks like this:

!! General information

  + proof inclusio gloria 
  + proof identifying with hearers
  + proof no xn elements
  + proof stuff not in AT
  + proof list OT refs

!! Themes

  + proof God act outside Israel
  + proof themes opposition
  + proof themes lack of recognition

!! 7.2

  + proof 7.2 no answer
  + proof Haran or Ur?

!! 7.7

  + proof 7.7 Messing with Exodus quote

!! 7.8

  + proof 7.8 setup for 7.51
  + proof Abe omissions

!! 7.15-16 

  + proof where buried?

!! 7.17-20

  + proof parallels Moses and Jesus

!! 7.37

  + proof raise up in Dt 18

!! Nested Demo
     Another Level
       Even Deepter
         + proof 7.2 no answer
         + proof Haran or Ur?
         More here
           + proof list OT refs
     One more for good measure
       + proof where buried?
1 Like
#14

WOW that looks really nice! To see the edit template look that clean, and the output nearly identical, that is amazing.

Did you notice in my macro that each line has a secret edit-template button? If you go to the site where I have the generating TW (Proof of concept, Acts 7), and in the SHQ sidebar click the button “Hide gray e” stylesheet, you will see gray letter e’s on all the macro lines. This is the other secret weapon in my macro. I can click lines from the article tiddler to open and edit them.

This macro set up was the result of years of experimenting and learning for me. And here you are whipping up a much cleaner version of it in two days. Super duper impressive.

#15

Ahh, that’s what those were for. I removed them, but it should be trivial to add them back. The trouble is in balancing between making this a useful general-purpose outline edit tool and something tailored to your use-case. To make this really useful, I would probably allow the user to supply a macro/procedure to handle the markup of the summary and another for the detail text. The default would be something like the above, and you could override the summary one to handle the edit link. There would also probably be a default stylesheet supplied with the code, with the assumption that the user would be altering for their purposes.

Not at all. I did a mockup of a way to go about this. And I had the advantage of your design to guide that mockup… the shoulders of giants. All I did was to see a way to make a nicer input to build this from.

#16

For the record, or perhaps just for anyone curious, here’s my original implementation of StretchText. It was probably one of the first plugins I made. It inspired Thomas to make another version.

1 Like
#17

@telmiger just had a play with TextStretch and checked it again on tiddlywiki.com and when opening one stretch it opeans them all!

#18

Did you use IDs?

See the documentation: “Elements with identical id open and close at the same time which can be useful or funny in rare cases. Elements with identical content open together too. You can separate them using unique id’s.”

#19

I had just dragged across the instalation tiddlers and your example tiddler and observed that behaviour.

I haven’t had chance to explore more.