You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our thoughts are to periodically (i.e. once a week), and maybe globally (i.e. everyone shares the same timestamp-based random seed), dynamically replace certain slots in a group's carousel with a randomly picked album from a manual selection for that slot. Essentially, randomized carousel slots are a list of albums, a periodically random one of which will always be shown in that slot's position. All the albums should (or could) represent the same "idea", and any of the albums may be shown to that effect. This lets there be more variety and diversity in the carousels while still keeping a coherent theme/layout. (A period is used, rather than randomizing on every load, to avoid needlessly frequent distractions, and to give a chance to come back and explore a new selection later.)
Implementation notes:
Probably just let the item in the carousel album list be an object, as below:
Flatten and normalize, into objects or sub-things. (Probably objects, for now.)
We can't do dynamics like this on the server, it has to be handled by client JS. The mutatePageContent step exists for this purpose. Blocking render introduced with scoped chronology links should help, but it's not a badly jarring consequence on other pages, because we're just slotting out a different album in the same place—no layout change.
Make sure this is fine without JS. Top-level for all carousel items should each be represented by a container, rather than <a>, and contain multiple <a> when randomization is applicable; all except the first should be style: 'display: none'. Use a class or data tag to indicate the slot (container) should be randomized.
We should support this behavior on homepage carousels, too. Make sure the implementation is not specific to groups.
The text was updated successfully, but these errors were encountered:
Beyond Canon slot: Beyond Canon and any other possible future albums for HS2/HSBC
Hiveswap slot: Act 1, Act 2, Act ect, Friendsim, Grubbles/Grubbels (these would both stick with the most recent album in each category on the Home page)
Official (group) and homepage:
CaM slot: literally just both Colours & Mayhem albums unless there happens to somehow be another contest in the future (to which i would include in this slot)
Solo Album Month slot: three applicable albums (two smaller slots before getting into more substantial slots ↓)
Numbered album slot: Homestuck Volumes 5 through 9
Solo Album slot: Strife, Alternia, MTaHK, Song of Skaia, Prospit and Derse, Sburb, Medium
non-numbered compilations: Alterniabound, Cherubim, The Felt, MC:DD, (Squiddles could be exclusive to the explore official page)
Fandom (group):
CANMT slot: Cool and New greatest hits and Cool and New volume 3 (the send off album) (literally can't remember if 9 and Greatest Hits 2 are part of the "considered overall good albums" of CANMT, but any CANMT albums similar to the two listed before would fit for this slot)
Homestuck Gaiden slot: with the ever expanding Fandom page, i think Gaiden can go down to a single slot instead of two with LOFAM5a2 still in permanence (until the next LOFAM, of course)
DCRN/Vast Error slot: probably anything that isn't the singular Volumes 1 through 3 and albums with single digit track amounts, that's all i've got for them though
Beyond (group):
Bowman slot
Oceanfalls slot
Toby Fox: Undertale, Deltarune, Temmie's games, Rose of Winter, Soul of Sovereignty, Itoki Hana collab singles (not sure the stance on Little Town Hero, but i think i'd lean towards not at least compared to the others listed here)
Brought up by Jebb (#hsmusic-chat) and this particular idea pitched and detailed by FF (#hsmusic-chat).
Related to #501, but this is a distinct idea.
Our thoughts are to periodically (i.e. once a week), and maybe globally (i.e. everyone shares the same timestamp-based random seed), dynamically replace certain slots in a group's carousel with a randomly picked album from a manual selection for that slot. Essentially, randomized carousel slots are a list of albums, a periodically random one of which will always be shown in that slot's position. All the albums should (or could) represent the same "idea", and any of the albums may be shown to that effect. This lets there be more variety and diversity in the carousels while still keeping a coherent theme/layout. (A period is used, rather than randomizing on every load, to avoid needlessly frequent distractions, and to give a chance to come back and explore a new selection later.)
Implementation notes:
Probably just let the item in the carousel album list be an object, as below:
This can be expanded to support e.g.
Rotating From
or similar, in the future.Normalize the format with a
parseCarouselEntries
function or similar.{select: 'static', album: albumRef}
{select: 'random', albums: [...albumRefs]}
{select: 'rotate', albums: [...albumRefs]}
(for example)We can't do dynamics like this on the server, it has to be handled by client JS. The
mutatePageContent
step exists for this purpose. Blocking render introduced with scoped chronology links should help, but it's not a badly jarring consequence on other pages, because we're just slotting out a different album in the same place—no layout change.Make sure this is fine without JS. Top-level for all carousel items should each be represented by a container, rather than
<a>
, and contain multiple<a>
when randomization is applicable; all except the first should bestyle: 'display: none'
. Use a class or data tag to indicate the slot (container) should be randomized.We should support this behavior on homepage carousels, too. Make sure the implementation is not specific to groups.
The text was updated successfully, but these errors were encountered: