TiddlyWiki is very powerful but gives too much freedom to new users. I lost myself: A story and an idea

Which puts me in mind of Dialectical Journals.

1 Like

Of course. And many, many more. That’s part of the challenge. I could have listed a dozen more without searching.

Yes, that’s what we’d want, but ideally not with an overwhelming amount content. Perhaps we need an edition wiki, which is the empty infrastructure with some minimal documentation of how to use it alongside an in-action example of a wiki built on that edition. A recipes wiki would probably have to have three or four categories with 20 - 50 recipes, not the 792 recipes in your personal cookbook (not counting Auntie Frieda’s weird gumbo!)

I’m pretty sure that would be straightforward, with one significant caveat. We could wrap those tiddlers in a plugin, and offer a button that simply toggles the plugin-type: plugin field on or off. (This would probably require a save/reload cycle.)

The caveat, though, is that to address these, we’d need to add [all[tiddlers+shadows]] to a lot of filters, including many otherwise simple ones. That might be a real impediment.

We could do something similar without that caveat – but with much more complexity in implementation, probably beyond my own skills, but possible for the experts. We could have a plugin-like JSON file holding the tiddlers we might want to hide. These would be promoted to real tiddlers by some (right now imaginary, even magical) process. When we want to hide this content, another magical process looks for all of these that have not been altered from their original (except for created/modified fields) and removes them… then possibly asks the user, for each modified tiddler, whether to keep or remove it. At any time that initial process can re-run, but won’t overwrite those that have been kept, or again offers the user the choice whether to overwrite the current copy. This has all the benefits of my first suggestion, without the caveat. Its own caveat is that it would be much harder to implement.

Absolutely.

Wait, what?!

Sure, just stab me through the heart, will you?! :grinning_face_with_smiling_eyes:

I use these all the time! I think I do so appropriately, when I want to focus on layout or design, and don’t want any pesky, realistic content to distract from the point.

Of course they don’t belong here, but please warn a man before you slaughter his sacred cows, would you? :wink:

That is a fantastic analogy!

1 Like

I know. He’s really good at those.

@Springer I hope you’re putting virtual pen to virtual paper somewhere more lucrative. Seriously.

In the demo wiki I shared for building “take away wikis” I quickly came to realise an effective solution goes further than prepared editions. There is two areas that make this more complex we just have to face;

  • The curation of diverse resource, tools, components, plugins and editions.
  • Presenting this is a way that supports the equally diverse set of user requirements, depth of experience both code and structured thinking.

This is supported by the Original Topic and the perception it reflects.

Editions or plugins are insufficient on their own to curate the possibilities.

Actually some of my explorations suggest we may be able to achieve this one way or the other already. If we could state the functional requirements I may be able to deliver a solution.

  • I may already have one, such as data plugins.

I have explored similar solutions already and the current plugin mechanism is eminently hackable as in my demo site https://takeaway-wikis.tiddlyhost.com/ see the disabled plugin, sometimes simply disabling the plugin is sufficient, and code can be written to look inside the disabled plugin to extract tiddlers.

But just as I say above to @Springer just help me spell out the requirements I am confident I can deliver. Unfortunately this is a common end point in our community, because we are not too good at collaborating to define robust requirements and end up getting lost “in the weeds”.

One thousand :+1:

In addition to banning “foo bar” and other “content deserts” in documentation;

  • Provide examples that use parameters, fields and variables not just static text.
  • We should have a publicly shared sets of data which can be use by the whole community. eg Ford Family for Genealogy, Periodic Table of elements as I published here https://test-data.tiddlyhost.com/

Another consideration should be what we install to build a wiki, and what we install to design the wiki. For example link to tabs could be essential in a design phase but disabled or removed to simplify/publish a wiki.

  • That is some things are installed to serve a temporary function
  • Do these belong in an edition or not?
3 Likes

In a recent thread I asked for a way to include another namespace in the is[system] test and this proved to be trivial eg $:/ system denotes system tiddlers and &:/ could be added, then all the existing is[system] and !is[system] tests include tiddlers with &:/

  • Perhaps we can do something similar so we do not need to modify [all[tiddlers+shadows]] throughout the wiki, but for example adds and exception to the all
  • or perhaps we can build a way to make “selected” shadow tiddlers look like real tiddlers without editing.

