jducoeur | Singleton tags?

Okay, here's a question for thought and discussion. I'm currently designing the Tag feature. Every Thing in Querki can have fields that are "tags", in the usual sense -- they contain whatever short text you would like. Tags will be hierarchical (because that is sometimes useful). And here's the interesting question: should tags *always* be multi-value?

One of the great failings of older databases is that they tend to be single-valued -- you can have only one Author for a Book, and such silliness. The real world is typically much messier, and that's reflected in the fact that most modern systems use Tags as sets of values: you can generally have any number of tags for a given item. Tags are remarkably powerful, and I expect them to be much-used in Querki.

So I'm clearly going to implement TagSet. Is there any reason to have a data type that is only a *single* Tag? The engineer in me says that of course such a thing should exist, since conceptually it's obvious, but the UX designer in me says not to, since you shouldn't expose a concept that is always a bad idea to use.

Opinions? Are there non-strawman cases where you would specifically want to only allow a single Tag on something? Or is it more bother than it's worth to expose this through the UI -- should I just have TagSet as the type that you always use?

Flat | Top-Level Comments Only

Could this be tunable? Could the owner/moderator of a particular area set a limit on "number of tags per Thing" (sometimes tagging gets WAY out of control, too!) with possible values of Zero to Foo?

That's possible, yes -- wouldn't be terribly hard for me to allow a meta-property that lets you say how many Tags are permitted in a given Property.

But as always, that needs to fight for its life: it's an extra complication in the UI, which I'm only going to add if it actually appears to be useful in the real world. I'm trying to be very acid about this: Querki is aimed at the general public, so my design example is Apple rather than Microsoft. Every feature has to be clearly valuable to end users before I spend pixels on it.

So the question is, how often does this happen, and how severe a problem is it when it does? I confess, I don't remember seeing it happen myself, so I suspect it's unusual.

That said, I'll add it as a possible approach. Thanks -- that viewpoint hadn't occurred to me...

I'll admit, I am not wed to the concept myself. It just popped into my head as a possibly useful compromise.

It is, and sorry if I came across as negative. Not sure whether it'll be worth adding or not, but it has the nice advantage that, since it is a tweak of TagSet, it could be added later, instead of being something I have to include upfront...

No, not overly negative. :) While not on your scale, I have written code before. I have also had to document products, trying to write the user's manual even as the product was being built, and being redesigned as it was being built. I understand and applaud the desire to avoid Feeping Creatures.

I'm not sure I am fully understanding the issues, but it seems to me that you have answered your own question.

I'm reminded of a comment made by one of my co-workers at SUN, defining when one implementation is more powerful than another. "If you can implement B using A, but cannot implement A using B, A is more powerful". I'd opt for the more powerful, TagSet, in all areas.

Talvin's question is a good one, though. Do you want to be able to create TagSets whose sizes are pre-limited for any reason? I see no reason not to do so - except that it introduces a set of error conditions around both the limit value and what happens when you hit a limit.

That is an increase in complexity of code and time of implementation. I lack the knowledge to advise you on that, as I am not as versed in the usage model as you are.

(I'm inclined to say "no" - as long as your TagSet contains an ordinal count of tags, you can always implement a subclass of TagSet called LimitedTagSet. Or, from what you have been saying about Scala, you can create something that has an ordinal-cap sort of property, and associate that with all your collections or sets, should you choose to do so. I did buy, but still haven't cracked, Scala for the Impatient. The irony is not lost on me. I've been reading on law instead.)

That is an increase in complexity of code and time of implementation. I lack the knowledge to advise you on that, as I am not as versed in the usage model as you are.

Actually, neither of those is a major concern. The real issue is, literally, screen space. Or perhaps more accurately, mental space.

The thing is, I'm trying hard to avoid the classic "Microsoft disease" -- including every possible feature, with the result that *finding* the features you actually want becomes more difficult. So features have to fight for their lives, less because they are hard to implement and more because they increase the amount that a user might have to understand in setting up a Space.

And yes, the implication is that Querki is trying to be lowest-common-denominator in many ways -- again, in a very Appleish sort of way. There are going to be a hell of a lot of features in this tool, so I want to make sure they are the *necessary* features, so as not to overwhelm users. (This is part of why I'm so focused on use cases: no feature gets into the system unless it's justified by a use case, and no use case gets implemented unless I believe I have specific people who will want to use it.)

Note that the Scala end of things is largely irrelevant. This is, indeed, near-trivial to implement in Scala. But end users aren't working in Scala, they working in what amounts to a database/language/UI implemented *in* Scala. While that will use a lot of Scala structures under the hood, I'm not assuming that the end-user view has much of anything to do with that -- we're going to focus on what the users need, and figure out how to map that to the underlying language and database.

A limit on number of tags makes sense. A special category for exactly one tag doesn't clearly fit into that sense.

If it's the by-far-most-common case, it deserves some optimizations in the user interface (but not in the underlying implementation unless there's a technical win involved).

Ah.

So the question is whether a user would want to limit the number of tags on something, and have Querki enforce that limit.

I'd say no, because retrofitting that is easy: objects from before the retrofit continue to have unlimited TagSets, objects afterward have a range.

Dan's point about proliferation of "near tags" is important as well, and the Merge feature he suggests would be useful, if likely secondary to your initial implementation.

What may be useful, to address his concerns, is to find a useful UI that urges the user to use existing tags over having them create a near-duplicate without care.

We are now far afield from your question. :-)

Definitely, but there's been some useful food for thought here. I think the tag-limit suggestion is clearly the right approach to my question, and lets me see whether it's a real problem before I worry about it.

As I just replied to Dan, I very much agree about the UI for reusing existing tags. Not sure exactly what that's going to look like yet, but I may get fairly heavy-handed about it. Tagslop is such a common problem that I suspect it's worth very strong encouragement to avoid it.

And yes, I agree about Merge, although I think it needs to be viewed more holistically -- I suspect we're eventually going to want a Tag Management UI that lets you see the full tag hierarchy in your space and shove things around quickly and easily. Possibly even drag-and-drop, but I'll need to see some realistic examples before I start designing. Regardless, it's probably a year or two off.

Singleton tags?

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject