Randomise default list & add filters

[GenerEOSAus]

As a Block Producing candidate, it would be nice to see the default list randomised versus having it in descending order of largest vote holders. This will improve fairness for all block producers. Additionally, filtering options can be implemented such as; geographical location, vote percentage, newest and oldest.

[thomasbcox]

Default ordering by current vote total will tend to increase voting for those who already have votes, according to my understanding of the psychology of list ordering. If we want a vote portal that does not unduly influence the user, we should probably default to a randomized order of some sort.

[eosauthority]

I feel is very important to be fair to all.

We should not show a position or sort by the top BPs. Real world elections don’t show a position or announce exit polls before the voting closes. We could probably show the positions only after a user has cast the vote. Similar to how a survey’s results are shown on twitter only after you’ve answered the survey.

[GenerEOSAus]

It could be that there is no default list to begin with and users are prompted to select a filter of their choice before a list is populated.

[gammastrat]

This is a valid concern so I appreciate everyone raising this point. Here is some research regarding the "ballot order effect" and it indicates that candidates that are ordered first typically garner more votes (in some cases by an order of magnitude of 4%-5% per Marc Meredith and Yuval Salant of the University of Pennsylvania).

1. http://www.shsu.edu/dpg006/ballot%20order.pdf
2. https://insight.kellogg.northwestern.edu/article/first_among_equals
3. https://www.sas.upenn.edu/~marcmere/workingpapers/BallotOrder.pdf

I will also add that we shouldn't order alphabetically either. So if the Portal is to randomize the order (if we deem that the best method to proceed), does anyone have examples of code that we can begin to vet to see if we can port into the Portal?

[gammastrat]

Additionally, if this proposal is merged, I would like to propose a note/pop-up/something (creative developers and designer types can determine this) that states something to the effect of:

"In order to facilitate fair and equal voting practices, we have randomized the ballot to limit the 'ballot order effect'. Please see here for more information."

[nsjames]

We discussed this briefly on telegram as well. I agree there should be no specific inherit ordering, but since producers are re-fetched every 5 seconds having no ordering at all would mean that the producers list would be re-ordered every time that it is fetched and mess with user experience.

A proposed fix for this is to cache a randomized order for the producers upon the first fetch and reorder the new producers in that exact same manner every time they are regenerated

[kesar]

I feel that a curation based in votes its needed in order to have a good user experience. I suggest a mix between randomness + curation:

double pareto (20-80) random fiter

Example for 200 BPs.

top 40 from top 40 top 8 (rand()) top 32 (rand()) top 160 top 32 (rand()) top 128 (rand())

1-8 rand() 9-40 rand() 41-73 rand() 73-200 rand()

that would give us 4 tiers based on votes that can be randomized.

We could use a seed based in hour of the day, that would give us pretty similar results during 1 hour timeframe (to avoid refreshing and loosing order).

[SteemPowerPics]

You can also use simple randomized arrays in a similar way you would code a game to "shuffle a deck of cards". This would change it up for every person viewing the page.

1) Random Integer (initSortOrder) for initial array initSortOrder = 1(alphabetical) or 2(reverse alphabetical)

2) initBPArray = [ loop through all BPs sorted by (initSortOrder) to build initial array ]

3) Random Integer (ShuffleValue) to shuffle (initBPArray) ShuffleValue = random int (3 - 9)

4) finalBPArray = [ loop through (initBPArray) every (ShuffleValue) to build randomized array list ]

5) loop through (finalBPArray) to show the list.

*If you want to further randomize the initial sort order, you can add in another random variable to use "alphabetical, vote % , etc) as the value to build the (initBPArray) with, then run the option for forward/backward (initSortOrder) on that list.

You can then have logical sort options by name, region, current vote %, etc. people choose.

[who325]

I just want to clarify two things regarding user experience and fairness of voting result.

1. Clashing points exist when we have to give up fairness for user experience.
2. Fairness of voting result is more important than user experience in terms of EOS ecosystem.

So that if we agree,

1. As Rick kindly mentioned earlier with references, certain bias caused by order effects could hinder user’s reasoning and decisions [1, 2, 3]. Any ordering mechanism such as alphabetical sorting or ordering by vote rank would cloud independent judgments into slightly biased ones. Although the number of votes each BPCs get could be a good indicator of performance, it is of low possibility that first numbers that come up really reflect that.
2. User experience often demands particular interface components such as search, curation, and sorting by criteria. End-users nowadays are keen to usability, so no-curation or no-sorting would increase inconvenience and this could result in voter laziness later on (in the future) when voters do not bother to vote only just because using voting interfaces takes a long time(relative to other fast & convenient interfaces).

We have to eradicate any possibility that could cause bias, at the same time we should not ignore usability of the voting portal.

Thus, what I suggest is as follows:

