lrem / ladders Goto Github PK

Sign in with Google requires one. The idea is: we store no PII, so there's not much to care about.

It would be nice to have something more creative than angular logo as fav, with a glorious title saying just "Web"...

Deleting a match makes the next recalculate raise:

sqlite3.IntegrityError: UNIQUE constraint failed: history.player, history.ladder, history.timestamp

It would be nice to have analytics about how people use the thing.

Removing vandalism is a bit hard when all you have to guess your decisions on are the results.

The list view displays only skill rating. A detailed view for a player could give more insight:

• number of games on record
• number of wins and losses
• recent matches filtered for the player
• historical ranking plot (depends on #23)

The button would swap entered players between teams.
It would allow for entering the players before the game is resolved.

The finder component should also list all the ladders with owner being the singed in user.

Make each line align perfectly with the 32-pixel grid. This will make the icons used by browsers sharper.

The backend already supports arbitrary team shapes and many interesting games are not duels. We need to have the UI allow games with more players. Some ideas:

• The dialog can always display a NxM grid, if the teams are uneven it can accept a blank space.
• Game shapes probably won't differ much within a league, so keeping at least the defaults in the database sounds like a good idea.
• For extra flexibility, we can have a way to extend the grid from within the dialog.

Currently we ask for draw probability at ladder setup, but then offer no way to express the draw when reporting a game. We do need a way to express draws. But before we get that implemented, it would be nice to not show that table row and just assume zero.

Current URL scheme is unclear, inconsistent and will, especially when both front- and back-end are served from same domain, require quite some special casing.

The finder component should also list all the ladders recently viewed from this browser.

Currently, everything is in a hard-coded debug mode. We need to turn that off for production and prepare tooling to make deployment a no-brainer.

While the content displays correctly, it lacks table headers if there are more than two teams.

As it turns out, we currently delete a player from a ladder only if there are no games left of that player across all ladders. It should be specific to this one.

It won't hurt to store players' skill ratings over the history. As a bonus, it will allow faster recalculation after removing a past match.

Currently the finder component on the landing page simply navigates to given name, even if such a ladder does not exist. We should instead only show a warning that the name is wrong.

There finally is a https://material.angular.io/components/table. Both the matches and ranking components seem to be good fits. The game reporting dialog probably should stay as it is, with the hybrid tabular/list view.

Currently we only have one owner per ladder, who can change settings and delete bogus matches, and everyone can view and add matches. It might be beneficial to have tiers of owners, deleters, adders and viewers, with an ability to specify which tier everyone gets.

Currently there is no way to tell apart a new ladder, with no games played, and a ladder that does not exist yet.

Self-explanatory time-saving, typo-preventing nice feature.

Match deletion, while not part of the regular happy flow, is still a critical functionality. It definitely should be tested.

The most popular ladder so far has instituted a rule that a flawless victory (10:0 score) counts double. So, they enter such a match twice. It would be way more elegant if that was explicitly supported instead.

The matches view started getting laggy for the big ladder, so I limited it to 20 most recent matches. Now, there is value in seeing old history. To that end, The UI should allow:

• Extending the set of matches shown to a large but still responsive number (100?).
• Cycling to older matches.

After 3dfe509 the + button no longer floats to the bottom of the screen. While this is a reasonable cost for getting rid of the mess, it's not what we want.

Currently it's just the number of seconds since the Unix epoch, which is not exactly human-friendly.

Currently the call to action from landing page takes the user directly to ladder setup form. After filling the form and clocking create, a terse error message suggests the name may be already in use. For any name attempted. The actual cause: the user is not signed in. Which will always be the case, as the only mention of signing on is hidden in the hamburger menu.

The app itself is tens of kilobytes, while vendor.js sits at 1.3M. It might be possible to shave some of that, especially around rxjs,

Right now the game dialog asks for zero-indexed teams. It would be much nicer to ask for "Winner(s), 2nd place, 3rd place, ...". Even better, add special cases (relevant after fixing #4):

• only pluralize "Winners" if game allows multiple people per team,
• if there are only 2 teams, name the second one "Loser(s)".

We need a way to add users to owners of a ladder and to the additional tiers requested in #2. Ideas how this might work:

1. Add a dialog displaying the user id (number from Google sign in) and a for allowing the owner to add the user. This would require separate messaging to pass the number.
2. Also display a qr code and allow scanning it, using e.g. html5-qrcode. This allows in-person transfer with mobile.
3. Change the user id to be based on email (obtainable with the Google sign in). Humans can deal with email, but then we're storing otherwise unwanted personal information.
4. Add a user-selected username. This is easy to transfer and might be a good idea if we want a reasonable way to remove someone from ACL.

There should be a landing page at / that describes what the whole thing is about and how to get started. There might be need for little extra pieces of explanation around the place.

The current database schema wrongly assumes that a player of a given name (primary key) will only ever belong to a single ladder. This should be fixed either by introducing an integer primary or by making the primary key use both player and ladder name.

The fonts, thus far, are only specified for the footer. For some reason this means that every other element ends up with a different font face, style, size and whatnot. The whole thing definitely would look way better if there was a single font used throughout.

Table does not wrap, making it sometimes impossible to select some player name inputs.