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?
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 .
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.
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.
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:
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.
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 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.
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.
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.
.