I agree and I correct myself. I also meant user groups or segments.
IMO, without a clear definition, it can be challenging to move in a certain direction (like growth), strive towards specific goals and make respective decision in the long run (incl. non-feature-related decisions).
That’s my point 
[Filling in the blanks] … with good example wikis of variant solutions to look at.
Just a theorem, TT
Are we talking about TiddlyWiki or the tools around TiddlyWiki here? Do you call everything TiddlyWiki?
TiddlyWiki itself, as I see it, is just a passive html file. It contains the application, but requires e.g. a browser to run it, inside a sandbox. This is somewhat like Docker, running container images.
But then, to escape that sandbox in the browser and save changes to disk, we need more tools, from Timimi to TiddlyDesktop and Tiddloid to the Node.js API wrapper.
Then, if you’re like me, you want your TiddlyWiki synchronized to your phone, which is beyond even these tools, adding even more to the technology stack.
I think the tooling, or the engine that runs it all, is what makes TiddlyWiki difficult to get started with. It’s is not a complete product – the batteries are not included! And oh, so many choices!
The fact that TiddlyWiki is so popular despite the above, probably says something about the actual audience, but maybe not the target audience. You’re probably smarter than the average bear, like to try and build things, aren’t afraid to break your computers, avoid the mainstream, commercial, easy solutions, and so on…
This is NOT true. By default, a stand-alone single-file TiddlyWiki uses the browser’s “download a file” mechanism to save your changes. No additional tools are necessary. The only issue is that some people don’t like the user interaction that the “download saver” requires. The “additional tools” are used to bypass this interaction.
Personally, I like the interaction afforded by the default download saver. It ensures that I make a conscious and deliberate decision each time the file is saved, and also lets me pick the target file and folder for saving.
This enables me to create incremental “checkpoint” files while I am working, which give me the ability to “undo” any serious errors simply by reloading a previous checkpoint.
When I am completely satisfied with my changes, I just save again, and select the original file and folder as the target for saving. I can then go to my desktop and delete the accumulated checkpoint files to clean up… or, I can leave the checkpoint files there, just in case I discover a problem later on. Then, I can use those checkpoint files with a “diff” utility to help identify the bug by determining when it first appeared.
-e
I boil the growth of TiddlyWiki down to how successful the group of developers that have final say on what code gets committed to the project and the building of a diverse, passionate, unified community on which it relies. Both take an incredible amount of effort and can conflict with each other.
The project has to be managed to provide direction, stay on track and not lose focus of the fundamentals which made TwiddlyWiki the product it is today. A healthy community is going to push boundaries. Too many wrong decisions will hinder the growth.
The community needs a forum that is responsive with contributions that carry weight and can make an actual difference. The future of TiddlyWiki relies heavily on the community. Not easy to maintain, just ask the leaders and moderators of this discord. Can disappear in a heartbeat.
As long as the balancing act between these groups can be maintained there is nothing that can stop the growth of TiddlyWiki.
To take this important discussion forward I have started some other threads, Please concider directing your passion for TiddlyWiki towards real outcomes.
These are a result of what I have read in this extensive thread and reoccurring themes seen in the Forums including Google Groups over more than a decade. It seems to me these are the begining of a practical answer to How to stimulate User Growth of TW?
Yes, a good point. BUT, tooling makes this much more convenient. I use git to create checkpoints automatically every hour, so I get the same thing without effort.
This is my current solution, which I’m not completely happy with, but it works.
Despite all that, I still cannot e-mail my TiddlyWiki, which is a feature Evernote had way back.
What I’m saying is that in order to match the offering from e.g. Notion, we need a complete solution with automatic persistence, synchronization and external APIs, not just reworking the html file. Your focus is making the box “TiddlyWiki.html” better, mine is on the solution.
I think we have the same objective, I just want to start with the private, LAN and read only published wiki’s. In part because 70% of the design and documentation issues are the same and we need to start simply. Perhaps what you want would be nice to provision on a server, so people can get TiddlyWiki as a service TWaaS, but I cant see anyone not already convinced about tiddlywiki doing what you have especially with little IT or Developer skills.
I think if we can give casual users a great experience, they will become enthusiasts and later start using more sophisticated setups and solutions.
Ciao Eric
I remember in the past I was critical of using the “default” (fall-back?) saving mechanism.
But I actually, now, think it is a rather good approach.
Users may need instruction to use it optimally?? (i.e. set the browser saving thing to let you pick destinations), but it does the job with no add-ons needed.
FYI, in my use case on FF I use auto-Timimi previous (that allows execution of programs) for save. It is good and just does the job.
On everything else, for saving, I’m now following you approach as you don’t need anything more.
It works. It is unfussy.
Just comment, TT
NO. Let’s not get in a bind here.
The issue is not TiddlyWiki, it is general Browser clampdowns (from worries about security).
There are ways to get round the limitations of browser clampdowns.
All of them, as far as I can see (for singular web pages), require installing a “back-end” stub, that permits interaction from the browser with the Operating System.
Just a comment
TT
I also prefer this, especially when I am experimenting with new ideas or when I am adding new plug ins to my wiki. Also I name and number the new wikis based on the plug in or idea added - so it’s easy to find out cause of bugs if we discover them only at a later time.
If it worked on mobile I might reluctantly concede.
The default fallback saver works properly on recent versions of iOS on iPhone and iPad. I’m not sure about Android, but the only requirement is a browser that can download files, which I think now is most of them.
On Android you can’t set the download location, have a pick-file dialog for the location, overwrite the original files, and it mangles both the prefix and suffix of the original file name in unexpected ways.
I have to admit I find myself grabbing a copy from tiddlywiki.com or tiddlywiki.com/prerelease for quick note taking, or experimenting, and using the default “download saver” often, but not as often as I’m starting or restarting the local node server.
But I think Offray puts it well in their new thread:
As usual, we try to simplify infrastructure to amplify/diversify participation.
Some people are more used to an experience where the data-storage is handled “in the background”, and even juggling multiple standalone wiki files (and their backups) can be overwhelming. I think single file wikis are one of the key features of tiddlywiki. But it has taken me a while to understand how tiddlywiki renders an HTML page from-itself-in-active-memory (standalone download saver, or when you first hit that page load request on the node server), and that this process of filtered-transclution-template-rendering can be used to render OTHER static HTML content. Now I want TWaaS, because exporting standalone “published” wikis with a subset of content, or as deep-storage backups is a great idea.
More thoughts after my job interview. 
@joshuafontany “Break a leg” - TWaaS starts with tiddlyhost of course.
Tiddliod works well and you can provide a link to a Wiki to install it the first time. But yes tiddloid is not the default saver.
I am trying in now on my Andriod 11 - firefox browser, Once downloading it prompts to open and lets you select an app and oddly firefox is not one of them, but I opened it in chrome and this is the resulting address content://media/external_primary/downloads/13642 this suggests to me its a “special protocol” and firefox is not currently aware of it.
Of course the “default fallback saver” is important, the main issue is one needs to either;
The problem comes about with subsequent use, it typically relies on the user remembering something on all platforms when;
As a result of these kinds of complications I started the discussion Make TiddlyWiki your own - discussion for this very purpose.
The issue is not so much the download saver it is the workflow and the user remembering to return to the saved wiki going forward.
There may be an opportunity somewhere in browsers, guidance info, or the workflow to assist with this. In other product’s available they can install a PWA - progressive webapp and this comes with various bells and whistles but still users the browser “engine”.
Package it as an app available on all the major platforms and include a proper (read: seamless) syncing mechanism. I’ve been using Tiddlywiki for my entire adult life, and the thing that keeps me looking for and trying other options is the difficulty in getting Tiddlywiki to sync seamlessly between both my phone and laptop. Currently I use both Google Keep and Tiddlywiki, the former to jot down thoughts when out and about, or when I otherwise don’t have my laptop handy, and the latter to journal (expand upon thoughts I’ve had over the day, or week). It feels disjointed using two apps, but as it stands, Tiddlywiki doesn’t meet my needs by itself, due to the lack of a seamless user-friendly synching mechanism.
@Elijah although I think we should make it easier and more obvious this has already being addressed many times, The use of syncing is but one way to address this and in my view not a good one. i made some suggestions here How are conflicts dealt with in Tiddlywiki when idiots like me are involved? - #10 by TW_Tones
I made a thread so that we can discuss potential names for tiddlywiki :
As someone who is just starting to play with TW and have started sharing the link around with friends, I think that the first major hurdle that TW needs to overcome is its design. The UI/UX looks like it was designed by programmers, not designers (I say that as a programmer myself, part of a team that has 40% just User Experience and Visual Designers).
It is, in my experience, when a professional designer takes wireframes (in our case, the app itself!) and does visual treatment that the apps suddenly gel and feel fresh and professional.
That applies also to the content on the homepage, etc.
Visual Designers have a different angle that even design-sensitive developers don’t. It’s the last phase that makes an app become a product.
