Asked for by Leong Sen Fong, 2026-09-28 13:04: should these two invite pages get charts like the others? Investigate, then UI design first.
No code has been changed. Mock-ups use made-up numbers (real data today is 5 minted codes and 1 waitlist person). The dashed green box is the only new part of each page. Drawn by Tora Master.
The proposal in one screen
Page
Question the chart answers
Two bars per day / week / month
Line under the chart
Waitlist(recommended)
Is the queue growing faster than we invite people?
■ signed up · ■ invites sent
“Queue grew by 8 in these 7 days (17 signed up − 9 invites sent)”
Mint Codes
After I mint a batch, how fast are the codes actually used?
■ minted · ■ claimed
“29 of the 50 codes minted in these 7 days are claimed (58%)”
Same as the five charts shipped today (v2.758): the shared 7D · 30D · 90D · 1Y · All switch, opening on 7D every time; week bars on 90D, month bars on 1Y; the same chart component (fl_chart), tap any bar for its numbers. The chart sits in the History slot of the page order the invite pages share (Overview › Actions › History › List). Nothing that is on the pages today moves or changes.
1 · Waitlist
‹ Waitlist
OVERVIEW
Unconfirmed3
Queued12
Invited5
Joined9
⏳ Oldest in queue: 9 days
INVITE CODES EMAILED
Sent14
Usable5
ACTIONS
Invite next 5
NEW
HISTORY · LAST 7 DAYS
7D30D90D1YAll
Mon 28 Sep
2 signed up2 invites sent
1 joined
↗ Queue grew by 8 in these 7 days (17 signed up − 9 invites sent)
ⓘ Tap any day for details · people removed from the list aren't counted
PEOPLE
amy@… Queued · 9d
ben@… Invited
cho@… Joined
Whole page, 7D (as it opens). New part in the dashed box.
‹ Waitlist
HISTORY · LAST 13 WEEKS
7D30D90D1YAll
Week of 28 Sep (so far)
5 signed up3 invites sent
2 joined
↗ Queue grew by 24 in these 13 weeks (44 signed up − 20 invites sent)
ⓘ One bar per week · tap any week
The same chart on 90D: one bar per week.
What each number is, and where it comes from
Number
Counted from
Why this source
Signed up (light bar)
the day the person joined the waiting list
Unconfirmed sign-ups count too: they did sign up. The overview above still separates Unconfirmed from Queued.
Invites sent (dark bar)
the day each waiting-list invite code was made
Every invite, first or repeat, makes a new code, and codes keep their dates. Not the list's own “invited at”: that date is overwritten on a re-invite and wiped when a code expires unused, so a past week would change after the fact.
Joined (in the detail row, not a bar)
the day a waiting-list code became an account
Two bars stay readable on a phone. A third bar would make each day's slot too thin at 30D.
People removed from the list, and old unconfirmed sign-ups that get cleaned up automatically, are deleted, so they can't be counted. A small note under the chart will say so (see question 3).
2 · Mint Codes
‹ Mint Codes
OVERVIEW
Unused21
Claimed29
Revoked0
Expired0
Claimed 29 of 50 (58%) · last one Sep 28
ACTIONS
Mint codes
NEW
HISTORY · LAST 7 DAYS
7D30D90D1YAll
Mon 28 Sep
0 minted7 claimed
29 of the 50 codes minted in these 7 days are claimed (58%)
ⓘ Tap any day for details
BATCHES
Launch party 29 / 50 claimed
CODES
HOOP-7K2F… Claimed
HOOP-Q9MD… Unused
Whole page, 7D. One batch of 50 was minted on Wed; claims trickle in after.
‹ Mint Codes
HISTORY · LAST 13 WEEKS
7D30D90D1YAll
Week of 21 Sep
50 minted18 claimed
35 claimed in these 13 weeks, against 70 minted
ⓘ One bar per week · tap any week
90D: minting shows as a few tall weeks; claims spread out.
Number
Counted from
Minted (light bar)
the day the official code was made (codes you mint here only, not member or waiting-list codes)
Claimed (dark bar)
the day it was claimed. “Claimed” is this page's own word (overview, batch cards), so the chart uses it too.
Minting comes in bursts, so most days show only claims and one day shows a tall minted bar. That is the real shape, not a bug. Revoked codes drop out of the history (the same rule Invite Performance already uses).
Invite Performance on the dashboard has a “Minted by you” row, but only as a total for the period. This chart shows when, which that row can't.
3 · Questions for you
Build both, or only Waitlist? My suggestion: both, since they are small and use the same parts. But if you want only one, Waitlist is the more useful.
Waitlist: two bars plus “joined” as a number (as drawn), or three bars?
Removed people: should removals start being kept (one small table), so the chart can count them from now on? Or keep deleting as today and just say they're not counted? My suggestion: not now.
Batch page (tap a batch on Mint Codes): also a chart there? My suggestion: no. Its card already says claimed / total.
Decisions (Leong Sen Fong, 2026-09-28 13:15 MYT)
“follow your suggestions”: build both · Waitlist two bars + joined as a number (as drawn) · removed people not counted, the chart says so · no chart on the single-batch page. Building started.
Shipped 2026-09-28 as v2.759: backend live (/waitlist-history, /codes-history); app on the web version (hoop-web.pages.dev) and in the next TestFlight build.
4 · How the build would be split (after your go)
#
Subtask
1
Backend: one Waitlist history endpoint and one Mint Codes history endpoint, both with the same ?range= rules as today (unknown range → error, week / month bars, Malaysia days).
2
App: the Waitlist chart in its History slot.
3
App: the Mint Codes chart in its History slot.
4
Tests, screenshots in every range, the fl_chart guard, docs, version, web version.