She’s a professor of Philosophy at a highly-regarded liberal arts school (my alma mater!).

I doubt it’s particularly lucrative, but I imagine it’s a job where such skills are well appreciated.

2 Likes

Yes, I was thinking about two plugins I have written, they started simple but now have extra features that another user might find idiosyncratic and prefer the earlier ‘vanilla’ versions, yet these enhancements are vital to me and so are the driving force in the writing of those plugins.

I found myself thinking it would be great if plugins could be written with such perfect granularity and wisdom in structure that they could be easily configured by the end user, almost like selecting candy in a mix-and-match store but I think these are idealistic dreams that would be tough to realize.

I reflected on the number of plugins I tried to work with before I wrote my own and why they didn’t fit me. I then reflected that I endured Windows for decades before migrating to Linux, yet I never moaned that Microsoft didn’t offer me the precise flavour, UI, functionality and granularity that I wanted, I had to learn to use the tools provided and if I did ever moan Microsoft were not listening - what we say we want is usually inline with realistic expectations and so everything changes when people migrate to more flexible platforms like TiddlyWiki or Linux, certainly my expectations have changed as my ability to code and configure have increased.

This leads me to the wonder that however valiantly TW volunteers advance the ‘core’ and strive to maintain a useful ‘vanilla’ core product that many of the people involved with and supporting Tiddlywiki are either hackers by nature or may be on the path to becoming such. :slight_smile: I use the term hacker here to refer to someone who gives up on the conventional tools provided and starts making their own tools.

There will probably always be a slight tension even within the same person wearing both hats - trying to produce a good useful vanilla product yet like dogs let loose from the leash people will tend to produce idiosyncratic and individualistic solutions if they are able and may find it difficult to find balance.

The difficulty is in a crowd working together to somehow migrate the more useful hacker output to a more approachable and generic useful tool kit? Certainly my plugins which started off reasonably vanilla are starting to look like one person’s way of working and that in some ways echoes with my disatisfaction with existing solutions when I was not really able to write my own.

One thing that might be useful is an examination of methods and architecture that might enable plugin writers to offer additional options as modules that can be easily included or ignored with that ease being there for both the user and the code writer. Flexibility and levels of granularity? Perhaps the new conditional functionality (if else etc) will allow writers to offer plugins with a greater level of modularity and flexibility for the end user - conditional includes/transcludes?

4 Likes

Thankyou @etardiff for the suggestions, I’m currently having a good time looking at them :grinning_face_with_smiling_eyes:

You explained my feeling perfectly.

As for PowerSearch, I found it really nice (but I feel like the older version’s ui is more clear for a new user if we want to do something similar, the new one is cleaner but shows little, its potential remains “hidden”)

Totally agree, especially with:

Provide examples that use parameters, fields and variables not just static text.

For me it was very important for my learning of tiddlywiki the possibility of reverse engineer the solutions other users proposed.

Therefore:

I really don’t know if they would be useful. They could complicate things.
BUT I really have to admit that since I installed “link to tabs” I started learning almost twice as fast (I don’t know if it was something that would have happened anyway, but link to tabs allowed me to give vent to my curiosity and therefore I learned a lot.)

Maybe we could do 2 almost identical editions?

  • Standard edition
  • (and more hidden, but still aviable) “With designer tools”

So the user chooses for himself what he wants.
I think the “With designer tools” edition should be harder to find, it should not be presented immediately, perhaps it is hidden after some text (in this way it will be discovered by those who are truly more curious and have more desire to learn and not by the user who wants use TiddlyWiki without complications. Natural selection :joy:)


…a way to make “selected” shadow tiddlers look like real tiddlers without editing.
I advise against it

Precisely because a user learns a lot by studying and playing around with what already exists or with the solutions proposed by other users, making them ambiguous could only create confusion.
There may be a risk that looking at these tiddlers will give you the wrong idea of ​​what constitutes a “shadow tiddler”.


