multimedia webapplication thoughts and experiments

If you’re creating a new media site, you will need a multimedia player rather sooner than later. There are many options available, the easiest is embedding something that already exists. For instance, if you want to put a movie on your site, you could go for a YouTube embedded player. If you want more options, even interactivity, you need something more flexible. You could do much worse than picking the JW FLV Player.

Before you read on, go ahead and open the example to take a look at what we will create.

The player is actually a Flash applet that you can embed in your page. The neat thing, is that it can be completely controlled from JavaScript. There’s a bunch of information on the website, but it’s not very clear how it all ties together.

First, you need to initialize the player:

1
2
3
4

var so = new SWFObject('jwflvplayer/player-viral.swf','mpl','300','300','9');
so.addParam('allowscriptaccess','always');
so.addParam('allowfullscreen','true');
so.write('player');

This will put a 300×300 sized player in the div-element with id “player”. It won’t load any songs yet. This we will do in a later step. When the player is done loading, it will call the “playerReady” method.

1
2
3
4
5
6

function playerReady(obj) {
    player = document.getElementById(obj.id);
    player.addControllerListener("PLAYLIST", "playlistLoaded");
    player.addModelListener("ERROR", "error");
    player.addModelListener("STATE", "stateChanged");
};

In this method, we initialize a few listeners. One is listening to playlist events (fired when new songs are loaded), another will display error messages and the third is used as an example how to display the state of the player. The JW Player wiki has a full list of all events.

Most of those methods themselves are plain JavaScript, so they are not that interesting, but you can take a look in the source of the example.

The final step to get the player to actually load up a song. It’s as easy as sending a “play” event:

1

player.sendEvent("LOAD", "music/"+event.target.innerHTML);

For all the details, take a closer look at the example.

There are many things still missing, but this should get you started. For instance, the player will only play one song at a time and the viral code is not functional (the embedding). But those will be discusses in further posts. And if you have any questions, feel free to leave them in the comments.

The last hour, I’ve been busy trying to get my site’s markup valid. The frontpage now validates, but there’s till work to be done to the other pages. So after reading Dennis Forbes’ post, I noticed I’ve been running for the past year or so with invalid markup and nobody ever pointed that out. One might rightfully wonder: does it actually matter?

Personally, I think it does and I feel I need to fix the remaining problems as soon as possible. I might even go from the “XHTML transitional” to the “strict” doctype, just for kicks (and other advantages). Not only will good XHTML give a tidy impression to visitors, but it is also one of the most reliable ways to make sure your site looks the same on all browsers and operating systems. And if you go for XHTML instead of HTML is will also be able to use neat stuff like XSL.

In order to get my pages in order (still a work in progress), there were actually only 6 errors that keep repeating. Because I’m running WordPress, it isn’t always easy to find the source. It could be a plugin that inserts some HTML somewhere or part of the header, or was it in the sidebar?

1. If you copy from webpages, make sure you are copying code pieces without layout. The build in TinyMCE editor is great, but if you copy a piece of code from a webpage, it sometimes pickes up HTML codes that you can’t see, but that will mess up your pages. For instance, I had problems with HTML comments (two dashes were copied as one long).
2. Close your tags. This is the most basic rule of them all if you are creating XHTML, but it is very important. It’s easy to write <br> instead of <br/>, but only the last one is correct.
3. Put alt tags on images. And don’t just put in some random piece of text. Try to make it descriptive, because blind people need them to fully enjoy your website. As do people with slow connections (they are still out there)
4. Encode special characters. This is again a XHTML requirement. Probably the most popular special character you’ll run across is the ampersand (&), you should write it as “&amp;” Don’t worry about your blog posts, the build in editor will take care of it. This is just for the templates.
5. Uppercase and lowercase matter. Tag names should all be lower case, so <META …> is not the same as <meta …> Obviously the actual text can be any case you wish.
6. If you give id’s to div’s (or other elements), they should be unique. This is not only a requirements, but if you plan on adding JavaScript to your site, you will save yourself a lot of headaches if you keep this in mind from the start.

If you want to test your own site, you can do so, entirely free of charge, at the W3C Markup Validation Service. Good luck with those tweaks.

Image credit.