Singleton tags?

[jducoeur]

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?

Comments

[jducoeur]

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.

[be-well-lowell.livejournal.com]

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).

[goldsquare.livejournal.com]

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. :-)

[jducoeur]

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.