Optional multiple tag fields (@Jeremy)
124 views
Skip to first unread message
Mat
May 17, 2013, 8:05:29 AM5/17/13
to tiddl...@googlegroups.com
In a prevous thread, I proposed the idea with optional multiple tag fields for TW5 and Jeremy answered:
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 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.
<:-)
"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 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.
<:-)
Eric Weir
May 17, 2013, 10:15:12 AM5/17/13
to tiddl...@googlegroups.com
On May 17, 2013, at 8:05 AM, Mat wrote:
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.
....
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.
I may be off-base here---my immediate reaction when I started reading was to say what I'm going to say, but I kept thinking, "We'll maybe he'll eventually get to something that that would not be relevant to"---but tags are not magic. Tags don't organize things. Human beings organize things. And they have to organize tags, too. I'm suspecting---and I don't mean to give offense here, just guessing at what's going on---that you're not putting much thought into your tagging---into developing a tagging *system.*
To precisely that end I have found taggly tagging to be *extremely* helpful. As you may know, in taggly tagging, since all tags are tiddlers anyway, tags can be tagged, too. That allows you to put your tags into a hierarchical structure. Which I suspect would in time take care of the problem you're experiencing, which, for all the words you put into describing it, I take to be simply the problem of "many tags."
I have found the combination of tw and tt *extremely* helpful in organizing my thinking about what I can assure you are extremely complicated subjects. The really cool thing is that you do not have to have your structure set up in advance. It can evolve as your thinking evolves. So you just start with whatever categories seem most appropriate initially. As your understanding of the subject develops, the tags you started with are likely to come to seem inadequate. Of course you will need additional tags, but some early ones may need to be revised. And tags can be edited! Maybe some will need to be renamed. Or maybe several can be grouped together under a common tag. As you continue the tagging structure will get clearer and your use of tags more discriminating. But it can continue evolving indefinitely.
I use the tw treeview blackicity tw developed by Morris Gray. I think I added tt to it. With it I have four ways to locate a tiddler---by tags, in the tree structure---which is itself a graphical representation of the tagging structure---in the time line and/or alphabetical list in the right hand column, or by searching. And as in a standard tw, an open tag tiddler will display a list of all the tiddlers tagged with the tag. Lots of ways to find tiddlers. Lots of ways represent the structure of your tags. Lots of support for thinking about complex topics.
Again, I may have misunderstood your problem completely. I hope not and I hope this helps. [Maybe *it* will just confuse you more.]
------------------------------------------------------------------------------------------
"The problem with the world is that the intelligent people are
full of doubts while the stupid ones are full of confidence."
- Charles Bukowski
Mat
May 17, 2013, 3:10:42 PM5/17/13
to tiddl...@googlegroups.com
Eric, thanks for your thoughtful reply.
Tagglytagging and treeview - I love them both and do use them extensively. They are key 'features' in most of my TW's.
And I fully agree with your starting comment that "human beings organize things [not tags]" and that my proposal would (optionally) force thought into tagging. But while taggly and treeview do organize tags, they don't address the the issues that I bring up which is more about managing tags and, particularly, not being forced to learn code operations to do this.
My overall hope is that TW would be easier to user for laymen ("non-coders"). Not everyone is a layman, especially not here, which is why I suggest this as an optional feature.
BTW, do you have any thoughts on the "closely related issue" I describe? Ie that tags could be field arrays instead so that you don't have to deal with several concepts and learn specific operations for them?
Again, thanks for yout thoughts.
<:-)
Tagglytagging and treeview - I love them both and do use them extensively. They are key 'features' in most of my TW's.
And I fully agree with your starting comment that "human beings organize things [not tags]" and that my proposal would (optionally) force thought into tagging. But while taggly and treeview do organize tags, they don't address the the issues that I bring up which is more about managing tags and, particularly, not being forced to learn code operations to do this.
My overall hope is that TW would be easier to user for laymen ("non-coders"). Not everyone is a layman, especially not here, which is why I suggest this as an optional feature.
BTW, do you have any thoughts on the "closely related issue" I describe? Ie that tags could be field arrays instead so that you don't have to deal with several concepts and learn specific operations for them?
Again, thanks for yout thoughts.
<:-)
Eric Weir
May 17, 2013, 5:02:43 PM5/17/13
to tiddl...@googlegroups.com
On May 17, 2013, at 3:10 PM, Mat wrote:
Tagglytagging and treeview - I love them both and do use them extensively. They are key 'features' in most of my TW's.
Glad to hear you have found them useful, too, Mat.
And I fully agree with your starting comment that "human beings organize things [not tags]" and that my proposal would (optionally) force thought into tagging. But while taggly and treeview do organize tags, they don't address the the issues that I bring up which is more about managing tags and, particularly, not being forced to learn code operations to do this.
This is an area in which I think "taste" and "work habits" may enter, not inappropriately, into our judgments about what makes for efficiency in software. I personally find taggly tagging sufficient for managing tags, but then "managing tags" may mean something different to me than it does to you.
My overall hope is that TW would be easier to user for laymen ("non-coders"). Not everyone is a layman, especially not here, which is why I suggest this as an optional feature.
That was one part of your post that I didn't comment on---tw's unfriendliness to non-coding users. I am fortunate that I got a lot of help from the coders here and gradually developed a tw setup that suits most of my needs very efficiently. But I must have had tw for a couple years before I even began to get a faint clue about how I make meaningful use of it, and it was quite a while, and took a lot of then-patient hand-holding, for me to get to a place where it was actually useful.
TW is extremely versatile, and for that reason very powerful. But for that reason exploiting any of its seemingly innumerable capabilities can require more than a little skill. So some of the difficulty for non-coders is inherent. But it could be a lot easier than it is. In fact, there has been almost no effort to develop the kind of documentation that could help non-coding users get to a level modest competence with tw.
BTW, do you have any thoughts on the "closely related issue" I describe? Ie that tags could be field arrays instead so that you don't have to deal with several concepts and learn specific operations for them?
No I don't. My immediate reaction is that "field arrays" sounds kind of databasey, and I have never thought databases might be helpful in the way I described tw with tt being helpful to me. Rather than allowing structure to evolve organically with one's thinking about a subject, as I understand them databases pretty much require you to have the structure in place before you start using them.
------------------------------------------------------------------------------------------
Eric Weir
Decatur, GA
"You keep on learning and learning, and pretty soon
you learn something no one has learned before."
- Richard Feynman
Reply all
Reply to author
Forward
0 new messages