Hello, @jeremyruston and I would like to request your support to help analyse the Community Survey.
We want to be able to present the key points of the results in a visual and useful way, which gets across the main insights from the survey.
If you are a statistician, or just want to try your hand at data visualisation, we would love to hear from you. Please write below or send me a message, and we can arrange access to the data so you can start your analysis.
Happy to help if extreme urgency is not required.
The 159 public responses to the survey received so far are now also available in TiddlyWiki format:
https://tiddlywiki.com/prerelease/surveys.html
Note that while I’m still working on it the 2025 data is currently only part of the prerelease.
There are a few issues that I hope to address:
Some interesting provisional observations:
The format of the response tiddlers is very simple:
first-heard-survey, other-survey-source, are-you-a-dev, first-used-tw, joined-tw-communityetc)I’ve started on the data from the spreadsheet and have worked through most of the “data engineering” tasks via scripts, doing analysis now, but will have to do just a little each night for probably a week or so.
From taking a look through things, approach will be:
Example from progress so far:
One other quick observation about use-cases
140 users selected “Knowledge Base”, winning as most common overall. This was followed closely by “Note Taking” (134), “Project Management” (84), and “Journaling” (74). What’s interesting to me is that the “Hello There” tiddler on TiddlyWiki.com doesn’t actually mention “Knowledge Base”, and in fact the only search results are two external resources. Seems like the site could better communicate it’s value as a Knowledge Base? We also don’t advertise that much around Project Management (although that happens to be my use case), but maybe that’s because “empty.html” is not great at that, need some editions / plugins / etc. to make it good here.
Question for @jeremyruston or @yan - what output would be desired, should I translate analysis into TiddlyWiki and put on a Tiddlyhost site or similar? Anything you’d like sent privately vs. posted publicly. Feel free to message me privately.
I was interested in the wiki-setup-info portion generated by the info tiddler. I didn’t sanitize the data much, so if the data was in a different column I may have missed a response.
the charts look great. The one piece of information I would find valuable on these, is a flag on the default setting for these (where suitable for the data)
Added a default setting indicator on the charts were applicable.
I did copy paste the survey results inot Mistral Le Chat LLM. It was the only one, that allowed so many input tokens in the free version
I did ask some additional questions, and got some good summaries and answers.
Then I did compare it with Google Gemini-2.5-pro CLI
I did download the survey xlsx file, convert it to a CSV and feed it to the LLM, which is in beta at the moment.
I needed to copy the responses into this post, since the CLI can not be shared with a link. Only saved locally.
I think there are some good ideas in the responses.
The questions where:
Based on the provided data from the 2025 TiddlyWiki survey, here is a summary of the findings:
The survey captures feedback from a diverse group of TiddlyWiki users, ranging from veterans who started using the software in 2004 to newcomers who just began in 2025. A significant majority of respondents identify as programmers or software developers.
Key Use Cases
The primary uses for TiddlyWiki are heavily focused on personal information management:
* Knowledge Management: The most common use case is creating personal and technical knowledge bases.
* Note-Taking & Journalling: A large number of users rely on it for daily notes and journaling.
* Task and Project Management: Many have adapted TiddlyWiki into a personalized system for managing tasks and
projects.
* Creative & Niche Uses: Other popular applications include worldbuilding for games, narrative writing, and as a
platform for programming projects.
Technical Profile
* Saving & Hosting: The single-file HTML format remains a core and highly valued feature. Users employ a wide variety
of saving and hosting methods, including the default browser saver, desktop applications like TiddlyDesktop, custom
savers (Timimi, TiddlyPWA), and server-based setups with Node.js. Cloud storage (like Dropbox/Google Drive), Git,
and Syncthing are popular for synchronization.
* Customization: A high degree of customization is the norm. Many users are comfortable with advanced features like
widgets and filter expressions, and a large portion write their own custom HTML, CSS, and even JavaScript to tailor
their wikis to their specific needs.
User Sentiment & Feedback
What Users Love:
* Flexibility and Control: The most praised aspect of TiddlyWiki is its near-infinite customizability, allowing users
to create highly personalized tools.
* Privacy and Data Ownership: Users deeply value its local-first approach, which ensures privacy and full ownership of
their data without reliance on third-party services.
* Longevity & Stability: The project's long history and commitment to backwards compatibility give users confidence
that their data will remain accessible for years to come.
* The Community: The TiddlyWiki community is consistently described as friendly, helpful, and welcoming.
Areas for Improvement:
* Learning Curve & Documentation: A recurring theme is that TiddlyWiki has a steep learning curve, and the official
documentation, while extensive, is often found to be confusing and not beginner-friendly.
* Mobile Experience & Syncing: Many users struggle with a smooth mobile experience, particularly regarding easy and
reliable saving and synchronization across devices.
* Saving Mechanism: The lack of a simple, out-of-the-box saving solution that works across all modern browsers is a
significant pain point for many.
* Onboarding and Aesthetics: Respondents suggested that the default user interface could be modernized and that the
project would benefit from better onboarding materials, templates, and marketing to attract less technical users.
Of course. Here is a more detailed statistical summary of the 2025 TiddlyWiki survey findings, based on the provided
data.
Respondent Profile
* Technical Proficiency: A significant majority of respondents, by a ratio of approximately 2:1, identify as
programmers or software developers. This suggests a user base that is, on average, highly technically literate.
* Experience Level: The user base is mature and diverse in its experience. A substantial cohort consists of long-term
veterans who adopted TiddlyWiki in its earliest years (2004-2010). However, there is also a healthy influx of newer
users, with many having started between 2020 and 2025, indicating sustained interest in the platform.
* Community Engagement: The majority of users are actively engaged with the TiddlyWiki community in some form. "Talk
TiddlyWiki" is the most frequently mentioned platform for active participation (reading and posting), while Reddit
and Discord serve as secondary hubs, often for lurking and reading.
Primary Use Cases & Technical Implementation
* Core Applications: The survey data reveals a clear hierarchy of use cases.
1. Knowledge Management: Overwhelmingly the top use case, with nearly every respondent using TiddlyWiki as a
personal or technical knowledge base.
2. Note-Taking & Task Management: These two applications are also extremely common, forming the second tier of
primary uses.
3. Journalling & Creative Work: A significant number of users employ TiddlyWiki for journalling, worldbuilding, and
narrative writing.
* Saving & Hosting Patterns:
* Single-File Dominance: The single-file wiki remains the most popular format. The most frequently cited saving
method is using a custom saver like Timimi or TiddlyPWA, closely followed by the default browser download saver.
* Desktop & Server Usage: TiddlyDesktop is a very popular choice for a dedicated application experience. For more
advanced users, running a multi-file wiki via Node.js is also a common configuration, often for larger wikis or
for serving them online.
* Synchronization: Consumer cloud storage (Google Drive, Dropbox) is the most common method for syncing files
between devices, with Git and Syncthing also being popular choices among more technical users.
* Customization Levels:
* Virtually all users have customized their TiddlyWiki with plugins and options.
* A vast majority are comfortable with core features like WikiText widgets and filter expressions.
* A smaller but still large subgroup takes customization further by writing their own HTML and CSS.
* The most advanced users, representing a significant minority, also write custom JavaScript to extend
functionality.
Key Sentiments & Feedback Analysis
* Most Valued Aspects (by frequency of mention):
1. Flexibility & Customizability: This was the most frequently praised characteristic. Users value the ability to
shape TiddlyWiki into a tool that precisely fits their workflow.
2. Privacy, Data Ownership & Local-First Operation: The second most common point of praise was the assurance of
data privacy and control, free from cloud services and subscriptions.
3. Community: The helpfulness, friendliness, and expertise of the community were consistently highlighted as a
major strength.
4. Stability & Backwards Compatibility: The project's longevity and commitment to not breaking existing wikis is a
key reason for user trust and continued use.
* Most Common Pain Points (by frequency of mention):
1. Documentation & Learning Curve: This was the most significant challenge cited. Many users find the official
documentation dense, hard to navigate for beginners, and lacking in practical, "cookbook-style" examples.
2. Saving & Synchronization: The lack of a simple, universally reliable saving mechanism across all browsers is a
major source of frustration. A seamless mobile sync solution is the most requested feature in this area.
3. Mobile Experience: The user experience on mobile devices is considered a significant weakness, particularly
around editing and saving.
4. Onboarding for Non-Technical Users: Many respondents feel that TiddlyWiki is intimidating for non-programmers
and would benefit from a more polished default UI, better templates, and clearer onboarding guides to attract a
wider audience.
Based on the survey responses, users employ a wide variety of backup and synchronization solutions, ranging from simple
manual methods to sophisticated automated setups. Here are the main categories of backup solutions mentioned:
1. Consumer Cloud Storage Services
This is one of the most common methods. Users store their single-file wikis in a folder that is automatically synced
by a cloud service.
* Examples: Google Drive, Dropbox, OneDrive, Proton Drive.
* How it works: The cloud service's desktop client monitors the local file for changes and automatically uploads the
new version to the cloud, providing version history and access across multiple devices.
2. Version Control Systems (Git)
A popular choice, especially among developers, is to treat the TiddlyWiki file or project folder as a code
repository.
* Examples: GitHub, GitLab, Gitea/Forgejo, or self-hosted Git instances.
* How it works: Users commit changes to their wiki, providing a detailed history of every modification. This method
offers robust versioning, branching, and the ability to roll back to any previous state. It is often paired with
automated scripts to handle commits.
3. Peer-to-Peer (P2P) Synchronization
This method syncs files directly between a user's own devices without relying on a central server.
* Primary Tool: Syncthing is mentioned frequently.
* How it works: Syncthing synchronizes a folder across multiple computers and mobile devices in real-time. This is
valued for its privacy and for keeping data within the user's control.
4. DIY (Do-It-Yourself) Scripts and Manual Methods
Many users have created their own custom backup solutions.
* Examples:
* Custom batch scripts or shell scripts that automatically copy the wiki file to a backup location, often adding a
timestamp to the filename.
* Using tools like rsync or robocopy to create nightly or periodic backups to a network drive or external hard
drive.
* Simple manual copying of the file to a USB stick or external drive.
5. Direct Saving/Hosting Services
Some services are designed to directly host and save TiddlyWiki files, which also serves as a form of backup.
* Examples: TiddlyHost, WebDAV servers.
* How it works: These services provide a direct endpoint where the TiddlyWiki file can be saved from the browser.
WebDAV, for instance, allows users to save directly to a personal NAS (Network Attached Storage) or a compatible web
server.
6. Desktop and Mobile Applications
Some dedicated applications that manage TiddlyWiki files have their own built-in backup mechanisms.
* Examples: TiddlyDesktop, Quine (iOS), Tiddloid (Android).
* How it works: These apps often manage the saving process and may create their own backups or integrate with the
device's native file system and cloud backup services (like iCloud or Google Drive backups).
Of course. As a documentation expert, I can provide a detailed set of recommendations for improving the TiddlyWiki user
documentation, based on the survey feedback and best practices for technical open-source software.
The survey data clearly indicates that while TiddlyWiki is powerful and beloved by its users, its documentation is a
significant barrier to entry and a source of frustration even for experienced users. The core problem is a classic
one: the documentation mixes tutorials, how-to guides, and technical references, making it difficult for any single
audience to find what they need.
Here is a proposed strategy to restructure and enhance the user documentation.
Overarching Strategy: Audience-Centric Restructuring
The single most impactful change would be to restructure the documentation around user goals and experience levels.
The current tiddlywiki.html file serves too many masters. I recommend splitting the documentation into at least three
distinct, but interlinked, sections:
1. The Tutorial: A linear, guided path for absolute beginners.
2. The How-To Guide / Cookbook: A collection of goal-oriented recipes for intermediate users who want to accomplish
specific tasks.
3. The Reference: A comprehensive, encyclopedic reference for advanced users who know what they're looking for.
This structure allows users to self-select the documentation style that best fits their immediate needs.
---
Actionable Recommendations for Improvement
Here are specific improvements for the user-facing documentation (Tutorials and How-To Guides).
1. Create a "Getting Started" Learning Pathway
This section should be designed to take a new user from zero to "aha!" in the shortest possible time. It should be a
curated, linear path that builds concepts progressively.
* Start with the "Why": The first page should briefly explain the TiddlyWiki philosophy (non-linear notes, owning your
data) and showcase 2-3 inspiring examples of what's possible.
* The First Five Minutes: The next section must be a simple, foolproof quick-start guide that covers:
* Downloading a new empty wiki.
* The single most critical step: How to save changes. This needs its own dedicated, highly visible page with
simple instructions for each major browser.
* Creating a tiddler, writing some text, and clicking "Done".
* Saving the file and reloading to see that the changes persisted.
* Build a Simple Project: Guide the user through building their first useful wiki. A simple to-do list or a personal
journal are excellent choices. This project should introduce core concepts one at a time:
* Tiddlers & Linking: Creating and linking tiddlers.
* Tagging: Introducing tags as a primary organization method.
* Simple Filtering: Using the tag operator in the list widget to create the first dynamic list (e.g.,
[tag[ToDo]]).
* Basic Customization: Show how to change the site title and subtitle.
2. Develop a "Cookbook" of Practical Recipes
This is for users who understand the basics but want to know, "How do I...?" Each "recipe" should be a
self-contained, step-by-step guide to building a specific piece of functionality. This directly addresses the
feedback that users know TiddlyWiki can do anything, but don't know how.
Suggested "Recipes":
* Task Management: How to build a GTD-style to-do list with states (e.g., "next," "waiting," "done").
* Personal Dashboard: How to create a custom start page that aggregates information from across the wiki.
* Digital Garden / Zettelkasten: A guide on creating a networked-thought wiki, explaining how to use backlinks and
create index tiddlers.
* Embedding Media: Simple, clear instructions for embedding images, videos, and PDFs.
* Customizing the UI: How to add a new tab to the sidebar or change the page layout.
3. Improve Discoverability and Navigation
* Create a Documentation Portal: The main tiddlywiki.com site should have a clear, visually appealing "Documentation"
section on its homepage that immediately directs users to the appropriate section (Tutorial, Cookbook, or
Reference).
* Aggressive Cross-Linking: The different documentation sections must be heavily interlinked.
* When a Cookbook recipe uses the <$list> widget, it should link directly to the Reference page for that widget.
* When a Tutorial introduces tagging, it should link to the conceptual page on Tagging in the reference section.
* "See Also" Sections: Every reference page should have a "See Also" section that links to practical recipes in the
Cookbook where that feature is used.
4. Incorporate Visuals and Interactive Examples
* Use More Screenshots and GIFs: For any UI-based instruction (e.g., "click the tag pill"), a screenshot or a short,
looping GIF is invaluable.
* Leverage TiddlyWiki's Interactivity: The documentation is a TiddlyWiki itself; it should use its own features to
teach. Instead of just showing code, embed live, working examples of widgets and filters directly within the
documentation tiddlers. This is a unique and powerful advantage that should be fully exploited.
5. Establish a Clear and Consistent Voice
* Write for a Beginner's Mindset: Assume the user knows nothing. Define terms clearly or link to a glossary. Avoid
jargon.
* Create a Documentation Style Guide: A simple guide for contributors that defines terminology (e.g., "tiddler" vs.
"Tiddler", "tag pill" vs. "tag link"), tone, and formatting will ensure consistency and quality as the documentation
grows.
Excellent question. As a web developer focused on local-first applications, improving TiddlyWiki's saving mechanism is
a fascinating and critical challenge. The core issue is the browser's security model, which is rightly designed to
prevent web pages from having arbitrary write access to the user's local filesystem. The classic "download a new copy"
method is a clever workaround but offers a poor user experience, leading to file clutter and confusion.
My approach would be a multi-layered strategy that prioritizes the most seamless, modern APIs first, while providing
robust and intelligent fallbacks. The goal is to make saving a local-file TiddlyWiki feel as effortless as saving a
document in a native desktop application.
Here are the solutions, ordered from most ideal to fallback.
Solution 1: The Gold Standard - File System Access API
This is the modern, definitive solution to the problem. The File System Access API
(https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API) (FSA API) is designed for exactly this use
case.
How it would work in TiddlyWiki:
1. Initial File Opening: When a user opens a file:///.../mywiki.html, TiddlyWiki's boot sequence would detect if the
FSA API is available in the browser.
2. Permission Prompt: If available, instead of just loading, the wiki would immediately use window.showOpenFilePicker()
to have the user "re-open" the file they just opened. This is a crucial step. It's a one-time action (per session, or
permanently if the browser supports it) where the user explicitly grants the web page permission to read and write
to that specific file.
3. Store the File Handle: Once permission is granted, the API returns a FileSystemFileHandle. This handle is the key.
It's a persistent reference to the file that TiddlyWiki's JavaScript can hold onto for the entire session.
4. Seamless Saving: When the user clicks the "save" button, instead of triggering a download, TiddlyWiki would:
* Generate the new wiki content in memory.
* Call fileHandle.createWritable() to get a writable stream to the file.
* Write the new content directly to the stream and close it.
The original file is overwritten in place. No new file is created. The user experience is identical to Ctrl+S in a
desktop app.
* Pros:
* Perfect UX: This is the ideal "save-in-place" experience. It's fast, intuitive, and eliminates file duplication.
* Secure: The user is in full control, granting explicit permission via the browser's native UI.
* Future-Proof: This is the W3C-standardized, officially supported way to solve this problem.
* Cons:
* Browser Support: It's only available in modern Chromium-based browsers (Chrome, Edge, Opera) and is still under
development for Firefox and Safari. This means it cannot be the only solution.
Solution 2: The Reliable Workhorse - Native Host Messaging via WebExtension
This is the approach used by the excellent Timimi extension. It's the most reliable cross-browser solution for true
"save-in-place" functionality where the FSA API is not supported.
How it would work in TiddlyWiki:
1. User Installation: The user installs a browser extension (like Timimi) and a small, companion native host
application.
2. Communication Bridge: The TiddlyWiki saver module detects the presence of the extension.
3. Saving: When the user saves, the saver module sends the full text of the new wiki file to the extension. The
extension then passes this data to the native host application via the Native Messaging API
(https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging).
4. File I/O: The native host, being a regular desktop application, is not constrained by the browser sandbox. It has
full permission to overwrite the original file on the disk.
* Pros:
* Excellent UX: Once set up, it's as seamless as the FSA API.
* Cross-Browser: Works on all major browsers that support WebExtensions (Chrome, Firefox, Edge).
* Proven: This model is stable and has been used successfully for years.
* Cons:
* High Barrier to Entry: Requires the user to install two separate pieces of software (extension + native host).
This is a significant hurdle for non-technical users.
Solution 3: The Paradigm Shift - Progressive Web App (PWA) with Service Workers
This solution fundamentally changes the model from "editing a file" to "using an app". It's a powerful alternative
for users who are comfortable moving away from the single HTML file paradigm for their primary interaction.
How it would work in TiddlyWiki:
1. Installation: A user visits a special "loader" TiddlyWiki page served over https- (e.g., from Tiddlyhost or a local
server). This page registers a Service Worker. The browser then prompts the user to "Install App".
2. Data Storage: The TiddlyWiki application logic and all user tiddlers are stored in the browser's internal,
persistent storage (IndexedDB). The concept of a single .html file is abstracted away from the user for day-to-day
use.
3. Instant Saving: Saving is instantaneous. When a tiddler is modified, it's simply a transaction in the IndexedDB
database. There is no file I/O.
4. Offline-First: The Service Worker allows the entire application to work perfectly offline. It runs instantly, just
like a native app.
5. Export as Backup: The "save" button's function changes. Instead of overwriting the app, it becomes an "Export" or
"Backup" button, which generates and downloads a complete, self-contained .html file, preserving TiddlyWiki's core
promise of data longevity.
* Pros:
* Best-in-class performance and UX: Instant startup, instant saving, offline-first reliability.
* Feels like a native app.
* Eliminates all saving friction.
* Cons:
* Paradigm Shift: It's not the "single editable file" model. This would be a new, optional way to use TiddlyWiki.
* Requires a Server: It cannot be initiated from a file:/// URI; it requires an http:// or https:// context, even
if it's just localhost.
---
Proposed Implementation Roadmap
A robust saving module should be a "dispatcher" that intelligently chooses the best available method.
1. Phase 1: Prioritize File System Access API:
* Implement the FSA API as the default, primary saver.
* On first load, detect if the API is available. If so, guide the user through the one-time permission prompt.
Make this a celebratory moment: "Your browser supports direct saving! Click here to enable it for a seamless
experience."
* The save button icon could even change (e.g., from a "download" icon to a "floppy disk" icon) to indicate that
direct saving is active.
2. Phase 2: Promote and Integrate with Native Host Savers:
* The saver module should actively detect if an extension like Timimi is installed.
* If FSA is not available but Timimi is, use it automatically.
* If no direct saver is available, the UI should briefly and unobtrusively suggest Timimi as a "recommended
upgrade for Firefox users" to get a better experience.
3. Phase 3: Enhance the Fallback Download Saver:
* The current download saver should remain as the ultimate fallback.
* Intelligent Enhancement: We can even improve this! When the user clicks save, we can try to use the FSA API's
showSaveFilePicker() method. This method always shows a "Save As" dialog, but it allows us to pre-populate the
filename and location from the original file. This would allow the user to easily select and overwrite their
existing file in a single step, which is a huge improvement over finding the downloaded copy and renaming it.
By implementing this tiered strategy, TiddlyWiki would offer the best possible saving experience that each user's
browser can support, gracefully degrading from a seamless, modern API to a more intelligent version of the classic
download fallback.
The above looks like a reliable road map to me. How do we turn these learnings into actions?
Hello, I can confirm the survey has now closed.
You can download the output for those who opted into data sharing from the top of the page on the EUSurvey publication link.
Jeremy is away for a bit so the survey edition is not up to date as of the time of writing.
If people who have responded would like to update their analyses and were not using the survey edition, this should be a good base for any more ideas and insight you retrieve. Thank you much for your the contributions you have already made.
I have updated my attempt at the wiki-setup-info generated by the info tiddler based on the final closed survey data:
Thank you - this is a powerful chart showing 3/4 of participants prefer fluid-fixed, which calls for changing the default setting!
This one too, showing the plugins at least 10% of participants have installed:
Not surprised highlight is so high with the vast number of programmers in the community.
There is a caveat to all this, of course: perhaps only a certain kind of user (probably more engaged) will have seen the survey in the first place, and had the motivation to complete it.
