I have looked at framadate (as you might note from the screenshot in my post), and I have used a wide range of similar sites that allow web visitor input, sometimes without even registering for an account (such as doodle).
What I’m indicating is that the infrastructure behind a site like framadate is quite complex, even though it looks simple on the surface.
Framadate needs to host a potential torrent of input data coming in from human web visitors, and they need to find a way to guard against (or minimize noise from) spammers and bots. Most importantly, they need a dataflow process that allows visitors to add select kinds of information to their servers, while not allowing any one visitor to modify the info associated with other visitors (EDIT: granted there are loosey-goosy tools that do allow anyone to mess around in a public shared sandbox), and not allowing visitors to edit or interfere with the html that controls how the site works. (EDIT: This part is what no online tool ever does. There’s always a sandbox around what can be accessed.)
TiddlyWiki is not that kind of solution, and it would have to be a very different kind of project if it tried to work that way.
Of course, I can set up a TiddlyWiki so that my editing interface looks however I like. And if I serve my tiddlywiki online through TiddlyHost (or my own web domain, etc.) I can also let web visitors interact with TiddlyWiki’s powerful editing interface. This means, with TiddlyWIki, that web visitors can tinker with everything about the site (based on the file that their browser loads into memory), even making changes in ways that “break it” … But what they break is (thank goodness!) only its ability to continue functioning in their own browser session. When the web visitor reloads, it retains nothing at all of their previous additions or edits.
What I literally cannot set up, over the web, is an interface that lets them use the TiddlyWiki edit process to modify the actual single html file (that is housed on the server) that is my TiddlyWiki. They can at best save an edited copy of it to someplace (like their own desktop) for which they have write access.
I can modify my own online TiddlyWiki file, of course, but it’s via an authenticated control panel, and edit access is all-or-nothing. If I were to try sharing my tiddlyhost account password with someone else (or my web server ftp access, etc.), that person would have complete edit access, and multiple users would be at great risk of making conflicting edits.
So again — unless the users you’re interacting with are all on a local area network or other authenticated-access system running a node.js version of TiddlyWiki, TiddlyWiki is not the way to conduct polls or surveys — until and unless you’re developing a complex interaction between TiddlyWiki and some other web-based service that’s handling the incoming data.