Folks, Jeremy and Jed specifically. When I mentioned Progressive WebAps, I think you took me too literally, perhaps that comes with the territory from coders.. My point is there is an expectation building and tiddlywiki is already well setup to respond to these expectations. Here are the key functionalities and I would find it hard to imagine you think any of these are not worthy aims.
I must say I am nervous speaking my mind here, but please consider what I am saying with the generosity in which it is offered. I may just have something worth listening to. When I mentioned PWA's it is with a view to capabilities for example; - *Progressive* — Works for every user, regardless of browser choice, - *Responsive* — Fits any form factor: desktop, mobile, tablet, or forms yet to emerge. - *Connectivity independent* — Service workers *are one way but we do not need them do we?* allow offline uses, or on low quality networks. *But there are uses out there for which we have methods such as using servers, and tiddlywiki naturally uses the browser cache, and offline works.* - *App-like* — Feels like an app to the user with app-style interactions and navigation. - *Fresh* — Always up-to-date *(this is a designers choice) and less important when we do not use a server backend, or a **continuous** deployment **method**.* - *Safe* — Served via HTTPS <https://en.wikipedia.org/wiki/HTTPS> to prevent snooping and ensure content hasn't been tampered with. - *Discoverable* — Identifiable as an “application” by manifest.json[13] <https://en.wikipedia.org/wiki/Progressive_web_applications#cite_note-w3cmanifest-13> and *service worker registration (if it **necessary**?)*, and discoverable by search engines *(good idea if it means can be appified, optional extra)* - *Re-engageable* — Ability to use push notifications <https://en.wikipedia.org/wiki/Push_technology> to maintain engagement with the user. *Nice optional extra can be implemented via **various* * means * - *Installable* — Provides homescreen icons without the use of an App Store. *Important in today's world.* - *Linkable* — Can easily be shared via a URL, and does not require complex installation. *Almost there except for savers, would if we adopted the approach.* On the subject of Local Storage, I do not care what the technology is called, we need to allow people to obtain this with the minimum effort. The current best method for me is Using Timimi and saving files, but since there is an increasing dependency on locally stored content, I am sure the solutions either are, or will be there for persistence even if there is a interactive step that demands authority to do so. Even just an easy install node package effectively grants this persistence, not to mention tiddlyserver, desktop and Bob, and we can move between folder and file versions. Personally, it’s pretty clear that PWAs are not a universal panacea for > TiddlyWiki. Everything about them is designed to work as a cache for an > online service, with some limited and crazy support for going offline. So > they could have a role with an online TW5 service like Xememex, but don’t > help the single file configuration. As I have to say regularly, there’s no > way on earth I would commit anything important to browser local storage, > nor could I in all good conscience recommend it to anyone else. > I not sure anyone, especially me suggested it was *a universal panacea for TiddlyWiki* but we do depend on the computers local storage. You may have good reason not to trust this mechanism but surely if we find an effective solution all the better. Imagine for example, just to propose and exception, we packaged a Pouch DB server for every OS and the ability to point any wiki to a named database, whilst also able to export to a single file. This would provide a reliable and persistent "local storage", one that could be connected to from any wiki at any url if desired. > I don’t think the heart of it is even a technology problem. It’s a much > deeper philosophical question. In the deepest possible sense, TiddlyWiki is > the way that it is because of the context in which it was built and used. > It is designed from the ground up as an open source application trying to > accommodate the needs of hundreds of thousands of diverse users. Almost > every decision I’ve ever taken about TiddlyWiki’s development would have > been completely different had I been working on a commercial shrink wrapped > product. > On this I agree, I am not contesting this, and that is what we should stick to. > What I’m trying to say is that the technology and the business model of > TiddlyWiki are intimately intertwined. Change the business model too much > and suddenly many of those technology choices become liabilities. > I agree and do not suggest anything differently, You continue to maintain this and make the technology choices. What I am talking about is the capabilities, addition not subtraction. > For example, TiddlyWiki allows deep customisation by end users, down to > adding new JavaScript modules. The only way to get that level of > customisation on a commercial service would be to buy a low level service > like a virtual machine, and run something like TiddlyWiki within it. For a > business model like, say, Evernote’s it is completely impractical to offer > that level of customisation while taking care of security and keeping > support costs reasonable. > Keep, keep, keep, Allow easy distribution of TiddlyWiki solutions, no business model changes proposed. > I can and do imagine building a shrink wrapped, mass-market product that > did what TiddlyWiki does, but I’m pretty confident that it’s not possible > to turn TiddlyWiki 5 into that product in any direct way. > I can see a solution being popular, just as amongst many Tiddlywiki itself is, But consider TiddlyShow, Cardio etc... if there was reduced barriers to discovery and adoption they could find themselves in a mass-market. > So, that’s why I’m so keen to focus on the opportunities presented by the > architecture we have now, and the investments we’ve made in it to date. In > particular, TiddlyWiki 5 has shown how people who are not conventional > software developers can create intricate custom applications that meet the > needs of arbitrarily specific niches. Of course. But you do realise it is hard to address a niche within another niche, At present if I have a niche solution, I must persuade people into the tiddlywiki niche environment first, If I could provide a niche solution to someone that they could acquire simply, they would use the niche solution (based on tiddlywiki) to meet their needs, then develop their understanding and need for TiddlyWIki. I respect the whole communities contributions, and Jeremy, Jed and Mario in particular their technical know how deliver so much, you and others are the "holders of the flame", and I want this to continue, but I must ask you think a little more progressively (pun Intended). It is those close to you, who need the most latitude in speaking to your power and expertise on Tiddlywiki, because those with some distance, simply choose another solution and we never hear from them. I have developed a simple yet effective Evaluation or decision making tool on top of TiddlyWiki why should it not become popular in an app store? Yours Sincerely Tony -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2c83e7db-48db-43ed-a603-f86d657f4645%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
