Randomise homepage members #104
Conversation
vladh
force-pushed
the
vladh/randomize-members
branch
from
2a9a5ee
to
0902069
Compare
|
The heading is no longer accurate. How about "Some Member Companies"? Also we need to balance the two goals of giving all members airtime with putting our best foot forward for site visitors. I think we do this best by weighting the selection based on developer count. For today this means we should always include Sentry in the selection, plus four others. We can make it more complicated as we get more companies in larger buckets (how long until we have multiple companies larger than Sentry?). 
|
|
@chadwhitacre Okay, here's a new strategy, which I think meets your requirements, but also is very fast and non-network-intensive. When Javascript is off, companies are sorted by descending number of devs. When Javascript is on, the first company is always the biggest one, then each subsequent company in the sorted list has a 50% chance of getting skipped, and this is carried out until 5 companies are chosen. This means that predominantly large companies will be shown, but everyone has a chance to get shown. |
vladh
force-pushed
the
vladh/randomize-members
branch
from
f426255
to
dedb0a8
Compare
When Javascript is off, companies are sorted by descending number of devs. When Javascript is on, the first company is always the biggest one, then each subsequent company in the sorted list has a 50% chance of getting skipped, and this is carried out until 5 companies are chosen. This means that predominantly large companies will be shown, but everyone has a chance to get shown.
vladh
force-pushed
the
vladh/randomize-members
branch
from
dedb0a8
to
a4c142c
Compare
|
Love the algo, thank you. Did you intend asc tho? 
|
|
Your screenshot is descending by number of devs. The pledge amounts are static in the test data, so that results in ascending amounts! |
|
I’ll remove the test data — we don’t need it anymore, so it will just add confusion. |
Hah! :) In that case ... |
Here's the approach I took. The list of members is randomised serverside for good measure. A row is created in the
MiniLeaderboardtable for each member, but only the first 5 members are nothidden. This increases network payload, but only marginally. Then, if Javascript is enabled, some Javascript code runs that calculates a set of 5 new indices of members to be shown. The appropriate members are then hidden/shown. This happens so quickly that it's unlikely to cause flashing because of a delay in executing JS, and it also gracefully degrades when JS is disabled, with members then being randomised on every build.