I would do something even simpler: A collection of example tiddlers tagged with “Sample tiddler”. In a tab in the sidebar or somewhere else we have two buttons:
"Delete all sample tiddlers"
"Install sample tiddlers"

The first is self-explanatory, the second is a link to a tiddler package that the user can install as json (or other methods)
Something like that, just an idea

2 Likes

Currently, the https://TiddlyTools.com/#TiddlyTools%2FSearch%2FFilters interface defaults to “hiding” the “Filter Builder” controls inside a popup that can be quickly displayed by pressing the “tools” (hammer and screwdriver) button that appears next to the “Filters” list dropdown button. This was done in order to present a less intimidating interface that works well as a feature-rich replacement for the standard $:/AdvancedSearch > Filter tab while making the “Filter Builder” popup controls just a single click away.

However… one aspect of ALL TiddlyWiki popups is that the visibility of each popup is controlled by a $:/state/popup/... tiddler, which only persists for the current session, and is automatically discarded when the document is saved.

It would be relatively easy for me to change this behavior so that the Filter Builder visibility is stored in a non-volatile $:/state/... tiddler that would be retained when the document is saved. Thus, after the “tools” button is clicked once to display the Filter Builder, and the document is then saved, the Filter Builder controls would be visible by default until manually hidden.

In this way, if the TiddlyTools/Search/Filters were included in a “starter” edition, it could be set to initially show the Filter Builder controls, which may be “more clear for the new user”.

Does this sound like a decent “compromise” solution to you?f

-e

2 Likes

These are interesting reflections. I believe we could start opening a collective project.

Since what we are trying to build is a simple edition, in my opinion it shouldn’t be too complicated (besides, I’m an incurable optimist)
Now I’m talking about “editions” because in my opinion it’s the first step to take: Let’s start with an organic product first, which is also the easiest thing to do. then we will think, if necessary, about making it more “grainy” and flexible. I would say first let’s try to see what direction it would take

Yes, I don’t know how easy it will be, but I’m honestly quite optimistic. What is certain is that we need to build something that encourages customization, but still gives a foundation to build on.

Perhaps rather than “encourage” I should say “allows” customization. I don’t know how to “encourage” custiomization or if encouraging it is the right thing to do. But giving the tools to the user to make it his own is the best thing we can do.

  • In this regard, I share my thoughts on something:

    I have already mentioned that I learned to use TiddlyWiki by deconstructing other users’ solutions, that link to tabs was very useful to me, etc.

    I would encourage, wherever possible, building plugins for a “starter” edition with code readability in mind.
    Sometimes I imagine it is necessary, especially for more ambitious plugins, to use many transclusions and many different tiddlers, but for the user who wants to learn, reading codes that are too branched out is very difficult, and learning opportunities are lost.

    I say this as a complete inexperienced person, it may be a bad habit to try to give priority to the readability of the code. I do not know. So forgive me if I’m wrong. But I wanted to say it, because if it is possible, it can help inexperienced users a lot. (Maybe this should be considered for the most linear and simple functions, for more complicated things, the priorities are different)


I don’t know how we could organize ourselves, I don’t even know the possibilities of this site, but I would say to focus on building a couple of very simple “starter editions” of different categories.

Maybe a “recipe starter edition” and a “note-taking starter edition”. (Idk, just an example)

We could create two topics and two projects: In the topic we collect which functionality we believe could be the best for the purpose of the edition, perhaps also using polls. Maybe we can also share some of our own solutions and discuss whether they can find a place in a “starter edition”.
Then we could start compiling them and we see where these projects take us.
In short, test the waters

Yes, that seems like a good idea to me :+1:t2:

To resolve this issue we could ask people what the first thing is they want to change, or customise. Some will want themes and fonts, other would want dark mode, I like a contents tab, and more button active on the Page Controls, Yes I want relink most of the time, my not until my wiki demands it.

  • This would help build an initial list for a not empty edition.

@snapsam:

As per our discussion, https://tiddlytools.com/#TiddlyTools%2FSearch%2FFilters has been updated so that the “Filter Maker” visibility is now stored in

  • $:/state/TiddlyTools/Filters/filtermaker (a persistent state tiddler, retained when the file is saved)

