Book > Hardcover > p. 158 “The Revengeful Restaurateur”
I understand the 2 examples and how “bad review” → “reservations.cancel()” does not violate the integrity of the reservation concept. But surely it violates the integrity of the review concept? There is no reasonable purpose for reviews that would include an effect on reservations. Even if there were to be punishment for, say, repeated negative reviews, it would, for concept integrity’s sake, have to be by suspending the user’s review privilege, for example. @dnj what do you say?
@TalkAboutQuality: I share your concern about this one. I suspect that it is a defect for a cancellation not to be confirmed to the reservation-holder. The coupling of reviews and acceptance of a customer seems too brittle. I also think that the coupling of reviews to the reviewer actually having been a customer (as is handled by the “Open Table” app, so long as that is how the reservation was made) is relevant as hinted here. These seem to be about “having a reservation” conceptually as opposed to how a reservation is reflected in the model of reservations that matter for the restaurant and also the restaurant’s commitment to service. (Then we get to consider how intermediaries fit.)
(Just to clarify, I’m not saying that this design is good or desirable! I’m just saying that it doesn’t technically violate concept integrity.)
I too would like to find some way to codify this intuition that you have as a design principle. The problem is that concept integrity has to be defined independently of any other concepts! I can’t say that a key property of the Review concept is that it doesn’t cause cancellations in the Reservation concept, because one concept shouldn’t be designed in the context of another. I can’t say that actions of Review shouldn’t affect any other concepts, because that would rule out all kinds of useful things (for example, syncing with the Karma concept so you get credit for writing reviews).
Another possibility here is to say that the integrity of Reservation is violated because the cancel action should not happen spontaneously, but should only be executed by the user. (Dennis @orcmid is hinting at this in his reply.) That seems more plausible, but it would prevent a sync that cancels a reservation when a restaurant has to unexpectedly close, for example.
This example is intriguingly related to another one I’ve been thinking about with my students recently. In Facebook, when Alice tags Bob in a photo, the photo (by default) becomes visible to all of Bob’s friends. That seems undesirable to me, because it seems to violate the integrity of the Friend concept, which says that only your friends should see your posts. One of my students responded that Facebook is simply executing a Friend.post action on Bob’s behalf, implicitly posting the photo on the assumption that if he’s tagged in it, he’d want to share it. If I grant that, my objection will now have to be that Bob didn’t in fact condone that post action, and may well not want it to be done. A more egregious example of this synchronization happened in Facebook Beacon, in which when you bought an item online, Facebook automatically posted on your behalf to tell all your friends what you’d bought. Andrew Hinton discusses this in his lovely book Understanding Context, whose relationship to context design I discuss in another post.
@dnj I was thinking more about cancellations without notifications, which is something that was experienced. I think a notification is needed, and a way for the original party to confirm receipt or maybe even question it. This is not unlike cancellation of email-list memberships.
This particular thread has me nervous about the independence/orthogonality of (ur-)concepts and however compositions are dealt with (or rejected). I will have to do my homework here before I dare say more.
PS: The assumption of transitivity with regard to tagging someone in a Facebook photo also strikes me as objectionable. There is an architectural principle at stake here, I think. An implementor’s generalization about intent is almost always wrong. The same goes for error messages assuming a cause not in evidence. Compare “The signed document has been altered” with a flat-footed “the digital signature is not verifiable.”
@orcmid I agree that a notification (and preferably a confirmation) would be desirable when you cancel a restaurant reservation. I think this is an example of why just having good concepts cannot guarantee a good design: you have to combine them well too (hence all those examples in the book of over- and under-synchronizations).
Confirmation is interesting for another reason: it would be nice to express it as a concept in its own right, but I’m not sure how to do that.
Re Facebook: I don’t think the implementor is really generalizing intent. That’s my charitable reading: what they’re doing (as in much of Facebook’s design) is surely just trying to expand engagement and connection…
About Facebook’s behavior here, of course, in general, everything they do is designed to increase engagement. Or put more bluntly, to keep people glued to their screens for longer. But being more specific about this case, they are asserting that the decision for my identity, in photos posted by others, to remain known only to people who know me by sight, is not mine alone. In fact, the rules of Facebook’s game are that any user can add this metadata about any other user. Facebook does at least ask me, in this case, whether I would like such a post (photo with me tagged in it) should appear on my feed. (I almost always say no, but that’s just me.) More interesting is what Facebook’s privacy policy says about privacy of metadata about me that has been added by someone else. Finally, while I wouldn’t want this forum to digress into discussions of particular social network platforms, it does demonstrate that, in the appropriate forum, concepts are a useful vocabulary for discussing such issues
@TalkAboutQuality: One way to put your insight is that there is a Metadata concept, in which users can add various metadata fields to items in a public space, but that metadata that points to someone’s identity deserves to be treated as a separate concept. So Facebook’s Tag concept is fundamentally different from a vanilla Metadata concept, and indeed users might reasonably expect to have control over how other users attach their identity. The Mention concept (as in Slack) is similar in this respect. Another kind of metadata that might need to be in its own concept is geolocation data. The social media platforms strip geolocation off uploaded photos, but often reserve it for their own use. And there are problematic examples of people’s geolocation in posts being used to find where they live, or to determine that they are away on vacation (so their homes can be broken into).