Visual loading indicator fallback while assets are loading

[SableRaf]

Increasing access

This proposal aims to make p5.js more accessible and user-friendly, particularly for non-English speakers, by replacing the text-based "Loading" message with a simple loading animation.

Which types of changes would be made?

• Breaking change (Add-on libraries or sketches will work differently even if their code stays the same.)
• Systemic change (Many features or contributor workflows will be affected.)
• Overdue change (Modifications will be made that have been desirable for a long time.)
• Unsure (The community can help to determine the type of change.)

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

What's the problem?

Currently, p5.js displays a text-based "Loading" message in the top-left corner of the page during the execution of the preload() function. This approach is not very visually engaging and can be confusing for end-users who do not understand English or have visual impairments.

A p5.js coder can replace "Loading" with a custom animation. This is mentioned in the preload() and the p5.js overview page but this option is still relatively hidden and not particularly beginner friendly. See this Coding Train tutorial on loading animations.

What's the solution?

Replace the text-based "Loading" message with a visual loading animation. This animation could be a simple, universally recognized loading indicator (e.g., spinning circle) that provides a visual cue to users that content is being loaded without relying on text. An animated loader also better conveys the fact that something is happening. We can use the afterPreload lifecycle event to trigger hiding the loading animation. Possibly, the loading animation itself could be user-overridable via a preloadAnimation() function.

Pros (updated based on community comments)

Accessibility: Enhances p5.js accessibility by providing a language-independent loading indicator.
User Experience: Improves the user experience with a more engaging and informative visual cue during load times.
Internationalization: Supports p5.js's goal of being globally accessible by removing language barriers in the loading process.
Visual identity: The default loading animation could be an opportunity to include subtle elements of the p5.js visual identity like the pink color.

Cons (updated based on community comments)

Intrusivity: Depending on its design, the loading animation may be perceived as intrusive. We can mitigate this by making it easy to change the animation or deactivate it, and add examples on the preload() reference page.

Proposal status

Under review

[perminder-17]

Thank you for bringing this up @SableRaf . I find your proposal satisfactory, and all the mentioned benefits make sense. Initially, I thought using text for loading, instead of animation, was to prevent confusion for users creating sketches and animations in p5.js.

I apologize if I am wrong but do you think using a loading animation might give a similar appearance to a sketch, causing potential confusion??

The default loading animation could be an opportunity to include subtle elements of the p5.js visual identity like the pink color.

What I think using this may also help in avoiding such misunderstandings.

[limzykenneth]

@SableRaf If we adopt async/await per #6767 would a loading indicator still be needed? With async/await there will not be a need for a separate preload() function and data loading probably will feel similar to the synchronous behaviour of Processing for example.

[SableRaf]

Thanks for your reply @limzykenneth. I'm not sure I fully understand the implications of using async/await for loading so take my feedback with a pinch of salt but, in cases where large files or many assets are being loaded, would a loading indicator could still be beneficial to inform users that the process is ongoing? Maybe it can be less intrusive, like a loading spinner in the top left corner.

[limzykenneth]

@SableRaf I was thinking something along those lines if we are to still retain the loading indicator with async/await. I believe that is possible, just wondering if it is something we want to keep around. I don't quite remember but does Processing do anything similar when waiting for slow file reads?

[SableRaf]

does Processing do anything similar when waiting for slow file reads?

Not that I'm aware, but file reads are probably faster with Java on Desktop, right?

[limzykenneth]

Yes, certainly with file read from disk definitely faster than file request over the network. So I think there are a few options:

• Full canvas blocking loading indicator - Similar to what we have now, perhaps visual instead, cons would be that it can seem intrusive
• Loading spinner/graphic in corner - Less intrusive (although not entirely unintrusive)
• Opt-in or Opt out for the above two - As part of the loading API, sketch author can decide whether to use the loading indicator or not through an additional argument. It provides choice but slightly complicates the API, also it is unclear whether loading indicator should be opt in or opt out
• No loading indicator at all - Likely closest to semantic JavaScript but long loading time can be misunderstood as performance issue

[SableRaf]

Thanks @limzykenneth, that sums it up perfectly!

I just thought of a way to make this work as opt-in in a relatively non-intrusive way: what if when files take a long time to load, we throw a warning message via the FES suggesting that the sketch author use the optional loader? For example:

🌸 It looks like your file is taking a bit longer to load than usual ⏳ Consider using loadingAnimation() to display a loading animation while your files are being loaded.

This way people would only be exposed to the feature when they need it.