Hi, I think, it is a matter of supporting software, its usability and documentation.
Tags are highly supported by the core and exposed to the "standard" user. Easy to use, displayed by the default layout. Allmost every listing core macro supports it. There are many plugins, that extend the core functionality. Most of them are well documented. Fields are highly supported by the core but are not exposed to the user. There is a hidden button in the toolbar to display them. Propper editing needs a plugin. Viewing is easy, but needs more advanced knowledge. Programmers like them to create "meta" or "hidden" information :) Slices are supported by the core in form of transclusions. eg: <<tiddler macro>>. Sections are supported by core in form of transclusions. eg: <<tiddler macro>> Slices and Sections are very well known. They are human readable. They are human editable, without any additional macro. But except of transclusions, they are allmost not used by programms to programmatically store human readable Information there. May be, because of human editing in the wrong way, will break the structure a programm needs to work propperly. May be, because the core doesn't expose easy to use "edit functions" like forms, radio buttons, drop down lists, to programmers and users. There are some well documented plugins, that expose easy to use "edit functions" like forms, radio buttons, drop down lists to the user. And it seems, many of them write to custom fields instead of sections and slices. And that's the reason why Michel says: >For instance, I have an application on a TW that could no be done >easily without tags or without fields! ...snip... >3. These items are easy to fill in (radio buttons, drop-down boxes, >text-boxes for notes, etc.. >4. Each of the input is associated with a field In my opinion it should be: 4. Each of the input is associated with a slice, or section content. But the easy to use Interface is missing. I also don't know any core functions that makes it easy to eg: <<list slice:sliceName ...>>, because a full text search is considered to be slow. ==== In my opinion "usefull user data" shouldn't be written to extended/ hidden fields. This data is to valueable. It should be in the tiddler content. Nicely formatted and exposed to the reader in a usefull way. I think all programmers should look for good usability in this area. Extended fields can hold "metadata" written by plugins, to get there job done. It shouldn't be mixed. Copy/paste a tiddler + tags from one TW to an other, should contain the whole information needed to work with the content. Loosing extended fields shouldn't make the content useless, or worse human readable. my 2 €ents mario On Nov 12, 5:29 pm, rakugo <jdlrob...@gmail.com> wrote: > I guess the benefit of using tags is they are a TiddlyWiki concept > thus lots of plugins exist around them. Work with fields and you may > find there is a plugin that does what you want but relies on tags. > > > However TW (unfortunately) uses tags for system things like > > "systemConfig". And users use tags to attach extra metadata. > > Out of interest why is that an unfortunate thing? Is it because they > show up in the UI? > If so you can hide them by creating a tiddler systemConfig tagged > excludeLists.... > > Jon -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to tiddlyw...@googlegroups.com. To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
