View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003008 | HTML & PERL | Feature Request - Interface | public | 2017-10-01 06:06 | 2017-10-08 22:43 |
| Reporter | Hinoe | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0003008: Relations: treat weak relations to graph endpoints as strong | ||||
| Description | The reasoning here isn't trivial and I want to make sure my point is well understood, so bear with me while I explain it in detail. Assume that a show has only one relation to a larger graph, making it a graph endpoint. When that connection happens through a weak relation, the entire rest of the franchise gets hidden behind that single relation. That behavior is kind of jarring from a usability perspective, as it is counterintuitive, it confuses the user, it creates more actions in that it forces us to pointlessly check beyond that relation for more, and, while it's also true that there is a good reason for that behavior, tbh it looks overall a bit stupid, especially if you don't know why it happens. Clearly, there is room for improvement. I believe that the behavior for such endpoints would be greatly improved if, in those cases, and in those cases __ONLY__, the relation was considered strong, rather than weak. From the endpoint's perspective, the graph would appear the exact same way it already appears for its only related anime; from the perspective of the entire rest of the graph, nothing changes, because there is nothing beyond the endpoint to begin with. If a show has two or more weak relations, or one weak relation and one or more strong relations, nothing should change, all its weak relations should still be treated as weak, unless overridden by an endpoint behavior coming from the other side of the relation. See examples in the steps to reproduce for easier understanding. Final note: when I say "graph" in this ticket, the word is used in the sense of "a bunch of interconnected nodes", rather than in the sense of show=rel; put another way, relations shown on the anime page, the add relation page (show=addseq) and the anime relation table are also covered. | ||||
| Steps To Reproduce | In the examples below, - denotes a weak relation, = denotes a strong relation, letters denote individual anime, and numbers denote larger graphs: A-B=C=D-E Currently, A and E see only their neighbors, while B, C, and D all see all five anime. With this change, I intend for all five to see the whole graph. A-B-C=D A currently sees only B; with the change, it should also see C, just like B. B sees A and C, C sees B and D, and D sees C and B; none of that would change. 1=A-B-C=2 1 and A see each other and B, while 2 and C see each other and B, and B sees only A and C. Nothing would change. A=B-C-D-B B, C, and D form a triangular relation. A and B can see all of them, while C and D see only B, C and D. Nothing changes. Comments: in the first two examples, B has two relations, but its relation to A should be considered strong *because A's status as endpoint overrides the fact B has a second relation*. The same idea applies to the relation between D and E in the first example. In the second example, D is an endpoint, but it has a strong relation, so this argument doesn't even apply to it; nothing changes in its treatment. In the third example, there aren't endpoints, so the argument doesn't apply to it at all; a larger graph can't be considered an endpoint for the purposes of this discussion, even if it has endpoints, or even exactly one (though its own endpoints would also be affected by the change; just the anime directly involved in the example won't be aware of that). In the fourth example, B-C-D-B is a triangular relation; triangles and other forms where nodes have more than one connection are, by definition, not endpoints. | ||||
| Tags | No tags attached. | ||||
|
|
To state it differently: If the current anime (#A) is an "end node", where end node = only 1 animerel to #B, and that animerel is a weak link (other, character, etc), then the graph should traverse into #B's network. Ie traverse step 1 is the directly linked weak rel anime (#B), and traverse step 2 is the graph for #B based on normal node traverse rules. Current graph #A <- weak rel -> #B Proposed graph #A <- weak rel -> #B <- traverse the rest of #B's graph -> -- but only where #A has only 1 relation and that is a weak rel |
|
|
this whole thing is nonsensical. provide actual examples. |
|
|
I didn't want to provide examples for this issue because they tend to become invalid reasonably fast, so I'm going to argue my point with one and provide a few others; the same logic applies, so long as you replace the anime IDs accordingly. https://anidb.net/perl-bin/animedb.pl?show=rel&aid=13508 -- currently, there is only one relation, namely "other" to aid 12420. Having to load https://anidb.net/perl-bin/animedb.pl?show=rel&aid=12420 is a pointless step because 13508's graph is already *wholly and entirely contained* (this is important!) within 12420's graph. The idea is to make things simple by just showing that one instead. Please note that this will ALWAYS happen in the type of situation the ticket intends to address (entry has ONE relation AND it's weak). Therefore, the intended behavior of weak relations is maintained. Nothing changes where it's not supposed to change. I used rel pages, but the same reasoning applies anywhere where the perspective of aid 13508 is relevant (e.g. "related & not in mylist" filter, "indirectly related anime" section of the anime page, etc). A few other examples in case the example initially provided goes poof: https://anidb.net/perl-bin/animedb.pl?show=rel&aid=13226 https://anidb.net/perl-bin/animedb.pl?show=rel&aid=13286 https://anidb.net/perl-bin/animedb.pl?show=rel&aid=13331 https://anidb.net/perl-bin/animedb.pl?show=rel&aid=13360 https://anidb.net/perl-bin/animedb.pl?show=rel&aid=13263 https://anidb.net/perl-bin/animedb.pl?show=rel&aid=13476 https://anidb.net/perl-bin/animedb.pl?show=rel&aid=13512 (this one doesn't even have a graph yet) |
