Usability improvements for events with lots of choices
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 118
- Forks
- 76
- PR merge metrics
- No merged PRs in 30d
Description
I've been sent a Newdle with a whopping 49 choices for timeslots and 14 participants, and I realized it's very hard to see who can or can't make it to the meeting.
First of all, it would be very useful if it was possible to display the choices in descending order of highest number of available participants (ie. best candidate dates/times for the meeting). Right now the list of choices is always in chronological order and you have to find the best option manually. This is trivial when there's only a few choices and you can see them all at once in the screen, but it becomes more difficult with 49 choices. It would be way easier if you could sort the choices by number of available participants.
Secondly, in grid view it is difficult to see which participants can't make it when there are a lot of choices because the Participants column scrolls off the list. This should be a fixed column, with only the dates being scrolled, so you could always see the participant's name no matter how wide the grid is. Another useful way of making this easier to see is if the icon had a tooltip with the participant's name, sort of like this:

Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the frontend entry points for the event choice list and grid view. Inspect how choices are currently ordered and how participant names are displayed while scrolling. Done means choices can be ordered by participant availability and participant names remain visible or available through tooltips in wide grids.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100