The current Aurora release of Firefox includes the Vibration API, a very simple system for making devices rumble.

The API consists of a single call to navigator.mozVibrate().

The function accepts a single parameter. Pass a positive integer to indicate the number of milliseconds the device should vibrate. Pass an array of these integers to create a vibrate pattern. Finally, pass 0 to stop any current vibration.

navigator.mozVibrate(2000);
//Vibrate for 2 seconds
 
navigator.mozVibrate([1000, 1000, 500]);
//Vibrate for a second.
//Then pause for a second.
//Then vibrate for another half-second.
 
navigator.mozVibrate(0); //An empty array is also valid
//Stop vibrating

Obviously, this is only meaningful on devices that support vibration, like mobile phones, tablets and game controllers. However, in both the Firefox implementation and pending W3C specification, calls are silently ignored when the device does not support vibration or vibration is not allowed.

The W3C added a NotSupportedError that is thrown when invalid values are passed to the function. Obviously, it has also generalized mozVibrate() to navigator.vibrate().

The specification also checks document.hidden before the rumble begins and at any time the visibilitychange event is triggered. If document.hidden is false, any requested vibrations must be ignored and any current vibration must cease immediately. No feedback is provided to your code in either of these events.

This means that spam pages can’t drain your battery (unless you leave the offending page up), a concern expressed on the WebKit mailing list and is implemented as navigator.webkitVibrate() in the development builds of the WebKit core.

To date, it has not been easy to tell, using JavaScript, whether the user can see your page or not. Sure, we have load, focus, blur and unload, but these have proven quirky and inconsistent in the past. Certain environments give us the ability to jump between windows and tabs, and even scroll pages without giving focus to the browser window. Automatic lock screens leave your web page active, but inaccessible. Further, Google is developing a feature for Chrome wherein a page can load and render before it is made visible to the end user.

If you’ve ever received a message on Facebook when it was the selected tab, but not necessarily the selected window and application, and it hasn’t made a noise, you’ve experienced some of this quirkiness.

So what can you do with this new API? You can slow down your application, suspend timers and clocks, and generally make your page behave better in a cooperative multitasking environment. In short, still more of what used to require Flash to implement no longer does.

Chrome introduced this new, simple API in 13 and the W3C has a group standardizing it. Firefox and IE will both see it added in their respective version 10 browsers.

To use it, you really only need to know two properties and one event.

The document.visibilityState property can be any one of four values, but the two most common (and only required) ones are hidden and visible. Now, when the page loads, you can know whether your content is actually exposed to the user or not.

The document.hidden provides a simple boolean.

Happily, the standards do partially specify how other applications can interact with these properties:

As examples, the attribute returns true when:

• The User Agent is minimized.
• The User Agent is not minimized, but the page is on a background tab.
• The Operating System lock screen is shown.
• The User Agent is minimized and a preview is shown.

The visibilityChange event will fire when this state changes after the initial page load, so you needn’t check it obsessively.

Note that Chrome uses the webkit prefix for this API, its properties and its event. Firefox and IE are expected to use the W3C version, without prefixes.

Please forgive the Simpsons reference in the title, but let’s face it, browsers eat up an enormous amount of screen real estate with menu bars, super bars, status bars, toolbars, scrollbars. And that’s all before you get to the white space and toolbars and menus your own app requires.

Sure, you can press F11 today in pretty much every browser and achieve that end, but how many of us actually do that? If we’re the power users and we don’t do that, what hope do we have for our users?

The Full Screen API will make it easy to do automatically. Better still, pre-release versions of this API are already supported in Firefox 9 and Chrome 15 (though disabled by default in Firefox 9).

To get you started, the Mozilla Developer Network has released its own guide to the interface.

In brief, there are a few key requirements:

1. The calling object for requestFullScreen() must be a DOM node
2. The DOM node may not be the child or parent of a plugin
3. If the DOM node is an IFRAME (or is the parent or child of one), the IFRAME must have an allowfullscreen="true" attribute

So what does real-world code look like? Let’s take a look at Mozilla’s own example:

function toggleFullScreen() {
  if ((document.fullScreenElement && document.fullScreenElement !== null) ||    // alternative standard method
      (!document.mozFullScreen && !document.webkitIsFullScreen) {               // current working methods
    if (videoElement.requestFullScreen) {
      videoElement.requestFullScreen();
    } else if (elem.mozRequestFullScreen) {
      videoElement.mozRequestFullScreen();
    } else if (elem.webkitRequestFullScreen) {
      videoElement.webkitRequestFullScreen(Element.ALLOW_KEYBOARD_INPUT);
    }
  } else {
    if (document.cancelFullScreen) {
      document.cancelFullScreen();
    } else if (document.mozCancelFullScreen) {
      document.mozCancelFullScreen();
    } else if (document.webkitCancelFullScreen) {
      document.webkitCancelFullScreen();
    }
  }
}

As you can see, the naming conventions aren’t quite there yet. Further, neither Firefox nor Chrome quite apply the CSS expectations of the developing standard.

When the calls fire successfully, either fullscreenchange, mozfullscreenchange or webkitfullscreenchange events will fire. Likewise, when it fails, either fullscreenerror, mozfullscreenerror or webkitfullscreenerror events fire.

Note also that in Firefox 9, you cannot use a form in fullscreen mode; pressing any key inside of an input seems to take you out of Full Screen mode. The browser provides no instructions for exiting fullscreen mode, so you will need to provide them yourself.

Confusingly, the ALLOW_KEYBOARD_INPUT parameter in the webkitRequestFullScreen() call seems to block the keystroke handler in the MDN sample, though forms once again work. It also provides instructions for exiting Full Screen mode, though it neglects to mention that Esc will do it as well, instead referring to Command + Shift + F on my Mac.

Still, Firefox 10 is expected to support the API out of the box, so we can start to see the development of true browser application environments. The possibilities for kiosk environments are also exciting.

If you haven’t heard already, OpenSocial is a multi-vendor Social networking API similar to the Facebook API’s.  It is also, a very different environment from the Facebook API’s you may already be using.

If you’re not already familiar with Facebook development, It’s pretty much a one way street.
You deliver a page marked up in FBML (A facebook specific markup language) to facebook in response to requests from facebook. More importantly, Your application lives solely in the Facebook realm  you can really only push data to it.  Put simply, what happens in Facebook, stays in Facebook.

The new Open Social standard is a significantly friendlier place to deploy applications for several reasons.

• No need to use FBML, HTML & Javascript work just fine.
• You can use whatever Javascript Library you want, OpenSocial uses it’s own namespace to prevent conflicts.
• Persistent storage, You don’t need to handle everything on your server and an application can be written exclusively in javascript + html without any need for a server backend.  All data can be stored to the social network.
• Universal Feed.  All OpenSocial apps can write to a shared Activities feed.
• Universal Friends.  Friends can transfer seamlessly between Open Social applications
• You can brand & Host yourself.  Unlike Facebook, you can pull data into your application instead of solely pushing it into the Facebook world.

You can find the OpenSocial API’s at http://code.google.com/apis/opensocial/