Improve UX for initial loading on site frontend

[jeffpaul]

Is your enhancement related to a problem? Please describe.
From @dkotter in #6:

On the FE, right now it renders out the audio players and then those get replaced with the WebAmp player. Thinking some basic styling here where those players get hidden and maybe some sort of placeholder container, so once the player loads in it's not shifting the page contents around

Describe the solution you'd like
Review the work in #6, the current state of the develop branch, and what approach should (if any) be taken to resolve this issue.

Designs

Describe alternatives you've considered

Additional context

[jeffpaul]

Could the plugin ship with the base skin images and render those initially until the player and correct skin and audio file(s) load in?

[dkotter]

I've pushed some changes that help with the front-end a bit. We change the individual audio players from having src attributes to data-src attributes. This prevents the audio files from loading unnecessarily which helps with load times. We then hide those audio players so they never show.

In my testing, the WebAmp player loads in fairly quickly, so while I still think it would be nice to have some sort of placeholder or loading indicator, things are better now

[jeffpaul]

@fabiankaegy any tweaks you might recommend on initial UX here?

[iansvo]

@jeffpaul Can you confirm if this is still needed? Seems to be a duplicate of #38.

[mehul0810]

@jeffpaul After doing some research in admin and frontend, there are couple of items I have noted:

• With Winamp block in admin, when I click on "Preview Player" then the player always sticks to the top making it really hard for the first time user to get back to normal player mode until the user refreshes the page or try scrolling as the player it sticked at the top scrolling helps to show the option and then we can change it to normal player mode from preview. The editorial experience around this needs some improvement See screenshot:
• The player in the frontend looks good. However, I feel there are couple of things that might need improvement:
• • The player buttons looks disabled irrespective of it being enabled/disabled
• • The player can be moved around on the page overlapping the content but that leaves a space where it was originally placed. So, wondering if moving around of player is a feature then can we make the whitespace to be moved around along with it? 💭

Note: I think all the items I mentioned should not be a problem. But, just wanted to add my experience being a new user.

[Sidsector9]

@jeffpaul this maybe already fixed as part of some other PR.

While testing:

• The audio HTML element is always hidden.
• The WinAmp container has a min-height which prevents layout shifts.

As of now, we just have a plain empty container until the player loads. We can improvise that if needed in a separate enhancement issue.

@mehul0810 can you open that as a separate ticket? It will be easier to track that way.

[mehul0810]

@Sidsector9 Thanks for reviewing. I have created the issue #83

[jeffpaul]

It looks like we could build upon the work in Gutenberg 14.7/14.6 in adding WordPress/gutenberg#45875 && WordPress/gutenberg#45300 such that we can set the default height of the block (based upon the components enabled: player, playlist, visualizations, etc). This will likely mean we need to bump the WP minimum to 6.2 as I believe these Gutenberg updates will be in core then, so a PR to handle for this is not a near-term need but something we should aim for in testing for WP 6.2 compat later in March.

[av3nger]

I wasn't able to replicate any CLS or content layout replacement happening on FE. It looks like all the skins default to the same size, which is already pre-set via CSS.