Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add some data checking UI/UX features to the results entry page #38

Open
philipbelesky opened this issue Jan 2, 2017 · 7 comments
Open

Comments

@philipbelesky
Copy link
Contributor

Apologies for the open ended feature request. I also don't have a dev environment working atm where I can replicate things so I'm adding this with 100% certainty that this already isn't the case and I've misunderstood something.

From having a number of iterations on Tabbycat’s eballot page we’ve tried to identify a number of UX/UI features that can help aid in minimising human error during the ballot entry process, particularly on mobile devices. Again I can’t bring up the exact tabbie interface right now so I’m going by memory on what are some options for improvement:

  • Display running totals of both team scores and team margins either on the confirmation page and/or on the initial entry page. This provides another piece of data that can be cross checked against the paper ballots to identify errors (by the adj doing the entry).
  • Display running rankings of the teams, ideally color coded, on either the confirmation page and/or the initial entry page. Ideally there would be a 2x2 'matrix’ style layout of the rankings here so that it can be easily compared to the ballot’s layout (which is also presented in the standard 2x2 matrix)
  • Optimise the mobile layout’s spacing and sizing so that layout is more compact (easier to see/compare scores across teams) and key information (names, scores) are more prominent.

I could potentially look at some of these in a PR, but it’s not likely that would happen anytime soon. The javascript needed to add these though is quite simple and probably easily added to the existing form. If helpful I can point to some analogous functions used in the tabbycat ballot page. It could also be worth pursuing an shared library or plugin for ballot entry as there are not too many differences between 2 and 4 team formats.

@chief-nerd
Copy link
Owner

Hey @philipbelesky - Thanks for your input
Regarding the 'Display running totals' - I don't like to display any points or speaks if possible as this might influence the judge.

Regarding the 2x2 matrix I think this is a really good input and afaik this was already done in some way. The problem is the available space on mobile. But I am open to new ideas here.

@philipbelesky
Copy link
Contributor Author

philipbelesky commented Jan 2, 2017 via email

@chief-nerd
Copy link
Owner

@philipbelesky we had this already. See:
https://github.com/JakobReiter/Tabbie2/blob/master/tabbie2.git/frontend/views/result/confirm.php#L41
I think we took it out because it either was a UX/UI issue or it confused people too much ... @rscoates do you remember?

@rscoates
Copy link
Collaborator

rscoates commented Jan 6, 2017

Yeah, the vast VAST majority of discrepancies between the eBallot and the paper ballot are that a judge gives a 76/77 (for example) on the eBallot, and a 77/76 on the other. The totals don't stop that, and, in our experience, actually lead to worse results entry, as judges use Tabbie as a calculator (yes, they are that lazy) when doing totals on the eBallot.

I assume there's a happy medium, but I haven't found one yet.

@philipbelesky
Copy link
Contributor Author

philipbelesky commented Jan 6, 2017

So if there is an issue with the scores being entered out of order, it might be worth setting speaker order as an explicit step during both the paper ballots and the eballots. Obviously it'll slow things down a little but it may be worth it to heighten correctness. My vague theory on this is that adjudicators have a mental model of that debate that is partly chronological (speaking order) and partly spatial (ie the OG/OO/CG/CO matrix) and having to sometimes flip the speaker order and sometimes not flip the order is an extra mental overhead that leads to score errors. When the order is set before scores are the interface will then always conform to this mental model and the overhead is lessened.

For Tabbycat's eballots we use dropdown menus, but for BP you could just have a simple "reverse" button that swaps the order of the DOM elements. That said this may not be as effective if the paper ballots also don't let you set the speaker order explicitly (by writing them out in the order, rather than just marking the position) as that will then also clash with that mental model as well as making cross-checking easier.

@rscoates
Copy link
Collaborator

The problem is exactly as you said - the paper ballots are a fixed order, and I'd like to keep it that way (as it helps with judges reading names out / confirming it's the correct people / not having to decipher handwriting), and at the moment, the judge can check the paper against the eBallot as a match. It's, I'd guess, a problem in 3% of ballots per round, so it's only at WUDC that this is actually an issue every round, and I don't think the extra burden on judges is worth it. If you were doing a tournament with only eBallots, it might be something to consider, though.

@philipbelesky
Copy link
Contributor Author

Cross-posting this thought incase it is also of interest to tabbie: TabbycatDebate/tabbycat#400

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants