In a prevous thread<https://groups.google.com/forum/?fromgroups#!topic/tiddlywiki/MaPEEqtavoE>, I proposed the idea with optional multiple tag fields for TW5 and Jeremy answered:
"Interesting. It sounds as though you are envisaging multiple fields on a > tiddler each with the behaviour of the existing 'tags' field, and the > ability to specify which tags field is used for a given operation. I think > that's possible but I'd be keen to make sure that I understand your > intended use cases better: can you give me a few examples of operations > that would be easier to accomplish with this feature?" > Ok, this has been an effort to write and I fear it'll be an effort to read but perhaps amusing. My problem is that I'm not a programmer so I'm probably using wrong terminology and have quite possibly misunderstood a thing or two about how TW is built up. However, I bring the perspective of an experienced TW user who has enjoyed but struggled with TW for a few years now. Maybe I (and surely many others here) can be seen as a link between you TW wizards and average Joes who justs want a good <insert purpose of TW> but who gets scared off when he realizes that TW without coding barely is possible and that he really is dependent on the generosity of the board members explaining stuff all the time. So, the central theme of my post here is about simplifying things for average Joe, one concept being the suggestion for optional multiple tag fields / tag categories. So, operation where optional multiple tag fields would simplify. For sake of explanation we have a TW on Tolkien stuff. Tiddler "Frodo" can have tags like the following: "ring bearer", "hobbit", "protagonist", "Elijah Woods", "The Fellowship of the Ring", "The Two Towers", "@Jeremy", and N more tags - i.e any association the author (or a group of people!) considers relevant. Thus, tags are plenty, sprawly and arbitrary - though all quite relevant and realistic. Example operation: Transclude the book titles. They are indeed among the tags but to get that info out you need to seek up which of the tags that in turn are tagged, say, "book". Perhaps not difficult for a coder like yourself but I think few non-coders would know what to do. Multiple tag categories would in this example omit the need to search all together (assuming tiddler "Frodo" has tagcategory "books"). The search was replaced by (optional) manual work at the time of adding the tags (or later). Note also that there need be no actual book tiddlers for this in contrast to current solution that requires book tiddlers tagged 'book'. More complex and general problem (still quite realistic): "List all characters of books (ie characters tagged with book names). Each bookname is tagged 'book'." You pretty much have to be a programmer to solve this. A merely experienced user might use fET, but if the number of books are arbitrary (i.e can't be hard coded) this case is actually not possible to solve with fET without adding special code. With tag category "book" in each character tiddler, a transclusion would be simple. While you asked specifically for "operations that simplify" and the above are only one or two examples, the following are mostly not operations but I belive they do illustrate situations where (optional) multiple tag fields are beneficial for non-coders: Using many(!) tags is problematic in current TW and problems increase with the number of tags. But if TW is to "fit around your brain" then just like some subjects in your brain has many associations, so do some tiddlers require many tags. It is a limitation to feel that "I'd better not". One specific problem is (was?) slowness as a consequence of many tags, especially for various searches that have to scan all tiddlers and all tags. Categories of tags could maybe smoothen this. Further, regular databases often have many, many attributes and values. Not incidentally, the user friendly way to add an item in a database is typically a form(!). A tiddler with (optional) tag categories would not be all unlike a form with attributes and values. I'm not sure pure programmers are fond of forms but it is not a coincidence that many user friendly databases has this view for adding and presenting information. It's even more problematic with plenty *and *sprawly tags. Eg Tobias TagSearch plugin <http://tobibeer.tiddlyspace.com/#TagSearch> shows such a 'sprawl' and how categorization solves it. Prio tags here and task tags over there. Not to mention public tags for visitors here and private tags there... ...and optional tag category fields would 'operationally' open up for commands in eg viewtemplate to "don't display tag field named 'unofficial'. Currently you must tag each individual unofficial tag with excludeLists (wich also forces you to turn mere tags into tiddlers). But excludeLists is a specific example. Operations can be of "any" type on category fields. Apropo that "tagging tags" forces you to turn them into tiddlers; when I look at the tag lists (tag tab) for some of my more complex TW's, I notice that some tags are only there so to find tiddlers in filters (fET's etc) where others are for actual manual searches. This is a consequence of the (brilliant) concept that tags can be [links to] tiddlers but it's also an indication that tags are indeed of different kinds - some are tiddlers and some are pure tags. That may not justify multiple tag fields per se but as a user I'd like to be able to manage tags more effectively. Sometimes not, therefore the suggestion for 'optional'. Multiple tag fields would simply be a more intuitive way to deal with sets of tags. (Note: I guess, the tag category names could also be tiddlers just like tags can also be tiddlers. Haven't thougt this through.) A closely related issue: If the above seems vague on if I'm talking about tags or fields, you're right. This is not coincidental. I like the aim Jeremy/Mario mentioned earlier that "users shoulr only havie to learn one new term, tiddler". In this spirit I think there are currently too many "value types" - there's tags, fields, slices, sections and maybe more. They do serve somewhat differnt purposes but only somewhat (at least from a user prespective). And they typically require different syntax for operations. And it takes dedication from a newbie to 'get' them. I think there could be a conceptual simplification made here illustrated by the following "analogy": The tag area+tags could be to the fields+values what user created tiddlers are to system/shadow tiddlers. At least the experience of it. ...ie. it would be conceptually easier if there are only "fields" or "tags" and then have some of them public and some as hidden/shadow/system. The tag area was a field (with an array of tags maybe?) and the other fields were shadow/system. With tag categories, (or field categories if you prefer that term), you'd eliminate the need to use slices and sections unless you explicitly want a slice tables or section headings in the content). This way, for any type of meta information there could(?) be one syntax as it all goes into fields. Iw tags are really the same as field values maybe they could be stored as arrays. Field names and the name of the tag box or multiple tag boxes are the same, ie it is the name of the array. Operation to fetchi/transclude a hidden field value is the same as fetching a tag. Again, I'm no programmer so maybe arrays is not the way to go. Ok, better halt this before I'm on trial for blasphemy. <:-) -- 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 post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at http://groups.google.com/group/tiddlywiki?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