• Randomize order perfectly (as the list is vertical, it is even more important.)
• Only leave search and do not add curation or sorting of any kind (this inconvenience IMO is desirable as it will make users do some research on BPCs).
• Let’s consider not showing the number of votes for first few weeks (or months) as first big votes could result in biased decisions.
• If leaving vote history is possible, categorized list of BPCs that he/she voted for should remain for the moment of revoting (to improve usability).

My suggestions are not for short-term but rather long-term speculations to improve voting interfaces(or system), as with EOS, voting is an essential way of making community decisions.

1)Bain, H. M., & Hecock, D. S. (1957). Ballot Position and Voters Choice. Detroit: Wayne State University Press. 2)Darcy, R., & McAllister, I. (1990). Ballot Position Effects. Electoral Studies, 9(1), pp. 5-17. 3)Krosnick, J. A., Miller, J. M., & Tichy, M. P. (2004). An unrecognized need for ballot reform: The effects of candidate name order on election outcomes. Rethinking the vote: The politics and prospects of American election reform, 51-73.

This one is far outdated but leaves room for thinking (maybe in the future we could conduct fairness/usability tests for each voting interfaces). Bederson, B. B., Lee, B., Sherman, R. M., Herrnson, P. S., & Niemi, R. G. (2003, April). Electronic voting system usability issues. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 145-152). ACM.

[aaroncox]

I have to play devils advocate for a minute here and really ask if this is really the best use of effort at this point in time. The case for randomization is largely based off of research done on traditional/periodic elections, which is not at all what we have here. This is a continuous election (every ~2 minutes) where users are continually voting and almost immediately impacting the results. Voters can also alter their vote at any point in time, which is a huge component that essentially invalidates any prior research involving ballots/elections.

Besides the fundamentals, there's also the implementation and effort required itself. Randomizing the list in a live-updating UI (while not confusing the user) is not an easy task (as @nsjames pointed out above). There are a number of edge cases that would need to be covered for an incredibly limited scope of the overall UX.

• When does it stop randomizing? After X votes, after Y time?
• Does the list randomly sort again if the user uncasts all of their votes?
• What happens when a new producer comes online and needs to be live-inserted into a voters randomized list? Do they go at the bottom or does the whole list rerandomize?

I'm sure there are plenty more, but besides the implementation, we also have to consider if this UX benefits to the actual stakeholders. Randomizing the list itself provides an obvious benefit to the block producers (equalizing the exposure essentially), but does it benefit the stakeholder? I personally am not sure it does and I can see how simply randomizing the list could cause confusion.

There's also nothing to stop stakeholders from just casting "dummy votes" to bypass the random sorting mechanism, view the current positions, and alter their votes accordingly based on those results. Once this is discovered (which will be quick), I'm sure plenty of people will just advise other stakeholders to do the same.

I understand the perception about wanting to make this process fair, but I have to believe there are better solutions than this. If the actual problem boils down to "users who vote randomly will vote for whoever is on the top of the default sort order", then I'd propose a better solution is to build a UX that prompts the user to proxy their vote instead of voting themselves. No random votes are good, and no random sorting is good either.

[gammastrat]

@aaroncox

You raise some interesting and potentially valid points with respect to "dummy votes". Assuming the "dummy vote" hypothesis is valid (btw, can you link to evidence of this?) for a moment, we should ask how wide spread this phenomena is. We do have solid evidence of the ballet order effect occurring in the real world, and while I agree that we are on a blockchain and not in a voting booth, I do not see evidence that would suggest behavior would change because you're looking at computer screen. To be certain, I'm not diminishing the point raised - it very well could be valid, I'm inquiring about the vastness of this potential issue.

Regarding proxy votes, I agree that this should be a feature, albeit I'm not certain it will be available at launch of the portal.

If proxy voting is not available immediately, and we can't control for the dummy votes, what else may you recommend to help achieve a fair process?

Thank you again for your thoughtful comments.

[who325]

@aaroncox

First of all, continuous voting does not make cognitive bias go away especially with vertical UIs where 'framing as rank' always works (to let first rankers stay first, unchanged). Plus, do we really need to update results of other voters real-time? In my opinion what users need to see is a feedback that their votes have been successfully saved, not the whole numbers changing continuously (we are not trading in an exchange, rather making serious long-term decisions).

So as you mentioned, if we are not going to change the vertical UI (change to horizontal card UI etc.), we need to randomize.
It comes down to a solution if we can save voting history, we can stop randomizing after the first vote is made. Before that, randomizing by a certain timeframe as @kesar suggested seems reasonable.

[nsjames]

All great points. I like where this discussion is going.

Just a note, we do in fact have to continuously regenerate the list but it's mainly about searching for newly registered producers. Regenerating vote totals are just a byproduct.

It's also possible that this is all due to the fact that the list is .. well a list. If it was a circle this wouldn't be an issue, correct?