instead of

  • $:/state/popup/TiddlyTools/Filters/filtermaker (a transient state tiddler, discarded when the file is saved).

Note that while $:/state/... tiddlers (but NOT $:/state/popup/... tiddlers) are retained when saving, changes to those tiddlers do not automatically cause the current session to become “dirty” (see $:/config/SaverFilter) and will not result in an “unsaved changes” warning when exiting. Thus, if you haven’t made any other changes that need to be saved on exit, you will need to manually invoke the “save changes” button to preserve the current visibility state of the “Filter Maker” before exiting.

2 Likes

This is why I suggested that rather than try to collect one edition of the most useful tools, we should have many, covering multiple types of TW, each one with its own set of plugins and bespoke tools. I think trying to create a useful advanced starter edition is likely to fail because of the inherent complexity. Smaller ones can highlight both the uses of TW and the power of specific tools.

That’s a great idea! This could be a much simpler way to manage what I suggested above. I don’t know how far innerwiki implementations scale; if they can hold twenty or thirty subwikis, this could be an amazing tool!

(BTW, there is a typo on the home page, which means that “Near Empty TiddlyWiki Edition” leads to a missing tiddler.

1 Like

My dayjob does involve putting pen to paper, and fingers to keys.

I have even actually earned a few royalty checks in my life. Distributed over the course of about ten years, it has added up to about enough for half a month’s worth of mortgage. So, I don’t know if you could call it “lucrative”. :rofl:

1 Like

Ha! Me, too! I think it amounts to a little more than that, but I won’t be quitting my day-job any time soon. :cry:

1 Like

I think it would be interesting to fold a little more of the DesignWriteStudio material into the community editions. This is part of Steve Schneider’s course where he uses TiddlyWiki to teach concepts about hypertext. I think of the barriers to making effective use of TiddlyWiki is understanding some key “tiddler philosophy” which long time users have internalized, but have profound implications for understanding how to use TiddlyWiki.

  1. The philosophy of tiddlers

The philosophy of tiddlers is that we maximise the possibilities for re-use by slicing information up into the smallest semantically meaningful units with rich modelling of relationships between them. Then we use aggregation and composition to weave the fragments together to present narrative stories. - Source

  1. Every tiddler is a tag is a tiddler. (TagglyTagging)

  2. A link to a tiddler is a form of tagging. (my own thought)

It is worth also to create a diagram or mind map or even an outline from time to time to help see the structure of your TIddlyWiki from a different perspective.

:+1:t2:

Yes, I was then convinced of the same thing too. Multiple editions/solutions for different needs


  • What do you say?

Shall I create a new topic where anyone from the community who wants can start exploring what the best solutions could be for a particular use of TiddlyWiki?

I would start with something common like “note-taking” or “journaling”. Then we’ll see where this little initial project takes us

Please tell me what you think or what the best way to handle this would be

Maybe we could start with a general thread to:

  • Vote to see which uses (e.g. note taking, task management, cookbook) are most popular and to discover some niche uses that we might not be aware of.
  • Discuss the problems of creating, curating, and presenting these “editions”. Maybe a separate thread to discuss the technical backend would be good. Some of this has already been discussed above.

And now for something completely different.

We have the “Showcase” category here on forum to share real life examples, but this is not easily discoverable from main site. This is not as helpful to newcomers as the discussed editions, but at least we already have a lot of content for that.

There is the Examples tiddler on main site (also presented as a tab in Community, which is displayed in the river by default), which contains a short list of examples, not updated since a long time, and imo rather exotic examples.

Link to forum Showcase category from the Examples on the main site would be the simplest thing to do for now.
In the long run, cataloguing of all showcase examples in links.tiddlywiki.org would be ideal (there’s not so many of them after all, and I see some are catalogued already).
And the last thing, that requires work, but not more than what is discussed here. I think even after the entries from Community tiddler will be removed form the homepage (after moving all to links), it would be nice for newcomers if a curated short selection of plugins, editions, and examples would be presented on homepage.