I am building a website with a large amount of sounds that should be played upon
ID: 647865 • Letter: I
Question
I am building a website with a large amount of sounds that should be played upon clicking elements. (It is a language learning website, and many words and phrases will be clickable, to hear pronunciation.)
In an earlier prototype I simply load the sounds on the page, and then play them in elements' onclick-event.
I'm worried about the overhead of loading all sounds, on every page, always, as certain pages may end up having quite a lot of them. I figure it would be way better if sounds were not loaded before the user actually clicks an element.
But then again, would this lead to too considerable waiting time between click and playback? And can I make the sound be cached, so that on consecutive playbacks it will not be loaded every time? Also, how do I go about this as elegantly, so that the markup job does not become unbearable when there are maybe a hundred or more sounds in certain pages?
What would be the best way(s) to implement this?
Explanation / Answer
I think you can look at a few options...
Start by Building 2 Prototypes
One prototype with all sounds pre-fetched.
One prototype with all sounds available on click.
This will allow you to actually compare if it's really that bad. Depending on how you architecture this, you probably won't need 2 separate prototype and just a configuration change (preferably with a URL request parameter, like ?sound-prefetch=false). This could come in handy later.
Local Cache
Depending on the usage of your site, it could be that a local cache would be good enough for you, if your users have modern browers supporting a local DB. Of course, this may not necessarily apply to your use case, but if it does maybe try to cache the most commonly used sounds for all users, and the recently used sounds for the current user.
Also make sure to leverage the browser's normal cache by specifying correct headers. That would work for most browsers, both modern and old.
Monitor Activity
The best way to do what's best for your users it to look at how they use your software. Do they listen to the same sounds sounds often? Do the location of the sound snippet have an impact on the likelihood of it being played (dead center of the screen, top nav bar, etc...)? Gather stats after a few days/weeks/months and see what makes the most sense to prefetch.
Compress Your Sounds
This will depend on your actual use case again, but I'd suspect that for music learning you can use pretty compressed audio files and still be able to hear quite well. So don't hesitate to crank up the compression ratios on the audio files you serve.
And by the way, what's the format of the files you serve?
How to Embed your Sounds?
How do you embed your sounds? Did you consider several approaches? You can play them using a simply JavaScript based player that will require to fetch the whole file, or maybe you can use a file format and a player that supports streaming, so that you don't need to wait for the file to be fully loaded.
Implementing your own embedded player (one for each sound), be it with JS, Applets, Flash or something else, might be a better alternative. Or maybe even a single Rich Internet Application might be a better alternative, depending on how many sounds you have per page.
Try to Give Your User a Choice
It might be best to then leverage a few of the strategies above and then give the users the chance to pick what's best for them. Your users in well-connected areas with fast broadband won't mind so much a few MBs of download per page, especially if they know what the intended purpose is, whether it's pre-fetched or not.
However, users who connect with a less than ideal bandwidth will thank you if they have the opportunity to chose how to load your pages.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.