TiddlyWiki is almost 20 years old!

Nineteen already? Time does fly! :partying_face:
Congrats to all the community and a very special thanks to Jeremy and all the contributors for keeping one of my personal favorite open source projects alive. It is quite unique and peculiar, and the emphasis on privacy is a rarity these days, when everything is a cloud service and user is data mined to no end.

Had forgotten all about Wiki On A Stick, but is what first introduced me to TiddlyWiki as well. Good times, thanks for the reminisce.


Those are all great ideas for a celebration, but I’m particularly interested in these

This gave me a few wild ideas.

Jeremy has in the past mentioned considering renaming TiddlyWiki to something else because of certain concerns with the name holding us back. Some brainstorming occurred in other threads

There have been a few past attempts at branding TiddlyWiki and coming up with a logo in the old Google Groups Forum. I made a few attempts myself some time ago as well.

With this in mind, this seems like the perfect timing for a full revamp. This could be a great opportunity to start fresh, and do the complete rebranding. I apologize in advance for the overly ambitious proposal, but bear with me. From the most modest to the most radical:

  1. New stylish palettes - Maybe keep it down two a handful to be manageable (quality over quantity), one or two light colored palettes, one or two “dark modes”, and one or two for the visually impaired.

  2. A new modern theme. Nico Notebook is a good example I’m currently using myself, perhaps a great starting point. Responsive design, modern look, good mobile browser support, touch interface ready, reorganized settings new clearer structure.

  3. Rename TiddlyWiki to whatever is deemed suitable

  4. Make a logo and creating branding for the fresh updated name from the get-go.

  5. Launch a new “6.0 version” to celebrate the occasion, that is a successor of the current 5 series

  6. Correct me if I’m wrong, but TiddlyWiki prides itself on mostly keeping backwards compatibility. From my limited understanding I imagine this probably lead to gaining some “baggage” in terms of code, that may be holding it back it terms of size, simplicity, performance and freedom. Take the opportunity to “clean house” and deprecate old methods with the new fresh version, without fear of breaking backwards compatibility.

I understand this may well upset some users, and may not align with the global vision for the project. Radical, changes like that are bound to break some workflows, but the opportunity does seem timely. I certainly don’t expect all of this to even be feasible, but just wanted to put it out there, maybe some of these points are worth pursuing.

I’d love to help with what I can.