The Many Clicks Problem to See Mother

Meta
#21

Ciao @pmario. I respect your opinion. And I will shut-up on the issue. Creating contention, which it looks like I might, would never be my aim.

That said, truthfully, I’m not 100% convinced you are right that embedding “limits possibilities”. I would say it is Contextual.

I am wary of having people say “this is it” when it is reduction to a rule. I still think iframing could be good often.

But, to not get stuck in an argument I’d ask this …

HOW do we better integrate live usage of TW into Discourse? I guess my OP was really about that.

Best wishes
TT

#22

The main page, yes. It’s too big. But what about subsets, when you want to point to a reference tiddler (e.g. static tiddler). Or use the share plugin, which otherwise isn’t getting much use?

1 Like
#23

As I wrote, it would be worth to explore, how we can add the right meta data, that https://tiddlywiki.com/static/all%20Operator.html can create the “card like” view in Discourse.

It would be nice, if the card has enough information in it, that the user can continue to read the topic, without even clicking the link.

1 Like
#24

Point taken. I do think it worth noting that the point here devolves to “bandwidth costs”. I think it a general issue, perhaps, on the net, that costs may still be seriously messing up access to basic functions? Just saying :slight_smile: .

#25

I think TT wants more than that.

Nevertheless, apparently if we could add description tags, or whatever useful tags we wanted to the headers of the static pages, we could get a “rich card” experience. “onebox”, if I’m understanding the thread correctly, is the tool Discourse uses to extract link info.

2 Likes
#26

Right. I was / am interested in bridging the gap between talking about our thing and actually having it liveish.

That said if any ordinary user could easily add a “card” such that, easily, it would turn up here it would be good!

BUT how real is that? What I mean is it is not so clear how that would work, yet.

Best, TT

#27

A card to any arbitrary site, or a card to a static tiddler?

The former, not so much, the latter maybe if you could convince Jeremy. I think it would be useful if it could be added to the static images, because likely Google uses the info in its search engines, and many other sites probably use onebox or something similar to present information as well.

Edit: The rich cards seem to be pretty limited in what they can offer. A title, an image, a two line description, a link. I couldn’t get the url link to work correctly. Presumably this could be ironed out if there was interest.

1 Like
#28

Lack of this in single file tiddler is one of the reasons – from social sharing to SEO – that I can’t really recommend it.

Many links get shared via chat or forums or Twitter – and social previews are very valuable.

This was discussed previously:

And we also removed rich link previews for tw-dot-com

#29

Right – not good for single file wikis. But TW’s parallel static website could have the appropriate OG headers embedded. Including, possibly, a url link to the single file at tiddlywiki.com.

Another possibility –

The blog I linked mentioned that Discourse has “recipes” included for Google, Facebook, etc. That suggests that we might be able to make our own recipes that know how to display from single file TW. Possibly where we define our own url structure without the # symbol but the recipe knows how to bake it back into the output. Like a link to the all operator might look like:

https://tiddlywiki.com/all%20Operator

But the recipe could create the output link as:

https://tiddlywiki.com#all%20Operator

2 Likes
#30

The recipes are just for parsing header / open graph / Twitter info. Single file TW / anchor tags don’t carry this info since it’s just a single HTML file.

And yes, totally doable for statically published TWs. Much like generating feeds, open graph support by default for publishing would be an important core feature of such a setup.

This is also a common / emerging pattern for many note apps — where published files are generated from a more dynamic app.

1 Like
#31

FYI: The above format works out of the box is static tiddlers have being published either as separate files, or automatically by a node implementation.

I have long believed if static tiddlers are published (individual or server generated) that all their links should not point to other static tiddlers but to the permalink within the wiki. This would mean any interaction with a static tiddler, used as a link would load only the target tiddler but any further interaction load the wiki for a full interactive experience.

So if “mother” publishes all tiddlers as static but linked back to mother at publishing time this should work well. The only gap is capturing recent changes to content and adding updating such static tiddlers on the host. It should be easy to create one or more static tiddlers whos modified date is newer than the last static tiddlers export, that the wiki editor can generate from the wiki to the host.

This is in someways related to my recent thread Sending a tiddler or tiddlers via email? which could generate submissions for changes to apply to “Mother”.

#32

Right. The more we simply connect to real TW the better IMO.

Shirley, that is the point? :slight_smile:

TT

1 Like
#33

Erm. Not so sure.

What can I say? I’d guess whichever method could be done it is always best to easily invoke a live TW. Otherwise why do it? Something like that.

Best, TT

#34

I wanted to follow up on this. The whole “card” thing.

FYI @joshuafontany wrote an experimental plugin that hasn’t had the attention it deserves for TW “Oembeds” https://github.com/joshuafontany/TW5-Oembed. Unfortunately the demo doesn’t seem to be working ATM.

Best, TT

#35

This is just thinking out loud. The recipes are apparently written in a Onebox “Gem” in Ruby (on Rails). Presuming that a headless browser driver exists for Ruby, then it might be able to fetch and parse the actual contents of an address to a single tiddler and set up a more responsive “card”. This would make setting up cards much easier because rather than using a special description field, there could be a default fall back that takes the first 100 characters or so of a tiddler as description.

Just throwing this out there in case there are any bored Ruby programmers hanging around.

1 Like
#36

This is for embedding other things in TW, not the other way around.

2 Likes
#37

@boris … Ah. I didn’t realise. Shucks. Sorry.

#38

Although the Other thing we embed in TW could be from a tiddlywiki !

  • If we can make tiddlywiki objects Oembeddable in other sites or wikis, ideally also through and then interrogate them within tiddlywiki it would provide a form of interwiki communication.
    • Tiddlers in wikis, static tiddlers or seperate .tid or .json files could be embeded?
  • Sometimes only a few bytes are needed to make a big difference.
2 Likes
#39

I remember @telumire invented an smart solution to use Tiddlywiki lively in a Talk post!
I could not find the thread!

#40

Thanks for keeping this thread alive!

My point in the OP was that there is a “distance” (visually) between Discourse and TW.

I simply think TW would do better if we could integrate a “TW Look” into Discourse.
I did suggest that rather than having links to TW-wikis we embed them. BUT there was concern on it being too much—that it would cause problems on bandwidth & performance here. So I, basically agreeing, abandoned that idea.

However, I still think we could maybe do more to "narrow the gap between talking about TW & using it??" And visual appearance is a big part of that.

I hope this is clear!
TT