The uniqueness of "xememex" is nice for making sure I find the sample code for just the new project. That is the only real concern I would have about renaming: Making sure search engine results can be refined easily.
Although I personally agree that the project title word is just a random string of letters that I can copy-paste as a prefix for my search query, I personally dislike the repetition of letters in xememex. Although xemex.com com is already taken by a watch company, perhaps we could take advantage of some other TDL like xemex.dev on which browsers now require HTTPS communication. I agree wirh Stobot that 'Wiki' isn't a buzzword today and doesn't sound that professional. Knowledgebase abbreviated as KB is ubiquitous. Perhaps a rebrand focus could be Xememex Quine KB. This sums up where to go, why it is unique, and why you would want to use it. (Thanks to Matt for the suggestion.) Saying 'cards' is in the project name would be focusing on the implementation details instead of the user's overall problem. Cards can solve the problem, but that is just a necessay evil. An easy to update and re-link KB is their end goal. Perhaps some project concept abbreviations could be XM code in a QKB file? I do like the unit identity of "card" because it is unlikely to actually be in the content of anyone's actual documents or code. It is easy to find all such references, and isn't a sub-part of other common English words. It is very short to type, which is probably my biggest gripe about the 'currentTiddler' variable. It is used so often, I would really appreciate 'curCard' for the next iteration. I have been going through the documentation to learn how to create a working example of each individual option in TW. Just scratching the surface I keep running into 'depreciated' examples. A new fork for Xememex is definitely what I would desire. TWC is still being used today on old and current browsers. TW5 will continue to be used 15 years from now. Applying all the lessons learned to a separate project should make a clean break and require the minimum of today's latest browsers' functionality. Older browsers - if they must be used - will still work with the other projects. A focus on support for internationalization right out of the gate would also help. Just recently, Jeremy said trying to support field names with non-ASCII Unicode characters would be very complex under-the-hood. Making a clean re-design will help others to write cards and metadata in their own language much easier. The hardest part of rebranding - as Mozilla well knows - is keeping the current project being able to support the latest fads instead of truly halting development for two years. I don't have any suggestions other than deciding the new project will only focus on implementing the existing TW5.1.23 features, and any new features will have to be brought in during a second round of updates after the base project is released. I only have two pleadings for improvements: 1) Please include some kind of string literal escape codes so we can use [ ], " ', etc. characters within filters without worrying about whether the query can succeeed. It would be like the !--html comment-- tag where all data inside is treated as non-code. Most people won't use these operation characters in card, tag or field names. Power users should have some method that consistently allows for them. 2) Please try to make at least one practical example of every single keyword. I am constantly trying to figure out how to use keywords mentioned on TW.com but don't actually have any concrete implementation to see why it would be useful. Counter examples would also be nice. On Monday, December 28, 2020 at 7:51:01 AM UTC-8 Stobot wrote: > I know Jeremy's trying to not make this all name related - but not being a > developer, don't think I can contribute to that part of the conversation. I > agree that it would seem logical to use a new name with a new significant > version, though I also agree that development has been so healthy lately > that I worry about that momentum starting because of a looming re-design on > the core. > > With that, on naming... :) > > - I agree and have experienced that the "Tiddly" / "Tiddler" naming is > a barrier for me to sell others on the software - doesn't seem serious > - I agree that "Wiki" in general undervalues what TiddlyWiki is these > days. I agree with others who consider TW more of a "platform". For > example > I use it as a competitor to Microsoft PowerApps. > - I really like "card" - that's what I use when explaining TiddlyWiki > already and is totally self-explanatory given how it appears on screen. > Plays well with the various metaphors of virtual card boxes. > - I like "memex" after reading a bit about it. I agree that one > concern is that it's not obvious how to pronounce it... > - Related - Even if I knew how to pronounce it, I could tell them > the name and they may not know the spelling even close enough to even > find > with google - which could be problematic > - Maybe something else memex related but something that's more > intuitive to spell / pronounce? MemexCards, MemexDeck, MyMemex, > MemexPlatform, MemexPro, TheMemex > > > > On Monday, December 28, 2020 at 9:58:40 AM UTC-5 Mark S. wrote: > >> On Monday, December 28, 2020 at 4:02:18 AM UTC-8 wrote: >> >>> >>> As you mention in a later reply, the real challenge is replacing the >>> word tiddler. I remember trying this in Classic and it wasn't easy then and >>> is probably even harder now with all the widget attributes etc. Which makes >>> me wonder if this would really be the best use of our time and resources? >>> >>> >> xemes >> > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/6a7096d9-b273-4c6e-a2f2-1a3e5d0c152en%40googlegroups.com.
