vision
vision copied to clipboard
hypothesis
Resolve tag referent
What do tags tag? The target/selection or the annotation body? If its the target, is it also possible to tag the body? And vice versa.
It's unclear, which means that now it's up to creators and consumers to decide for themselves. Ok or not ok?
Not okay.
I need to know because tags are bodies in the OA spec and we're going to change the data model shortly to be this way. I need to know which annotation has the body. If the tag is tagging tho body then there is a second order annotation whose body is the tag.
Right now the data model we are using is ambiguous, as is the interface. That's okay. But I'm making the data model unambiguous and so I need to know and we need an interface for this.
This is pretty critical.
What do tags tag? The target/selection or the annotation body?
Actually, there are three possibilities, not two:
- They tag the target/selection
- They tag the body (for example, "has curse words")
- They tag the annotation itself (for example, "irrelevant")
The second and the third options are not exactly the same, because the second one says something about the body itself, while the third one says something about the relation between the target and the body.
The distinction between the body and the annotation in our interface is another ambiguity. I would consider possibilities (2) and (3) the same for the time being.
If we are already in the process of cleaning up the data model (which will inevitable involve rethinking the UI, too), why would we settle with leaving a recognized ambiguity in the model, instead of clearing it up, too? Especially since it's very close to the other ambiguity, which we are changing.
IMO it would cause much less pain to do extensive (and potentially disrupting) changes in the date model (like this one) only once, compared to doing it twice.
I'm not convinced (and I've thought about it quite a bit), that there's any place for annotations in the interface at all. Rather there are targets and bodies and their relative placement in interface is influenced by the annotation which connects them. If that's so, then there is no way for a user to indicate that they wish to tag an annotation, or reply to an annotation, or anything like that. For search purposes, it may make sense to capture the annotation as "context", i.e. an alternate target. We may wish to do the same with replies (making them replies to the body, with context as the annotation).
What's not clear to me is why any of this needs to be disruptive in any sense. If you mean that I may have to run a migration or we might need to implement some backward or forward compatibility code, then yes, it's disruptive.
Generally, though, I don't want to hold up clarifying one ambiguity just because we can't (yet) clarify the other (especially if we may never).
Another interpretation of disruptive would be that it disrupts other development, but that's a flawed viewed of progress which privileges visible, user-facing improvements. Furthermore, this improvement might clarify some things which are user facing. As a user, I've got no idea what I'm tagging right now.
Another interpretation of disruptive would be that it disrupts other development,
My interpretation is that it disrupts development, because we have to re-do things already done. That does not necessarily mean that it's a bad thing; it just means that we have to calculate with this.
but that's a flawed viewed of progress which privileges visible, user-facing improvements.
It would only be a flawed view of progress if it contained the assumption that disruption in development must always be avoided at all costs. My view does not contain that assumption.
Furthermore, this improvement might clarify some things which are user facing. As a user, I've got no idea what I'm tagging right now.
Correct. I am not proposing not to clean up the ambiguity. I am proposing to recognize the disruption cleaning this up will bring, and try to avoid having to uproote our UI twice, if we can clean up our data model by doing this only once.
I am proposing to recognize the disruption cleaning this up will bring, and try to avoid having to uproote our UI twice, if we can clean up our data model by doing this only once.
I didn't say you were.
I'm only saying that calling it disruptive at all makes no sense to me because the only way in which development is every a disruption is if there are other things that we'd prefer to be doing but cannot. However, there's little I'd like more than to fix these sorts of issues because they're at the heart of what I don't like about our product right now: loose standards of conceptual integrity and confusing interfaces. To me, other things we might do are a disruption and this is the important stuff.
You don't have to agree with me on that. The central point is there are two issues. They are distinct. They are only superficially similar.
I worry far more about scope creep than I do about changing things twice. Our team is prone to creep.
I think the suggestion to do them at the same time is pernicious. I'm not ruling it out, but I'm striking it down as a requirement.
calling it disruptive at all makes no sense to me because the only way in which development is every a disruption is if there are other things that we'd prefer to be doing but cannot.
That's not what I have meant. Let's find a different expression then, instead of disruptive.
How would you describe a step which we really want to make, but which will mean that we will have to go back a few steps, and redesign and re-implement stuff which was already working once?
I am happy to use a different expression instead of disruptive; this is the meaning that I wanted to convey.
there's little I'd like more than to fix these sorts of issues because they're at the heart of what I don't like about our product right now: loose standards of conceptual integrity and confusing interfaces.
To me, other things we might do are a disruption and this is the important stuff.
You don't have to agree with me on that.
Actually, I do agree that cleaning up any problems around conceptual integrity is top priority. That's also one of my biggest woes. See my notes a bit later.
I don't know. It's not productive for us to comb over these words again and again. What I care most about is getting a culture that cherishes rewriting things as an opportunity to do something better rather than a pain. We should always try to design things as correctly as we can given constraints of time and understanding, but when we have to do it again it's not going back. It is going forward.
I'm not convinced (and I've thought about it quite a bit), that there's any place for annotations in the interface at all. Rather there are targets and bodies and their relative placement in interface is influenced by the annotation which connects them.
I have thought about this quite a bit, too. (Like, 5+ years.) I have recorded some of my conclusions in #41.
(They are out of scope of this issue, so I submitted a new one, but they are related, so I am linking them here.)