Until recently, playing audio required a plugin of some sort. But thanks to the evil geniuses who put together the HTML5 spec we now have a fully fledged Audio element and JavaScript API to play with. With great power comes great responsibility. Apparently. And so before we go on and take a look at how to include (and control!) audio with HTML5 a word of caution.

Most users, sane ones at least, don’t like audio on web pages unless it’s a) part of a video, b) a podcast or c) a music track they’re looking for. Background music, perish the thought, is considered a no-no. And with good reason. Our hapless user might be at work, and your page autoloading Greensleeves might alert his or her boss that they’re not crossing i’s and dotting t’s. Or perhaps our user is listening to Spotify – the last thing they want is your Garage Band mashup competing for their ears.

Enrich Don’t Enrage

I guess there are two main reasons you’d want to include audio on your site. The first is because it’s something the user wants to listen to; perhaps a podcast, or a preview of your latest song. The second is because the audio is part of the user experience. You may have added background music to a page on your site, or even sound effects hooked into buttons and other elements. Most Flash websites come with some form of audio enrichment and with the wonderful HTML5 spec, a pinch of CSS3 and a spoonful of JavaScript you can have a Flash-esque website in a standards compliant way.

Do not underestimate the power audio can have on a user experience. Great audio can lift a site into the echelons of brilliance and, done well, it is arguably more powerful than visual design in creating an emotional experience (did anyone ever see the Donnie Darko website?). Bad audio will ruin a website and you won’t see your visitors again. Ever.

The Basics

As with most of the HTML5 spec, including audio on your page is remarkably simple (and very similar to including video which you can read about in a previous post).

<audio src=”mynewtrack.mp3”></audio>

Yup. That’s it. There are a number of additional attributes we can add to spice things up. For example:

<audio src=”mynewtrack.mp3” loop controls autoplay preload></audio>

You can add any or all of these attributes. ‘Loop’ loops the track. ‘Controls’ adds the browsers native controls (see below) and ‘autoplay’ is a one-way ticket to eternal damnation.

Safari 5

Chrome 6

Opera 10.6

Firefox 3.6

Internet Explorer 9

Preload has three possible incarnations. ‘Preload’ will ask the the browser to preload the track. Note that it asks rather than demands. This is because the browser knows best; a mobile browser or a browser on a slow internet connection may decide to ignore the request. ‘Preload = none’ is self explanatory. ‘Preload = metadata’ tells the browser to grab all the meta data from the file like the track name or duration which may come in handy when constructing your audio player. The track itself won’t start to download until the user activates one of the controls.

The Continued Curse of Codecs

Of course it’s not really that simple. The problem with mp3s, as ubiquitous as they’ve become, is that encoding and decoding them is subject to patents and therefore costs. And so whilst some browser vendors can afford to support this technology, others cannot.

Enter .ogg, sibling of .ogv which you may have come across when encoding video files. The Vorbis codec which is used to create .ogg files is not subject to any patents and therefore free to use – this is probably why browsers like Opera and Firefox support it.

To make sure you cover all bases, it’s useful to have fallback audio files which you can include like so:

<audio controls>
  <source src="mynewtrack.ogg" type="audio/ogg" />
  <source src="mynewtrack.mp3" type="audio/mpeg" />
  <!-- You could even put a Flash fallback here -->
</audio>

Here the browser will try to load the .ogg file, and if that fails it will try the .mp3 file. If all else fails you could include a Flash movie with the audio too.

Creating OGG and mp3 Files

Fortunately there are a number of ways to encode your tracks which won’t cost you a penny or a cent. For both Mac and PC users there is Audacity, a free digital audio editor which allows you to save files as both .mp3 and .ogg. You can download Audacity from http://audacity.sourceforge.net/.

If you’re using a Mac I recommend Switch. You can download a free trial from http://www.apple.com/downloads/macosx/audio/switchaudioconverter.html.

Switch is a sound file converter which covers a multitude of file formats. It’s clean interface is easy to use but make sure you’re connected to the internet the first time you encode a file as it downloads codecs on demand. Still, once you’ve downloaded the mp3 and ogg codecs you’re good to go.

If you’re on a PC and Audacity isn’t for you, check out the list of software over at Vorbis.com.

Controlling the Controls

What we’ve learnt so far is good enough to include audio on the page but we might want a little more control, and for that we need to dip into the JavaScript API.

I’ve created a basic music player which you can check out over at http://www.richardshepherd.com/tv/audio/ . You can view the source HTML and CSS to see how it’s put together, but here’s the basic HTML:

<div id="player">
 
 <input type="button" value="Play" id="play" />
 <input type="button" value="Pause" id="pause" />
 <input type="button" value="Stop" id="stop" />
 
 <span id="timecode"></span>
 <span id="progressContainer">
   <span id="timecode"></span>
   <span id="progress"></span>
 </span>
 
</div>

All we need to do now is attach audio events to my elements which we can do using the new Audio API and a wee bit of jQuery.

First we create a new audio object and point it at the right file:

var music = new Audio(mynewtrack.ogg);

Then we hook an audio play action of the play button in the HTML with some jQuery:

$('#play').click(function(){
  music.play();
});

We can do exactly the same with the pause button.

$('#pause').click(function(){
  music.pause();
});

Now let’s do something a bit tricky and create a progress bar which will move as we listen to the track.

All we need to know is the total duration of the track and where the imaginary playhead currently is.

// Display our progress bar
music.addEventListener('timeupdate', function(){
 
  // How long is the track in seconds
  var length = music.duration;
 
  // Whereabouts are we in the track
  var secs = music.currentTime;
 
  // How far through the track are we as a percentage
  var progress = (secs / length) * 100;
 
  // Change the width of the progress bar
  $('#progress').css({'width' : progress * 2});
 
  // And finally calculate where we are in the track
  var tcMins = parseInt(secs/60);
  var tcSecs = parseInt(secs - (tcMins * 60));
 
  // If the number of seconds is less than 10, add a '0'
  if (tcSecs < 10) { tcSecs = '0' + tcSecs; }
 
  // Display the time
  $('#timecode').html(tcMins + ':' + tcSecs);
 
}, false);

The first thing we do is add an event listener which looks for the timeupdate event; once we know the music is playing (and so the time is updating) we can work out where we are in the song.

Next we need to find out how long the track is with music.duration and whereabouts in the track we are with music.currentTime. That’s really all the Audio API we’ll be using – the rest is vanilla JavaScript and jQuery.

Some pretty basic maths will then give us the percentage we are through the track, and then we can use CSS to alter the width of the progress bar. Finally I also put the time in minutes and seconds onto the page.

This is what it will look like:

Turn it Up

For those of you who are familiar with HTML5 forms you may recall the range slider. Well, turns out we could use one of these for a volume control!

<input id="volumeSlider" type="range" min="0" max="10" value="8" />

We just need to add in a little jQuery:

// Take care of the volume slider
$('#volumeSlider').change(function(){
  // Set the music volume based on the slider’s position
  music.volume = $(this).val() / 10;
});

And there you have it – a perfectly respectable music player thanks to HTML5.

More from the JavaScript API

As well as play, pause and volume there are bunch of other JavaScript attributes and methods we can call upon. Here are a few:

• autoplay
• buffered
• currentTime
• duration
• ended
• error
• loop
• paused
• played
• startTime
• seekable
• preload

You can see a comprehensive list at http://www.w3.org/TR/html5/video.html#audio.

Note the difference between the methods play() and pause() versus the events play and pause. A method is something you do to the audio file, whilst the event is something you can listen for and attach events to.

Sounds Good

So there we have it – a run through of the exciting new Audio element in HTML5. I don’t think it’s an element that you’ll use a great deal, and like HTML5 video browser support remains a little sketchy. However it’s another exciting development for web professionals and as with all new technologies it’s great to get in on the ground floor and watch it flourish.

Further Reading

For an in-depth look at how to create a live streaming radio player, check out the great tutorial at http://dev.opera.com/articles/view/html5-audio-radio-player/

Here are some more interesting links:

• http://dev.opera.com/articles/view/everything-you-need-to-know-about-html5-video-and-audio/
• https://developer.mozilla.org/En/Using_audio_and_video_in_Firefox
• http://www.apple.com/html5/showcase/audio/
• https://wiki.mozilla.org/Audio_Data_API

