"preference voting" and "ranked choice" are largely used as synonyms, as both involve an ordered list of preferences. When I mentioned writing out a list of numbers in order, I was talking about ballot UX design here.
The ordinary case of preference voting is extremely explainable: if more people prefer A to B than prefer B to A, A beats B; pick the candidate that beats everyone else. "It's like running a bunch of head-to-head elections all at once."
They're also really easy to tally into a table: "A ranked above B" is a point for A over B; "B ranked above A" is a point for B over A; A and B ranked equal relative to each other doesn't add anything to either of those two cells.
The corner cases like cycles almost never come up. And even then, it's relatively easy to explain a high-level understanding of the most common methods: "if there's a loop of people who each beat the next one in the loop, ignore the one with the smallest margin of victory". If A beats B in a landslide, B beats C in a landslide, and C very narrowly beats A, A wins.
Also:
> Let's say you're three people and the rankings are ABCD, EBCD and FBCD.
Every ballot implicitly ranks every option, and the usual assumption is that if someone doesn't even care enough to list a candidate, they prefer every candidate they did list over any candidate they didn't list. (There are UX design ideas that could let someone say "this candidate is last" without ordering every candidate, but that adds complexity.) So these ballots are:
A > B > C > D > E = F
E > B > C > D > A = F
F > B > C > D > A = E
Writing it out that way shows that B beats A by 2:1, B beats E by 2:1, B beats F by 2:1, B beats C by 3:0, and B beats D by 3:0. No corner cases or cycles here; a majority of people prefer B to every other candidate.
The ordinary case of preference voting is extremely explainable: if more people prefer A to B than prefer B to A, A beats B; pick the candidate that beats everyone else. "It's like running a bunch of head-to-head elections all at once."
They're also really easy to tally into a table: "A ranked above B" is a point for A over B; "B ranked above A" is a point for B over A; A and B ranked equal relative to each other doesn't add anything to either of those two cells.
The corner cases like cycles almost never come up. And even then, it's relatively easy to explain a high-level understanding of the most common methods: "if there's a loop of people who each beat the next one in the loop, ignore the one with the smallest margin of victory". If A beats B in a landslide, B beats C in a landslide, and C very narrowly beats A, A wins.
Also:
> Let's say you're three people and the rankings are ABCD, EBCD and FBCD.
Every ballot implicitly ranks every option, and the usual assumption is that if someone doesn't even care enough to list a candidate, they prefer every candidate they did list over any candidate they didn't list. (There are UX design ideas that could let someone say "this candidate is last" without ordering every candidate, but that adds complexity.) So these ballots are:
Writing it out that way shows that B beats A by 2:1, B beats E by 2:1, B beats F by 2:1, B beats C by 3:0, and B beats D by 3:0. No corner cases or cycles here; a majority of people prefer B to every other candidate.