My client is not an idiot. If he wants 15 seconds of quiet background
music
that plays upon opening a seating chart in a concert hall he can have
it.
You seem a bit rude and off the point here. My job is to do
professional
work regardless of what the client wants. My clients job is to let me
know
what he wants. Simple, really.
I was hoping to get an answer without the rudeness that a few of you
have
shown. I wasn't asking what your opinion was about this. That is
irrelevant to the question at hand.
While I agree that background music on its own is annoying, I won't
second-guess your need here as I agree it's not relevant. I'm only
going to address the technicalities of doing it, which I think have
been pointed out but perhaps haven't been made entirely clear.
While you wisely focus on using a ubiquitous digital audio format such
as MP3 for this task, you're overlooking a major issue - the experience
itself depends on:
1) the presence of players to handle your media - not hard with MP3, I
think it's safe to assume everyone has a workable MP3 player on their
system , or built in to their OS or browser;
2) the use of code within your HTML that will seamlessly and properly
hand of your content to a wide variety of players and still create a
consistent experience.
Number 1 is easy; number 2 isn't. Every embedded player has its own API
(set of HTML attributes) for controlling playback -- for instance, will
the playback start automatically or only in response to user
interaction? Will it loop, and if so will the loop be seamless or will
there be a jarring gap between loops? Will the player itself be visible
in your Web UI, or will it be invisible and controlled only by you (the
HTML author)? Will the file actually playback instantly, or will it
download, then load in an external player?
All of these, and MANY more issues, are common when attempting to use
standardized media formats on the Web without paying attention to what
actual player you are targetting. In other words, even using a
standardized format you still need to code specifically for certain
players if you expect to control the experience at all. This, to me, is
far more important than what format you use.
So regardless of what format you use, you'd be wise to consider what
players you'll support. For ubiquity's sake, I'd simply target Flash
for your needs -- it's on virtually every system, is lightweight and
well known by developers and users both. It supports MP3 just fine.
Anything more than Flash would be overkill; and if you don't target a
specific player (or players) then different browsers and operating
systems will have difference experiences on this page. May not matter
to your client, who likely has one computer and will never know the
difference, but if he's got friends/family/colleagues with anything
else he'll likely be disappointed about the disparate experiences of
these folks.
Is rudeness common here? If so I will take my questions elsewhere.
You're the first post I've replied to in quite some time; I just
re-subscribed yesterday in fact. I do think the admonishments you got
from the other members were fair, and you shouldn't take it personally
- they are good points.