Or perhaps you hacked together a cgi script or even some PHP. But when that first email arrived with the subject line ‘test’ you realised that your website had now become interactive. You could now not only interact with your users, but also tailor your site based on their input.

Long Live Forms

Years later forms are still the primary way our users can interact with us, more than just clicking on links or triggering JavaScript events. Indeed, it’s likely the first thing you do when you start up your favourite browser is type a search query into a form.

Forms and form elements, as they appeared in the HTML4 spec, were utilitarian but hardly elegant. So we got smart. We enlisted our ever loyal friend JavaScript to lift forms to new heights, create new types of interaction, and give the user instant feedback and support.

Feature Rich Forms

With a combination of server-side scripting and AJAX we now have feature-rich forms, but all at the expense of programming complexity. Funny thing is, we’re now so used to this sort of code that what is about to happen almost seems too simple.

Inevitably, as is the case with much of the HTML5 spec, HTML has now caught up with the needs of web designers and developers by providing a remarkably simple way of creating usable and even extensible forms.

Email Sign-up Form Demo

I’ve created a demo of an email sign-up form you can check out at http://richardshepherd.com/tv/forms/.

Each form field uses something from the HTML5 spec and we’ll run through it one step at a time. When I refer to a browser supporting a particular feature, I mean the very latest stable release of that browser which you can download from the relevant vendor website.

Of course, when dealing with anything HTML5 related (like our previous post on HTML5 video) there is a huge browser caveat – some browsers support all some or none of what we’re about to discuss. And it’s changing really fast.

Your best bet at the moment is to use Opera, Chrome or mobile Safari, although we’ll look at browser support a little later on (together with a piece of JavaScript which helps test for certain features).

A Place for Everything

Feature: Placeholder text
Browsers: Chrome, Safari, Firefox 4

I think most of us have played with JavaScript enough to have placeholder text appear and disappear in a form field. You know, it’s normally light grey text which hints at what should be typed in the form field, and once the form field is selected it disappears. Then, when the cursor leaves the form field a check is made, if the field is still empty then redisplay the placeholder text. Such an intuitive thing sounds convoluted when typed out like that, and it needs a few lines of JavaScript to make it happen. But not any more.

Let’s start with the first name. Here’s the code:

<input name="firstName" placeholder="First Name" required />

Wow! Seriously, go ahead and test it. Isn’t it beautiful?! Simple yes, but also elegant and highly usable. It does exactly what we need it to do, and doesn’t need to get any more complicated than that.

But hold on a second, there’s no sign of type=”text”. Well in the good old world of HTML5 inputs default to text unless otherwise specified; likewise forms methods default to GET unless specified.

No Jacket Required

Feature: Required form fields
Browsers: Opera, Firefox 4

We have all relied on Javascript to validate a form at some point or another. It’s no substitute for good server-side validation (particularly when it comes to security) but it is an excellent way of providing the user instant feedback on their input. One of the many things we validate is that a user has entered data for a required field and this is now something we can do with HTML5!

Here’s what it looks like:

<input id="lastName" type="text" name="lastName" placeholder="Last Name" required />

One of the currently under-supported features of HTML5 forms, adding the required keyword allows browsers to validate the form on the client-side much like Javascript can. And until the feature is universally adopted you can future-proof your document by using Javascript to check for the ‘required’ attribute rather than a particular class or name.

Here’s how Opera renders an error on a required field:

When used with type=”email”, the required field can even validate an email address:

You might also notice that the validation is also affecting the border colour. Required elements start off red, and when you type something into them it changes to green. As you move onto the next field it then changes to grey – the default colour.

The same is true of email validation – the email field won’t turn green until you’ve entered a valid email address. This is a nice touch, and it’s added with some simple CSS pseudo-selectors:

input { border: 2px solid #999; }
input:focus { border: 2px solid #6C6; }
input:invalid { border: 2px solid #F00; }

Getting More Specific

Feature: Email, Web & Phone fields
Browsers: Safari for iPhones

First let’s take a look at the code:

<input id="emailaddress" type="email" name="emailaddress" placeholder="anything@example.com" required />

All this is doing is telling the browser what type of data to expect which, at this point, is not really of any benefit unless you’re using mobile Safari, probably on your iPhone. Because what Safari can do is change the keyboard layout depending on the type of data that is being inputted.

For example, in an email field it handily offers the @ symbol in the touch screen keypad. If you change the type from email to ‘phone’ or ‘website’, mobile Safari changes the keyboard further. With more and more of us accessing the web through mobile devices this type of behaviour is only going to become more prevalent.

It’s a Date!

Feature: Date Picker
Browsers: Opera

This is another example of where custom built widgets may eventually be replaced by browser controls. A date selector is such a useful piece of kit and it’s great to see browser vendors slowly adopt this.

At the moment there is very little control over the date picker but I’m sure that will change of the coming months and years. Imagine, a browser based date picker that you can style with CSS. Perfect!

Here’s the code:

<input id="birthday" name="birthday" type="date" />

And here’s what it looks like in Opera 10.62:

Now some have commented that this Opera date-picker is far from attractive, but it does serve it’s purpose and it’s a HUGE step in the right direction. There are even some variations on a theme. The above code generates a standard date picker (day, month, year) but we can be more specific:

<input type="datetime" />
<input type="datetime-local" />
<input type="time" />
<input type="week" />
<input type="month" />

Datalist – A list of Data

Feature: Datalist
Browsers: Opera

Whilst not quite an auto-suggest feature, datalists allow us to present the user with a range of options to use in a text input box. This is best used when there aren’t too many options, because with no filter applied to the list as you type it doesn’t get any shorter the more characters you input.

Whilst I don’t think you could list every country in the world (as the list would fall off the bottom of the page) you might want to include a few of the more popular ones like so:

<input id="country" type="text" name="country"  size="40" list="countries" />
 <datalist id="countries">
  <option value="Australia">
  <option value="Canada">
  <option value="Germany">
  <option value="France">
  <option value="United Kingdom">
  <option value="United States">
 </datalist>

(Forgive me if your country is not on that list – it doesn’t mean it isn’t ‘popular’!)

Whilst perhaps not a replacement for a good JavaScript based auto-suggest tool, it is still a useful enhancement to a normal text field. And like most of the HTML5 form elements, it’s easy to implement and greatly adds to user experience.

NB. When testing this code I found that including a Datalist input broke the page in Safari (5.0.2, Mac); it simply stopped rendering the page when it reached the list. It doesn’t seem to have this effect in any other browser.

Forms by Numbers

Feature: Numbers
Browsers: Opera, Chrome, iPhone

The final feature we’re going to take a look at are numbers. By simply specifying an input type as ‘number’ you have access to ‘Increase’ and ‘Decrease’ buttons which allow the user to input whole integers. You will probably see these input types referred to as ‘spinners’ or a ‘spinbox’.

On the iPhone the touch keyboard changes to one that is number-friendly.

As ever the code is easy and very readable:

<input id="computers" name="computers" type="number" min="0" max ="100" step="1" value="2" />

The min, max, step and value attributes are optional.

Again, I believe using this sort of control needs some thought as no-one  will want to click the button eighty-four times just to enter the number 84, they’ll simply type it in. However for smaller numbers and for altering numbers it’s a useful addition to the web designers arsenal.

But wait, There’s More!

In this article I’ve included what I think are the most interesting and practical additions to HTML forms, but there are others in the HTML5 spec which you might want to check out. They include:

• Autofocus
• Range (sliders)
• Color

Go ahead and check them out – you might find one of them useful.

Falling Back

The great thing about many of these HTML5 form enhancements is that they will degrade gracefully to standard input boxes. However some don’t play nice at all, even with so-called ‘modern’ browsers.

The date picker, for example, can behave in odd and unusual ways. In Opera it works just fine but in Chrome there is simply an option to increase and decrease a date by one day – starting in 1582!!

This is far from helpful and I’d argue a complete #usabilityfail. So how can we serve Opera the date picker and Chrome something else? Our old friend JavaScript, that’s how.

Before we go on to look at the code it’s also worth remembering that not everyone has JavaScript installed. Unfortunately for those users the form may malfunction or even stop the rest of the page loading (see Datalists, above).

Only you can decide how far you want to push the envelope in these fledgling days for HTML5 forms. For personal projects I urge you to heed the words of Salt ‘N’ Peppa, and “push it, p-p-push it real good”.

JavaScript to the Rescue!

With JavaScript we can check to see if a browser supports a particular attribute like type=”number”, and take action based on the result.

I first saw this code suggested by Jeremy Keith in his excellent book ‘HTML5 For Web Designers’ (which I encourage you all to buy):

function checkAttribute(element, attribute) {
 var test = document.createElement(element);
 if (attribute in test) {
   return true;
  } else {
   return false;
  }
}

You can then check to see if a browser supports a particular feature with something like:

if (!checkAttribute('input', 'placeholder')) {
// No support for placeholders, so add them with JS
}

A Word on Modernizr

Another way to check if a browser supports a particular element is by using the funky Modernizr script. This handy utility, when included in a page, adds a bunch of classes to the <body> tag that indicates which features are available. A wave of the JavaScript magic wand and you can decide exactly what can and can’t be used on the page.

A typical Modernizr script might look like this:

if (Modernizr.input.date) {
  // This browser supports date inputs. Hurrah!
} else {
  // Oh dear. Time to include your own
  // JavaScript date solution...
}

Wrapping it All Up

So there you have it – a run through of some of the more useful and supported additions that HTML5 brings to our forms. I hope you can see the potential in some of them for your site and, as with all shiny new toys, I encourage you to play with them on personal projects but use sparingly on commercial outings. At least for now.

The additions to the HTML5 spec are direct responses to how we use the web in the real world, which is what makes them so effective. I’m not sure we’ll ever turn our backs on JavaScript when it comes to validating and controlling forms but usable, elegant form design is about to get a whole lot easier!

Further Reading

If you’re looking for more “input” that’s “on form” then “submit” yourself to these great articles:

• http://www.w3.org/TR/html5/forms.html#the-form-element
• http://www.miketaylr.com/code/input-type-attr.html
• http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)
• http://www.opera.com/docs/specs/presto26/html5/
• http://24ways.org/2009/have-a-field-day-with-html5-forms
• http://net.tutsplus.com/tutorials/html-css-techniques/rethinking-forms-in-html5/

Have you tried out HTML5 forms yet? What do you think? We’d love to know!

As Wired reported back in March Twitter’s Evan Williams promised @Anywhere would “reduce friction.”

“You could be reading your favourite columnist [and] you can easily tweet from the column itself if […] you may just want to follow the columnist […] without going back to Twitter.”

Amongst the launch partners for @Anywhere were Digg, Huffington Post and The New York Times. And one of the most high profile users the little known Follow Finder from The Mighty Google.

But alas, it was more a fizzle than a firework and like many at the time I was rather nonplussed.

I’m pleased to say I’ve been completely converted. Not only is playing with Twitter inherently a cool thing to do, it can add real power to your website and more importantly your web applications. Indeed, it’s the scope for easily including Twitter functionality in web applications that’s really exciting.

So let’s take a look at some of this functionality and how you can use it. You’ll be up and running in just minutes, and after briefly looking at some of the simpler methods we’ll dive straight in to integrating Twitter right into your web app.

Registering for @Anywhere

The first thing you need to do is register for an Application ID. It’s ridiculously simply to get, but perhaps worth some explaining to the uninitiated. First head on over to http://dev.twitter.com/anywhere and click on the ‘Start using it now’ button.

You’ll be swiftly taken to a one-page form where you register your app. The first question, particularly to those new at this whole API game, is ‘what if I don’t have an app?’.

Let’s say you just want to use hovercards on your blog. Or let’s say you want your users to be able to tweet about your blog articles by providing them a tweet box at the footer of each page. Not really an ‘app’ is it? More of a feature, a widget perhaps.

Well, in the big wide world of APIs what you have is a web app my friend and you need to accept it! Even the humble ‘Linkify’ method (automatically turning all Twitter usernames into links to their profiles) makes your humble blog post a web application of sorts. Deal with this fuzzy distinction and move on. We need that app ID!!

NB: For the rest of this article I’ll use the term app/application, but it equally applies to your site/blog

Completing the Form

Application Name

Name your application wisely because users will see this name when they are asked to authorise your app; although it’s worth noting that certain functionality, like linkifying and hovercards, doesn’t require users to see this name.

Callback URL

If you intend to use some of the @Anywhere functionality which requires users to authenticate your app then Twitter needs to know which page to send the API response to (which includes lots of handy data about the user that we can tap into using JavaScript!). The callback URL is most likely the very same page that has called the authentication.

If you’re only using simple @Anywhere methods like linkify you can just put your site’s homepage in here.

Default Access Type

This defaults to Read-only, but we want to use some advanced @Anywhere methods so make sure you change this to Read & Write.

Basic functions

Okay, we’ve filled up this car with petrol/gas so it’s time to take it out for a spin! Open a new HTML document and in the <head> of the document include the following line of code:

1

<script src="http://platform.twitter.com/anywhere.js?id=YOUR-APP-ID-GOES-HERE&v=1"></script>

Don’t forget to add your app ID into the URL.

Before I go on I feel I must address those of you who now resemble Yosamite Sam, with steam coming out of their ears at the idea of ever including a JavaScript file at the top of a page. But including the anywhere.js file in the head makes a lot of sense for a number of reasons, outlined by Twitter themselves:

• It’s small. Less than 3kb to be exact, gzipped up into a tiny package.
• All dependencies for @Anywhere features are loaded asynchronously, so you only get what you need when you need it.
• Most importantly, when a user logs in and authenticates your app the Twitter login page redirects back to the callback URL. This happens in a pop-up window, so if anywhere.js is at the bottom of the page it’ll mean that the user sees your site in that pop-up before it disappears. Which looks bad and, as Twitter put it, ‘is a poor user experience’.

So leave it in the <head> and let’s move on. Now we need to initialise the a global @Anywhere object which we do with:

1
2
3

<script>
twttr.anywhere();
</script>

For those who have tried to run that script, you’ll see that nothing happens. That’s because we need to give it a callback function of some sort. For example, to linkify every Twitter username on a page you simply need:

1
2
3
4
5

<script>
twttr.anywhere(function(T) {
T.linkifyUsers();
});
</script>

What’s with the capital ‘T’? Well that’s just Twitter’s convention so we’ll stick with it, but you’re welcome to change it to a more descriptive name. An instance of the API client is passed into T for us to then call methods on, just as we’ve done above.

Run that puppy on a page which has a username in the markup and watch it magically turn into a link. It was roughly about now that I gave up on @Anywhere earlier this year, but stick with me here – it get’s better.

Hovercards

Another method that works in a similar way is Hovercards, which work in the same way.

1
2
3
4
5

<script>
twttr.anywhere(function(T) {
T.hovercards();
});
</script>

With linkifying and hovercarding under our belts its worth looking at another couple of handy features.

Scope

You can limit the scope of a method by passing in a CSS selector. A lot of you will spot that this looks a lot like jQuery and that’s because it’s using the same Sizzle selection engine.

For example, to linkify usernames only in the DIV with an ID of ‘sidebar’ you could use the following code

1
2
3
4
5

<script>
twttr.anywhere(function(T) {
T(‘#sidebar’).linkifyUsers();
});
</script>

Configuration Options

There are a number of option that we can pass to these methods, which we do in an object literal. Again, if you’ve used jQuery before then this will be nothing new to you:

1
2
3
4
5

<script>
twttr.anywhere(function(T) {
T(‘#sidebar’).hovercards({ expanded: true});
});
</script>

Adding {expanded: true} does exactly what it says – it renders the Hovercard in it’s expanded form from the off, rather than waiting for the user to click ‘more’.

Moving Swiftly On

I’m going to skip a bit here, which relates to some of the other configuration options you can use with the various “Anywhere methods. I highly recommend Twitter’s own documentation which you can find at http://dev.twitter.com/anywhere/begin.

Getting more Advanced

If you’ve spent much time surfing the interweb you’ve at some point seen that pop-up window asking you if you authorise an app or a site to play with your Twitter account.

If, like me, you blindly click yes you give that site direct access to lots of your personal (albeit public) information. Normally this isn’t a problem, but with great power comes great responsibility – as James Cunningham of Twifficiency fame (more at TechCrunch).

There are a couple of ways @Anywhere uses this connectivity. The first is with built in functions like the Tweet Box and the Follow button. Both need the user to login to Twitter and authorise your app, so both will cause the authorisation pop-up. We can call both like so:

1
2
3
4
5
6

<script>
twttr.anywhere(function(T) {
T('#follow-button').followButton("richardshepherd");
T('#tweet-box').tweetBox();
});
</script>

This places a follow button in the element with an ID of ‘follow-button’ (and which is set to follow my Twitter account!), and a tweetbox in the element with an ID of ‘tweet-box’.

You’ll can find further details of the Tweet Box and Follow Buttons in the official documentation, but I think it get’s much more exciting to look at connecting your app with someone’s Twitter account and pulling information from their public profile. So let’s go ahead and crank things up! It’s surprisingly simple.

1
2
3
4
5

<script>
twttr.anywhere(function(T) {
T(‘#connect’).connectButton({ size: “medium” });
});
</script>

And that’s it. Try it out, and you’ll see the familiar pop-up asking for you to authorise your app (the name you gave it when you signed up). You can change the size be replacing ‘medium’ with ‘small’, ‘large’ or ‘xlarge’.

Medium is the default, so if you’re happy with that you can remove it from the code. But how about your own custom connect button – how cool would that be? It turns out that the Twitter API has a signIn method which we can attach to any element: text, image or whatever you fancy.

Let’s say you have created your own CSS rollover button, applied to a span with and ID of twitterLogin. Here’s how you’d use JavaScript and the Twitter API to hook the signIn method to that span:

1
2
3
4
5
6
7

<script>
twttr.anywhere(function(T) {
document.getElementById(‘twitterLogin’).onclick = function() {
T.signIn();
}
});
</script>

We are now freed from the shackles of Twitter’s own graphics and buttons, which makes it possible to create a unique experience for your own app or site. If the user is logged in, the pop-up window will simply ask them to authorise your app. If they aren’t logged in to Twitter it will also ask them for their login details.

I Can Haz your Details?

So your web app now has a connect button, and let’s assume your user has clicked it and logged in/authorised your app. Sweet. What next?

You should have set the Twitter callback URL to the same page as your web app, which means the pop-up will disappear and your page will be sent a bunch of new data (think of it as an AJAX request and response). This means you can use Javascript to check if the user is connected with the rather handy isConnected method. And, assuming it’s all gone to plan, the currentUser property contains lots of handy information.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<script>
twttr.anywhere(function(T) {
if (T.isConnected()) {
// This user is connected. Awesome!
var user = T.currentUser;
var screenName = user.data(‘screen_name’);
alert(‘Hi there ‘ + screenName);
} else {
// the user isn’t connected, so probably best to show them
// a connect button!
T(‘#twitterLogin’).connectButton();
}
});
</script>

Admittedly the use of a JavaScript alert here is almost criminal, but you get the idea. Include jQuery and you can start injecting the DOM with lots of Twitter goodness, personalising the user’s experience.

So what other properties can we access, apart from Screen Name? Well, pretty much all of the user’s public profile information is up for grabs. Here are some of the most useful:

• description
• followers_count
• following
• profile_image_url
• location
• name
• time_zone

And you can check out a full like at http://dev.twitter.com/anywhere/begin#user-properties

So using our example above you could access the profile image with:

1

var imageHTML = ‘<img src=”’ + user.data(‘profile_image_url’) + ‘“ />’;

What Next?

Of course @Anywhere is no substitute for server side integration with the Twitter API, but it’s a lean way of enhancing your web app/web sites experience for Twitter users.

Have you started to use @Anywhere? If so, tell us how and whether you think it’s enhanced your web application or site. And which features would you like to see in @Anywhere in future releases?

Further reading

Have you been bitten by the @Anywhere bug? If so, here are some great places to find out more…

• http://www.slideshare.net/toddkloots/anywhere/
• http://platform.twitter.com/js-api.html

I also really like this integration of Twitter Hovercards into a WordPress blog comments

• http://www.binarymoon.co.uk/2010/05/integrate-twitters-wordpress-comments/

Perhaps not divisive in the web community, most designers and developers seem to love the idea of it, but certainly divisive in the real world of cross browser support, licensing and (dare we even mention it) Adobe Flash.

HTML5 Video in Safari with native browser controls

Let’s start at the end. Internet Explorer 9 promises to support WebM video, one of the three main contenders to the HTML5 video throne, but from IE8 backwards you’re out of luck. In short, you need to use Flash. The same is true of all but the most recent versions of other major browsers, which of course poses a very relevant question.

Why Use HTML5 Video at All?

It’s a great question and, as I’ve mentioned, a divisive one. There are myriad reasons why and we’ll go on and look at a few of them. But if your users follow the usual browsing trend the chances are they won’t be able to see the video and you’ll need a fallback to Flash.

Even when IE9 makes it’s debut to the masses there will still be a legion of IE8, IE7 and IE6 users, together with other older browsers, that will need you to keep dipping your toe in Adobe’s pool.

I need to add a caveat to this article. I live in the real world and I work on a site with millions of real users. The vast majority of these users have browsers that don’t support HTML5 video and I expect that’s the same for many of your sites too. As much as we want everyone to use Chrome on OSX it’s not going to happen so you will need to create a Flash fallback for the foreseeable future. I’m talking years here, not months.

There are some other problems with HTML5. There are three major camps emerging each championing a different video codec (a way to compress and decompress video files). As of writing there are some content protection issues (digital rights management) and some features, like full-screen video and native keyboard support, have yet to be fully fleshed out.

So Why Bother?

I think any good web practitioner is a pioneer, always seeking out new technologies and techniques to bring colour and life to their site. If you’ve got this far then you’re one of those people.

HTML5 video promises a wonderful environment to create unique video experiences, styled with CSS and controlled with JavaScript. A HTML5 video is just another element in the DOM which we can read and write to, and this allows us far more customisation on-the-fly than Flash ever could. It’s accessible, it’s standards compliant, and above all it’s simple.

YouTube are already delivering some HTML5 videos, and Vimeo have hopped on the bandwagon too. More and more sites are offering up the format, experimenting with it, and creating new and exciting ways to use video on their site. Check out the links at the end of this article for more places to check it out – just not with IE ;)

The YouTube HTML5 Video Player

Need More Reasons?

DOM, Meet Video

They’ve been flirting for some time now but finally the DOM and video can make it official and head out on a date. You can position, float and z-index video till dawn, indeed anything you can do to a div you can do to a video element. No more of those pesky plugins that make Flash elements disappear if you have lightboxes – HTML5 video will play nice with the rest of the kids and, more importantly, be under your complete control thanks to JavaScript.

Video, Meet CSS

It doesn’t end there. As a DOM element HTML5 video can be styled. And since the only browsers that support it also support CSS3, in some form or another, it means you can add (webkit) transitions, box shadows, hover effects and all kinds of stylesheet goodness to make your video blend seamlessly into your page.

Keyboard, meet Video

Although only currently supported by Opera, all browsers will soon support keyboard accessibility of videos without any additional code. As Bruce Lawson has noted it’s almost impossible to TAB in and out of a Flash video, which is a real problem for those users without assistive browsing technology.

Add these new features together, throw in a dizzy helping of JavaScript, and you just know that someone, somewhere will create a HTML5 video editor.

Using HTML5 Video on your Site

In days of old when Knights were bold the interweb got all confused about anything that wasn’t text. Netscape and Mosaic decreed that images should be tagged up as <img> which, to be fair, makes some sense. But the W3C didn’t approve and they introduced the <object> tag. As the saying goes “you snooze, you lose” – the web had already adopted the Netscape/Mosaic method.

Then things got really strange. When the forerunner to Flash hit the web the W3C again suggested the object element but Netscape went ahead and created the <embed> element, which the W3C refused to validate. The resulting confusion gave us the wonderful markup-soup that is Flash video.

1

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="100" height="100" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowFullScreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="src" value="http://www.youtube.com/v/Sv5iEK-IEzw?fs=1&amp;hl=en_GB" /><param name="allowfullscreen" value="true" /><embed type="application/x-shockwave-flash" width="100" height="100" src="http://www.youtube.com/v/Sv5iEK-IEzw?fs=1&amp;hl=en_GB" allowscriptaccess="always" allowfullscreen="true"></embed></object>

Without whining about the aesthetics of that, wouldn’t it be nice if we could simplify it to just: <video src=”myVideo.ogv”></video>

Surely it’s not that simple? Well sorry to disappoint you but it is. In fact, because it’s HTML5 the quotes are optional too so it’s two characters longer than it needs to be. I’m not even going to insult you by explaining that code.

But how about we give this baby some shizzle?

1

<video src=myvideo.ogv width=640 height=480 controls poster=myImage.jpg></video>

I think the only two things I need to explain here are controls, a boolean which displays the browsers native controls, and poster which is an image to display whilst the video is downloading. If you only specify one size attribute, the video will automatically resize the other maintaining the video’s aspect ratio.

There are other attributes we can throw in but as yet there is limited cross browser support for them. They include loop, autoplay, and autobuffer.

Need a fallback for those browsers that don’t support HTML5 video? That’s easy too:

1
2
3

<video src=myvideo.ogv width=640 height=480 controls poster=myImage.jpg>
<a href=myvideo.ogv>Download this video.</a>
</video>

Codecs and Acronyms

Of course this does pose the question, what on earth is an .ogv file? Well until fairly recently it was a fairly obscure video file. It gets worse it’s not the only one and it won’t work in all browsers.

Yep, cross-browser compatibility rears it’s ugly head once more. There are (currently) three codecs we need to worry about the main reason seems to be browser vendor’s personal preference and their aversion to using patented technology. Take our old friend the .mp4 file, which is familiar to anyone with an Apple device. MP4 files are created with the H.264 (MPEG-4 AVC) codec and there are licensing issues a-plenty surrounding it, which is probably why only Apple (Safari) and Google (Chrome) are supporting it.

Partly because of this we are seeing the rise of two comparative new-comers to the video field – Theora and VP8. I’ll try to keep this brief – Theora is royalty-free and therefore can be used in any form without a problem. You’ll most often see .ogv files for videos encoded with this codec. It’s best friend is Vorbis audio (.ogg files), similarly royalty free. Browsers that support this type of video include Firefox, Chrome and Opera.

VP8 (stay with me, we’re nearly done with this) came from On2 (the same company behind VP3 which then became Theora). On2 was bought by Google earlier this year who then waved a legal magic wand and made the technology royalty-free. It’s more complicated than that, but I’m not a lawyer, suffice it to say anyone can use it. The VP8 codec creates .webm video files.

That Last Bit Bored Me

Me too, but it’s important and I encourage you to read a little more on these codecs and the implications of using them.

Here’s a summary of which browsers support what:

• Theora (.ogv files) – Firefox 3.5+, Chrome 5.0+, Opera 10.5+
• H.264 (.mp4 files) – Safari 3.0+, Chrome 5.0+, iPhone 3.0+, Android 2.0+
• WebM (.webm files) – Internet Explorer 9 (yay!), Firefox 4.0+, Chrome 6.0+, Opera 11.0+

NB. The file extensions I’ve noted here are the most often used but you can encode videos of different types with different extensions – most of us needn’t worry too much about that though.

For an in-depth look at the dizzy world of video and audio codecs as they relate to HTML5, check out Mark Pilgrim’s fantastic article.

A Real World Example – It’s Easier Than it Seems!

Let’s return to the real world of digital camcorders and basic video editors like iMovie and Windows Movie Maker. Go ahead and record, edit and output your movie as normal. Now, head on over to http://www.mirovideoconverter.com/ and download the Miro Video Converter.

The Miro converter will encode .ogv, .mp4 and .webm in it’s sleep, so create your three versions. Three versions seems like overkill but for now it’s the only way we can support those browsers that support HTML5 video. Strictly speaking you could forego the .webm file until IE9 is released.

And finally, here’s the code we’ll use:

1
2
3
4
5
6
7

<video width=640 height=480 controls poster=myImage.jpg id=videocontent>
<source src=myvideo.ogv type=video/ogg>
<source src=myvideo.mp4 type=video/mp4>
<source src=myvideo.webm type=video/webm>
<!-- You can even put your flash video code here as a fallback for internet explorer users -->
<a href=myvideo.mp4>Download this video.</a>
</video>

And there you have it, all three major formats supported. Head over into your stylesheet and apply some lovely CSS3 effects to #videocontent. Of course the video element can have any ID or class name you like.

Further reading

As you can probably tell HTML5 video is a huge topic and at the same time relatively easy to implement. You can keep it as simple as the code above so you can delve deeper into the world of codecs and licensing. In case you feel the need to find out more, here are some of the sites I used to put together this article.

• http://www.webmproject.org/
• http://www.vorbis.com/
• http://mpeg.chiariglione.org/
• http://www.getmiro.com/
• http://dev.opera.com/articles/view/introduction-html5-video/
• http://diveintohtml5.org/video.html
• http://www.youtube.com/html5
• http://vimeo.com/blog:268
• http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video
• http://my.opera.com/core/blog/2010/03/03/everything-you-need-to-know-about-html5-video-and-audio-2

So what do you think? Will you be using HTML5 video on your site soon or will you stick with good ole Flash?

We look forward to hearing your comments and seeing how you implement HTML5 videos on your sites with JavaScript and CSS fun and trickery!

That was then. Now, at (long) last, we are able to give some of this control back to the client. Or, if you’re using WordPress for your own site, you’re able to take control of your menu system with a wonderful new drag-and-drop GUI rather than diving into the code.

New Menu System

The menu system is based on WooNavigation, a custom menu system used by the ubiquitous WooThemes in the latest versions of their custom framework. Although much of the code was rewritten for WordPress 3, the similarities are still clear.

Adii Pienaar from WooThemes recently told me:

“The new menu system that WooThemes contributed is firstly long overdue and is a massive benefit to every single WordPress user. In essence, this is such a basic feature of any CMS, but due to it being a benefit to all WP users, I think this is a significant new addition.”

Chris Coyier from CSS Tricks agrees:

“Personally I think this is a big step forward because, together with Custom Post Types, it is migrating WordPress towards a fully fledged CMS. The more power we can give the end user, the easier it is for developers and designers with an understanding of PHP to use WordPress as a content management solution.”

So, without further ado, let’s take a look at how it all works. Grab yourself a WordPress 3 install with a bunch of pages and a refreshing beverage. It’s thirsty work.

Activating a Custom Menu

If you’re using WordPress 3 with the (brand new) default Theme TwentyTen installed this next bit won’t apply, because it’s already set up to use custom menus, so let’s assume you’re working with an older theme or perhaps even building your own. When you log into WordPress, go to Appearance > Menus.

If your current theme doesn’t support custom menus you’ll see this error message:

This means we need to head over to functions.php and get our hands a little dirty with some code. Open up functions.php and add in the following code:

add_action('init', 'register_custom_menu');
 
function register_custom_menu() {
register_nav_menu('custom_menu', __('Custom Menu'));
}

register_nav_menu has two parameters here, the first is the slug we’ll use in our code and the second is the name our menu will have in the WordPress admin area.

Now before we head back over to the menu screen, let’s stay in the source code and tell WordPress wear to put this menu. The most likely place will be in header.php, but of course there is no reason you can’t put a menu anywhere on your page. To keep things simple for our first menu let’s open header.php and, at whatever point makes sense in your theme, add the following line:

<?php wp_nav_menu(array('menu' => 'custom_menu')); ?>

With just the default ‘About’ page in our theme, if we look at our site we’ll see the following in the source code:

<div>
<ul>
<li><a href="the-link-in-here" title="About">About</a></li>
</ul>
</div>

And that’s all there is to it! Of course, we can add in a bunch of options into that array. You can check out the details over at the WordPress codex and here are a few of the more important ones explained:

• menu – which menu to call. In our example we only have one but you can set up as many menus as you like
• container – what element is wrapped around the menu. The default is a standard <div> but if you’re playing with the new kids over at HTML5 you could always change this to <nav>
• container_class – the css class given to this container, helpful for custom styling
• menu_class – the css class given to the <ul> that is rendered. The default is ‘menu’, and again this is helpful for custom styling.
• depth – How many levels should the menu display. The default is 0′ which means all levels, but you can set this to perhaps 1′ or 2′ to limit how far a drop-down menu will render. Handy stuff!

That’s probably enough for our purposes, but it’s definitely worth checking out the WordPress codex because there are many options you can set, like adding text before and after menu items and links.

Using the GUI

So let’s get cracking with the user interface, where much of the magic happens.

The first thing we need to do is create our first menu (remember, we can have multiple menus) so I’ll imaginatively create one called ‘Our First Menu’. Type that in to the Menu Name field and hit the Create Menu Button.

Did you spot the check-box ‘Automatically add new top-level pages’? Well, do you?

Normally I don’t, because I figure if we’re going to the trouble of making a custom menu we probably don’t want it doing anything automatically. After all, we want complete control over our menu, so I don’t want WordPress dropping in a new page every time we create one. Maybe you do, and that’s okay with me too :)

Excellent! Our first menu is empty but we’re well on our way. Over on the left we’re told that our theme currently only supports one menu so we best make sure we’re using ‘Our First Menu’. Select it in the drop-down, and click Save.

Adding Pages to our Menu

So we’ve created a place in our theme for the menu, and now we’ve created the menu itself. Trouble is, there’s probably nothing in it. WordPress gives us three easy ways to add content to the menu, and the great news is that it doesn’t have to be content that sits in the WordPress site. For example, the first box on the left you’ll see is for Custom Links.

You could perhaps link to your twitter account like I have in the screen-shot above, and just click ‘Add to Menu’. It might be your portfolio, which you’ve hosted elsewhere, or links to live client sites. It might even be links to your favourite news sites. Whatever you choose, it’s great to know your menu can take your visitors anywhere.

The second (and probably most often used) way to add content to the menu is in the Pages’ box, under ‘Custom Links’.

As you can see, I’m working on a fresh install of WordPress 3 which gives me just two pages – Home, and About. Now ‘Home’ strictly speaking isn’t a page in the default configuration (although you can change that). For me, ‘Home’ is whatever resides at and in index.php.

Notice the tabs at the top of the ‘Pages’ box, which allow you to hunt around through content rich sites for exactly the pages you want. If you’re setting up your menu for the first time you might want to look in the ‘View All’ tab, or if you’re just adding in a page you might want to ‘Search’ for it.

I’m going to select both Home and About so I’ve got something to play with. If I hit ‘Add to Menu’ you can see that my menu is really starting to shape up.

Finally we have the ‘Categories’ box, which acts in much the same way as the ‘Tabs’ box. Again, as this is the default install of WordPress I only have one category, the much maligned ‘Uncategorized’.

I’m going to select it (most of my posts often accidentally end up in uncategorized!) and ‘Add to Menu’. This is what we now have:

Now before we move on you need to ‘Save Menu’, so go ahead and click it.

To prove that this has worked we can load up my simple blog (which has the TwentyTen theme installed) and marvel at it’s glory.

Menu Hierarchy

That’s cool but it’s also only the beginning. The next thing to look at is ordering your menu hierarchy. So far the menu items have just appeared in the order we added them, but we probably want to change this. The good news is that this the whole system is drag-and-drop, so go ahead and move things around.

What you’ll also notice is that you can create a hierarchy by dragging items onto other items. I’ve added a few more pages and created something that looks like this:

You can see I’ve created a hierarchy of pages as indicated by their indents, and I’ve also changed the name of ‘uncategorized’ to ‘The Blog’. If we whizz on over to the actual site, we can also see that WordPress has created a funky drop down menu for me.

Now it’s worth noting that TwentyTen is designed to style the menu as a drop-down, and that the actual HTML WordPress generates looks like this:

<div>
<ul id="menu-our-first-menu"><li id="menu-item-5"><a title="The home page" href="http://localhost/">Home</a></li>
<li id="menu-item-6"><a href="http://localhost/?page_id=2">About</a>
<ul>
<li id="menu-item-23"><a href="http://localhost/?page_id=9">Our Company</a>
<ul>
<li id="menu-item-21"><a href="http://localhost/?page_id=13">The Team</a></li>
</ul>
</li>
<li id="menu-item-22"><a href="http://localhost/?page_id=11">Our Products</a></li>
</ul>
</li>
<li id="menu-item-20"><a href="http://localhost/?page_id=15">Get in Touch</a>
<ul>
<li id="menu-item-19"><a href="http://localhost/?page_id=17">Office Locations</a></li>
<li id="menu-item-4"><a href="http://twitter.com/richardshepherd">My Twitter Stream</a></li>
</ul>
</li>
<li id="menu-item-8"><a href="http://localhost/?cat=1">The Blog</a></li>
</ul>
</div>

A Few More Options

You should also be able to see in the Menus admin that each menu has a drop-down arrow. Click on it, and you’ll see there are a few things you can tinker with.

• URL - The url which the menu item links to
• Navigation Label - What it will actually say in the menu
• Title Attribute - Useful for making your menu accessible, and you could also use some jQuery to grab this and create a piece of ‘description’ text
• Remove/Cancel - No prizes here

Menu Widgets

There’s one more thing we’ll look at in this introductory tutorial, and that’s the menu widget. So far all we’ve done is actually create a menu in our header and stick ‘Our First Menu’ into that hook. There is one other thing Custom Menu’s do out-of-the-box. In the WordPress admin head on over to Appearance > Widgets and we can take a look at the Custom Menu Widget.

It should be sitting under Available Widgets, so drag it over to one of your widgetized areas and let’s take a look at the options:

As you can see, there aren’t many! You can give the widget a title (I’ve called mine ‘Our Menu Widget’) and then select which menu you have created to use. Now we only created one menu in this tutorial, but you could of course create a second and drop it in here. Click ‘Save’, head on over to your site and you should see something like this:

And that’s it! Great for a sitemap-like feature, just remember that if your menu doesn’t automatically update when you add new pages neither will this widget.

Just the Beginning

As you can probably tell, there’s a lot going on with the Custom Menu feature. I’ve tried to stick to the basics here and focus on the GUI, but there is a lot more going on under the hood that is also worth looking into. If you feel confident with PHP then start playing – there’s so much more you can do.

If all you are looking for is a simple way to create and manage menus for you and your clients, we hope this overview gets you started. As always, we welcome your comments and look forward to seeing Custom Menus on your WordPress sites!

“They just got named poorly because they live in the Posts table in the database. Think of them more like custom objects/content types.”

Cool – it’s just custom content. What’s the point of that then? Can’t we just categorise blog posts and order our pages in nice hierarchies? Can’t we use conditionals to spit out different CSS stylesheets? Well yes, we could. But admit it – it’s not fun.

And hands up if you’ve ever tried to explain to a client what a custom field is. Hurts, doesn’t it? So thank goodness for wonderful people like Jane who have given us a solution.

What is it and What it isn’t

Everyone’s talking about them. I recently asked Chris Coyier from CSS-Tricks what excited him about WP3 and he replied custom post types:

“Think of how Tumblr works – how you can publish photos, quotes, links and whatever else. You could create those same types now with WordPress, and build themes to support and have special styles for them. This is fantastic stuff for building custom sites!”

Make sense? Well according to Jane, Chris misinterpreted their goal:

“Custom post types aren’t really meant for that use […] Custom post types are great for things that are more or less catalogued: products (in an e-commerce site), listings for a real estate site, etc. For regular content creation as described [by Chris], you can already do [that] by using custom taxonomies and/or stylesheets to make post templates.”

Now I’m going to go out on a limb here and say that Chris made a interesting suggestion. I say this for two reasons: firstly because I think the great thing about WordPress is we can use it in the way we feel it should be used. There might be a different or better way, but there is no wrong way to do something (unless it doesn’t work!). Secondly I refuse to believe that many designers would read up on something as scarily titled as ‘custom taxonomies‘.

Indeed I expect to see WordPress themes cropping up all over the place that mimic the way Tumblr themes look and work. WooThemes have already released three.

Get your Hands Dirty

Now before we dig in I want to say this – custom post types make things a lot easy for non-technical people to use the WordPress admin to enter content. However the designer/developer still needs to have a reasonable grasp of PHP and needs to be prepared to get their hands dirty (unless they opt for a plugin that does the job for you like http://wordpress.org/extend/plugins/custom-post-template/ or http://wordpress.org/extend/plugins/custom-post-type-ui/)

For our tutorial we’re going to be editing functions.php which is your theme directory. We’re simply adding to this file, so feel free to start at the top or at the bottom – just don’t change any of the code that’s already there. For the more confident of you out there you could adapt this code into a plugin.

With a few edits we are going to create a custom post type for our portfolio, and a template which will use this information. We’ll end up with a new panel in the admin menu which looks like this:

A new overview page called “My Portfolio”:

And a new place to enter our content:

Step 1

Here’s the first bit of code we need to add to functions.php, which I’ll review below.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

add_action('init', 'portfolio_register');
 
function portfolio_register() {
 
	$labels = array(
		'name' => _x('My Portfolio', 'post type general name'),
		'singular_name' => _x('Portfolio Item', 'post type singular name'),
		'add_new' => _x('Add New', 'portfolio item'),
		'add_new_item' => __('Add New Portfolio Item'),
		'edit_item' => __('Edit Portfolio Item'),
		'new_item' => __('New Portfolio Item'),
		'view_item' => __('View Portfolio Item'),
		'search_items' => __('Search Portfolio'),
		'not_found' =>  __('Nothing found'),
		'not_found_in_trash' => __('Nothing found in Trash'),
		'parent_item_colon' => ''
	);
 
	$args = array(
		'labels' => $labels,
		'public' => true,
		'publicly_queryable' => true,
		'show_ui' => true,
		'query_var' => true,
		'menu_icon' => get_stylesheet_directory_uri() . '/article16.png',
		'rewrite' => true,
		'capability_type' => 'post',
		'hierarchical' => false,
		'menu_position' => null,
		'supports' => array('title','editor','thumbnail')
	  ); 
 
	register_post_type( 'portfolio' , $args );
}

Anyone who’s worked with WordPress before will recognise the structure here. We’re adding an action when the WP Admin initialises to call the function portfolio_register(). In that function we create two arrays, $labels and $args, and then use register_post_type to pull it all together. In doing so we name the new custom post type ‘portfolio’ and tell it to use the arguments from $args.

The devil is in the detail, so let’s run over some of those arguments. A full list can be found at http://codex.wordpress.org/Function_Reference/register_post_type. First let’s look at $labels:

• name – this is the (probably plural) name for our new post type
• singular_name – how you’d refer to this in the singular (such as ‘Add new ****’)

You can probably work out the rest of $labels for yourself, as they simply refer to different circumstances in which the name of your custom post type would be used.

And now $args:

• public – should they be shown in the admin UI
• show_ui – should we display an admin panel for this custom post type
• menu_icon – a custom icon for the admin panel
• capability_type - WordPress will treat this as a ‘post’ for read, edit, and delete capabilities
• hierarchical – is it hierarchical, like pages
• rewrite – rewrites permalinks using the slug ‘portfolio’
• supports – which items do we want to display on the add/edit post page

That’s the first simple step, and it should be enough to see your new custom post time in the WordPress admin. Save functions.php and take a look!

Step 2

The next thing we need to do is register a taxonomy. Or, in English, create categories for this new content type.

For example, in our portfolio we want to include the names of technologies and software used to create our work. I’m going to call this taxonomy ‘Skills’, and populate it with things like HTML, CSS and jQuery.

It’s just one line of code:

1

register_taxonomy("Skills", array("portfolio"), array("hierarchical" => true, "label" => "Skills", "singular_label" => "Skill", "rewrite" => true));

The first item here is the taxonomy name, ‘Skills’. The second is the name of the object type we’re applying it to, in our case the custom post type ‘portfolio’ (which is an array). Finally our arguments; you can find a full list at http://codex.wordpress.org/Function_Reference/register_taxonomy, and here we’re using just three which have the same meaning as described in Step 1.

Add that line of code in and you should now see:

You can then enter new ‘skills’ just like you’d enter categories for blog posts. It looks like this:

Step 3

The third step is to add custom data fields to the add/edit post page.

For our portfolio we can add things like the year the piece was published and details on who designed, built and produced the site/design.

There’s a bit more code here, but read through it in order and it should make sense:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

add_action("admin_init", "admin_init");
 
function admin_init(){
  add_meta_box("year_completed-meta", "Year Completed", "year_completed", "portfolio", "side", "low");
  add_meta_box("credits_meta", "Design & Build Credits", "credits_meta", "portfolio", "normal", "low");
}
 
function year_completed(){
  global $post;
  $custom = get_post_custom($post->ID);
  $year_completed = $custom["year_completed"][0];
  ?>
  <label>Year:</label>
  <input name="year_completed" value="<?php echo $year_completed; ?>" />
  <?php
}
 
function credits_meta() {
  global $post;
  $custom = get_post_custom($post->ID);
  $designers = $custom["designers"][0];
  $developers = $custom["developers"][0];
  $producers = $custom["producers"][0];
  ?>
  <p><label>Designed By:</label><br />
  <textarea cols="50" rows="5" name="designers"><?php echo $designers; ?></textarea></p>
  <p><label>Built By:</label><br />
  <textarea cols="50" rows="5" name="developers"><?php echo $developers; ?></textarea></p>
  <p><label>Produced By:</label><br />
  <textarea cols="50" rows="5" name="producers"><?php echo $producers; ?></textarea></p>
  <?php
}

First of all we call the add the admin_init function to the queue when the WordPress admin initialises, and within that function we add two meta boxes – places to enter our data. The context for these two statements is

1

<?php add_meta_box( $id, $title, $callback, $page, $context, $priority ); ?>

The only difference between the two is where we place them on the screen. The ‘year completed’ is placed in the sidebar using ‘side’ whilst the ‘credits’ are placed in the main flow of the page using ‘normal’.

Within the two functions there is some vanilla WordPress PHP code and HTML to help define our old friend custom fields. Make sure to include

1

global $post;

…so that we can then query the current post using

1

$custom = get_post_custom($post->ID);

Once the two new meta boxes have been added it looks like this:

The final thing to do in step 3 is to make sure we then save these values with this post. I do this with

1

add_action('save_post', 'save_details');

and

1
2
3
4
5
6
7
8

function save_details(){
  global $post;
 
  update_post_meta($post->ID, "year_completed", $_POST["year_completed"]);
  update_post_meta($post->ID, "designers", $_POST["designers"]);
  update_post_meta($post->ID, "developers", $_POST["developers"]);
  update_post_meta($post->ID, "producers", $_POST["producers"]);
}

There’s nothing too tricky here. Again we’re adding an action, this time to the ‘save_post’ event. It fires the function save_details() which uses update_post_meta (http://codex.wordpress.org/Function_Reference/update_post_meta) to save the relevant data.

Step 4

A nice little touch is to rejig the layout of the My Portfolio page to display some of this information. If you’ve followed through the article so far this should all make sense to you:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

add_action("manage_posts_custom_column",  "portfolio_custom_columns");
add_filter("manage_edit-portfolio_columns", "portfolio_edit_columns");
 
function portfolio_edit_columns($columns){
  $columns = array(
    "cb" => "<input type=\"checkbox\" />",
    "title" => "Portfolio Title",
    "description" => "Description",
    "year" => "Year Completed",
    "skills" => "Skills",
  );
 
  return $columns;
}
function portfolio_custom_columns($column){
  global $post;
 
  switch ($column) {
    case "description":
      the_excerpt();
      break;
    case "year":
      $custom = get_post_custom();
      echo $custom["year_completed"][0];
      break;
    case "skills":
      echo get_the_term_list($post->ID, 'Skills', '', ', ','');
      break;
  }
}

Here we’re adding two more functions to the WordPress Admin. The first, portfolio_edit_columns($columns), simply defines the columns. The first two arguments “cb” and “title” are part of the core so don’t play with those too much (you can of course rename “Portfolio Title”). It’s the next three that come from our custom post type, “description”, “year” and “skills”.

We have one more function to tell WordPress where to get this data from – portfolio_custom_columns($column). Using a simple switch/case we can define what data to actually show in the column layout. For the “description” we use the_excerpt(), for “year” we get the custom field data using get_post_custom(), and for “skills” we get a comma separated list of the terms/taxonomies/categories using get_the_term_list().

With that we have our customised columns:

One final touch

Be default custom post types will display using single.php, or index.php as a fallback. The great thing is we can create our own custom template using the filename single-xxxxxx.php. In our case this is single-portfolio.php. Just create your template file in your theme directory and the custom post type will use it. How you display the data is totally up to you.

Hey, did you also notice the ‘Featured Image’ option on the add/edit page. That works out-of-the-box thanks to the ‘thumbnail’ part of:

1

'supports' => array('title', 'editor', 'thumbnail')

You just need to make sure to include the following line of code in functions.php:

1

add_theme_support('post-thumbnails');

For more details check out this excellent post by Mark Jaquith.

Rewrite Problems?

There are a few reported problems out there about the rewriting of custom URLs; in short, they sometimes don’t work. However, if you’re experiencing this problem there are a couple of easy fixes.

First, simply go to the Settings > Permalinks page, which will flush the permalinks (assuming that your WordPress install can write to the .htaccess file). This should clear up most problems related to permalinks, custom post type related or not.

If that doesn’t work you can add a line of code after you register the post type:

1
2

	register_post_type( 'portfolio' , $args );
        flush_rewrite_rules();

This worked for me on a particularly problematic install.

Conclusion

And there we have it! That is a whistle-stop tour of custom post types which I hope gives you the appetite to explore further.

The best thing is to experiment with the code, read through the documentation in the WordPress Codex, and share your ideas with others. Like any new feature I’m sure it will evolve as users create new and exciting ways to use it, and we’d love to hear about how you’re using custom post types here at Think Vitamin.

According to founder Matt Mullenweg, WordPress now runs an estimated 8.5% of all sites on the internet. This is a staggering amount – almost one in every ten sites is sitting on what was once just ‘blogging software’.

Put another way, there are 20 million eager WordPressers looking forward to the long awaited upgrade from 2.9.2 to WordPress 3.0.

The first release candidate is now available and most of the new features are well-known and have been described in detail. Others, like custom post types, are leaving some users scratching their heads. But what does the new version of WordPress mean for the millions of web designers that use it every day?

A CMS by any Other Name

“Version 3 is absolutely a step forward for designers”, argues Chris Coyier from CSSTricks”

“For one thing, I think it will finally squelch the ‘WordPress is a blogging platform, not a CMS’ argument. With custom post types becoming a core feature, it is straight up CMS territory.”

We’ll come back to custom post types later, but the point that Chris makes about WordPress becoming a true Content Management System (CMS) has lots of support.

Elliot Jay Stocks is a well-known designer who uses WordPress, and he’s also excited about this development towards a true CMS:

“It’s definitely a step forward. It’s moving further and further away from its roots as a blogging engine and incorporating powerful tools that make it a viable CMS.”

Jeff Starr, who co-wrote ‘Digging into WordPress’, believes that:

“WordPress 3 is custom everything, and it’s awesome. These features provide greater control and flexibility in terms of content organisation, presentation, and management. Custom content types take us beyond the days of posts and pages. Custom taxonomies take us beyond tags and categories.”

Adii Pienaar from WooThemes agrees:

“I’m very excited about custom post types as this makes WordPress even more of a fully-fledged CMS”

So let’s take a look at some of these features in more depth, and just how they will affect web professionals designing sites for the WordPress platform.

Custom Post Types – Simpler than it Sounds

Perhaps the feature that causes the most confusion, or at least the most questions, is custom post types. At its heart it’s a relatively simple concept – instead of just posts and pages you can now specify your own type of entry.

Admin screen for a custom post type of “Video”

Chris from CSSTricks explains the concept well:

“Think of how Tumblr works – how you can publish photos, quotes, links and whatever else. You could create those same types now with WordPress, and build themes to support and have special styles for them. This is fantastic stuff for building custom sites!”

Fantastic stuff indeed, and it’s interesting to hear Chris mention Tumblr. WordPress’s nimbler, younger cousin continues to grow at a phenomenal rate and has many fans out there. Indeed, some designers have ditched WordPress altogether for Tumblr.

Others, like Corbus Bester, have designed amazing WordPress sites that look and feel like Tumblogs. Perhaps there is some mileage in this fusion of styles; it’s certainly now possible – and considerably easier – with custom post types.

Chris Spooner from SpoonGraphics also sees the benefit this new feature will bring:

“As someone who uses WordPress for almost every website I build, I’d say it would be really useful to be able to create a new entry for a particular section of a website that’s different to the usual post and page layouts. A new portfolio entry springs to mind as a good use of this feature.”

The Community Gives Back

One of the other highly publicised additions, thanks in no small part to the goodwill and marketing genius of those WooThemes folk, is the new Navigation System.

Admin screen for the new menu system

It is, in short, a master-stoke. It also blurs the line between the open-source platform and its profit-making community. Adii Pienaar explains:

“I’m happy to be a bit biased, but the new menu system that WooThemes contributed is long overdue and a massive benefit to every single WordPress user, In essence, this is such a basic feature of any CMS, but due to it being a benefit to all WordPress users I think this is a significant new addition” he adds.

Chris Coyier believes:

“The menu building tools are going to be huge for designers as well, and unquestioningly a step forward. Building dynamic menus in the past has involved using WordPress functions in the theme code itself with a bunch of parameters. Nerdy stuff, and not for the average site owner or even for many designers.”

WooThemes designer Magnus Jepson agrees:

“The navigation system will let designers concentrate on setting up the menu instead of hard coding it.”

So how does it work? Chris explains:

“The new menu builder puts a GUI on [menu building], putting menu control in the admin where it should be and where anybody can intuitively control it.”

Other Features

Of the myriad other features on offer with version 3.0, the more noteworthy include:

• The long awaited integration of WordPress MU with the core WordPress code, a project that has taken the WordPress team over a year;
• The new default theme TwentyTen, and the promise of a new theme every year;
• New author templates, allowing the easier customisation of pages for individual authors; and
• A new installation system, ditching the known security issue that is the ubiquitous ‘admin’ user.

The new default theme “TwentyTen” home page

WordPress 3 for Designers

So will these new features make a difference for designers? Adii argues:

“Not necessarily for designers, I think the new features are probably more geared to end-users, like the menu system, or developers, for example custom post types.”

He has a point. The level of comfort and experience you have with PHP really does affect how much you can squeeze from the WordPress system; HTML and CSS are simply not enough. Elliot touches on this:

“I hope it becomes easier to work with template files. Less PHP wizardry required and more functionality built in from the start.”

Chris Spooner thinks that others will benefit from the upgrade:

“I see the upgrades more suited to the everyday end user. The extra customisation options will also allow the non-tech user to add their own touch to their blog.”

Others, like Jeff Starr, believe that WordPress 3 will bring benefits to designers as well:

“[It is] definitely a step forward. A huge step. In addition to better content management, its integration of WPMU makes it that much easier to create entire networks of sites with a single installation. WordPress 3 also features bulk updates for plug-ins and themes, saving users even more time.”

And it’s that hacking that keeps WordPress, even version 3.0, out of the reach of anyone without a basic grounding in PHP (and, arguably, jQuery). Elliot argues:

“It still doesn’t look as powerful as Expression Engine, But for ease-of-setup and ease-of-use, WordPress remains my favourite CMS. My only beef with WordPress is that it can take a lot of hacking to get what you want, and I’m hoping that WordPress 3 will solve this problem.”

The future for WordPress

So just what does the future hold for WordPress? Is it too early to speculate what we’ll see in WordPress 4?

“I’d actually vote for it not to develop too much,” said Adii from WooThemes. “WordPress is great because it has never been the most complex or complicated system to use. I am however in favour of adding functionality that will make WordPress a more complete CMS, even if that means having different ‘flavours’ of the platform i.e. blogging vs. CMS.”

Perhaps WordPress.com will remain as the hosted solution for casual bloggers, and a ‘WPLite’ version will also become available.

We then might see an offshoot, the more powerful CMS version, which caters for the needs of its considerable and growing user-base of web designers looking for a back-end system.

It makes sense, and it could see an opportunity for Automattic to further monetise part of its software-as-service stable. But who exactly would profit? And who would pay?

When asked about the future or WordPress, Jeff focuses on usability for designers:

“Make it fast, make it secure, and make it easy on the server. Go for lean and mean, and deprecate the fluff that nobody uses.”

This sentiment is echoed by Magnus:

“I hope that WordPress will develop to be faster and more secure than it is today, and also that it adopts the most widely used functions into the core for all to use. Maybe wishful thinking to have both new functions and faster system, but everything is possible.”

Chris Coyier also offers some thoughts about the future:

“As far as the software itself, I hope it continues to have a big community and have a good, smart, quick core team. There are no particular ‘features’ that I’m pining for anymore, mostly just a wish that the team keeps my WordPress nice and secure as we move forward.”

There’s a nice turn of phrase here from Chris, “My WordPress”. The wonderful thing about WordPress is that it’s us, the users, the designers and the developers that help create its ultimate direction. And it’s our creative and unique implementations of this powerful system that will guide its future development.

Want More on WordPress 3.0?

Over the coming weeks we will be taking a more code based look at some of the new features in WordPress 3.0. Watch out for our first article which will focus on “Custom Posts” in the next few weeks.