Remy Sharp has developed a tool for remotely debugging web pages. This works using code injection, so be very sure to keep it out of production environments. However, when you need to diagnosis issues remotely, say, because it’s on a mobile device, with limited console support, or because a client is reporting problems that you can’t repeat locally.

Implementing this is a snap!

:listen

This returns an UUID which you will need to insert into the page markup:

<script src="http://jsconsole.com/remote.js?FAE031CD-74A0-46D3-AE36-757BAB262BEA" type="text/javascript"></script>

From then on, calls to console.log() will return their output to your listening machine.

The really handy library has one more trick up its sleeve. You can specify the UUID to which you will listen.

:listen FAE031CD-74A0-46D3-AE36-757BAB262BEA

When the remote device loads the debugging module, you’ll see something like this in your console:

:listen FAE031CD-74A0-46D3-AE36-757BAB262BEA
Creating connection...
Connected to "FAE031CD-74A0-46D3-AE36-757BAB262BEA"
Connection established with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

HTML5 begat the AUDIO tag. Now that we have it, what do we do with it? And how do we accommodate older browsers?

Unfortunately, there are two incompatible standards and the W3C Audio Working Group "has not decided upon a specification".

The Web Audio API works on recent builds of Chrome and Safari. The API includes complex filters and allows developers to roll drum machines and visualizations. It’s active by default on Chrome 16, but not on Safari 5. Worse, Safari 5 reports that it is supported, but won’t run the samples to which I have linked. Adding insult to injury, it’s also slow and can randomly introduce skips and clicks.

Mozilla introduced the Audio Data API, but it only works in Firefox 4 and above. It’s also a very low level API and requires intermediate libraries to be truly useful for non-developer apps, of which there are a number. Like Google’s Web Audio, it’s slow and can randomly introduce skips and clicks.

Since these two technologies encompass only about half of web traffic, we clearly need fallback mechanisms.

There is SoundManager2 which uses both HTMl5 and Flash 8 or 9+ to bridge platforms. It relies on MP3/AAC/OGG/WAV sample files and supports panning, sampling and – most valuable – event support. Events like whileplaying and onposition make it easy to sync your audio and video. Beyond equalization, volume and start/stop positions, however, you can’t do much to filter the sound output.

You might also try Audiolet, which lets you generate your own waveforms in browser, giving you a full range of freedom, but it’s going to sound like 8-bit audio unless you use samples. (Hint: try combining it with MUSIC.js to make the most of that 8-bit arcade sound)

Then there is audiolib.js, which goes even lower than Audiolet and can operate server-side. It allows you to both manipulate and generate audio samples in PCM format, which it can then save for future use.

Audiolet starts quickly and is half the size of SoundManager2, but can click and skip, especially when the browser is scrolling or otherwise pre-occupied. SoundManager2 can bog down when playing too many sounds at once. Try activating +follow and then moving your mouse quickly over its Smashing Christmas Lights demo to see this in action.

Audiolib is extremely low level, but for generating short realistic waveforms, it is effective and fast, both client-side and server. Sadly, in Firefox 9 on my Mac, this example only plays the first bell while Safari 5 and Opera 11.6 played nothing at all. Chrome 16 played it correctly. However, when I had the page open in 3 browsers simultaneously, even though only one was generating noise, the load was causing skipping and clicking in Chrome. Your audio could easily suffer if the end user’s computer is otherwise busy.

In short, there is no good solution yet that is widely supported and flexible and performant, even within modern browsers.

Remember the glory days of 8-bit audio? Games today feature fully scored soundtracks records in dozens of high quality MP3′s, but as late as the 90′s, music was 8-bit frequency manipulation.

MUSIC.js is Greg Jopa’s library for taking notation and calculating its corresponding frequency. This can then be fed to audio generation libraries like audiolet.js to generate the sound.

Implementation is very simple. Take his sample of A from the fourth octave. Two lines is all it takes:

var n = Note.fromLatin('A4');
var freq = n.frequency(); // returns 440

Intervals are similarly straightforward:

var c = Note.fromLatin('C3');
 
// by semitone
var wholeStep = Interval.fromSemitones(2);
var d = c.add(wholeStep);
console.log(d.latin()); // "D"
 
// by interval name
var g = c.add('fifth');
console.log(g.latin()); // "G"

It even calculates chords and scales. Note that all of these calculations are uncached, so you will want to optimize your loops.

Unless you develop in-house sites for companies that have standardized on a very modern browser, you’re stuck developing sites for IE8 and even IE7. (Heaven help you if you’re still developing for IE6).

How then do you access some of the powerful features of ECMAScript or the contextual tags of HTML5 without having to write layer upon layer of fallbacks?

Your fellow JavaScript developers have produced shims to emulate most of this functionality, even in environments where Chrome Frame isn’t viable.

The html5shiv project is still under active development. It not only adds support for HTML5 contextual tags, it sets their default styling and makes them print in IE8 and below. Naturally, their canvas element is not going to have the behaviors you see in other browsers, but at least you can get away with a single set of markup and fewer CSS rules.

The es5-shim project is also under active development. It alters prototypes of native objects, so I wouldn’t combine it with prototype.js. This library also has the benefit of being well documented – including what does and does not differ from the specification. Heed the cautions from Kris Kowal, its author, though:

“As closely as possible to ES5″ is not very close. Many of these shims are intended only to allow code to be written to ES5 without causing run-time errors in older engines. In many cases, this means that these shims cause many ES5 methods to silently fail. Decide carefully whether this is what you want.

About a month ago, I found myself In a terrible debugging situation. A web app that I had carefully QA’d in both an IE 8 and IE9 environment was receiving a slew of bug requests from users. Some of these we’d expected. The use of several minor CSS3 tweaks meant that the visual experience was intentionally degraded in IE, but many of these we hadn’t.

Script timeout errors popped up randomly throughout the enterprise.
IE 666 users complained and I wasn’t allowed to take appropriate action.
Layout quirks surfaced.

Even more troubling was the discovery of radically different layout interpretations between builds of IE 8. My testing had proved inadequate because minor build number differences were interpreting the css in radically different ways. Since the app had managed to make it into production with these issues, and fully repairing all of them looked to be a slog I didn’t have the temporal luxury of pursuing; I punted. I threw up conditional comments to repair the issues that were preventing casual browsing. Then I hid the login box for IE users; replacing it instead with a Chrome Frame install prompt.

The results were immediate. My complaint volume dropped astoundingly. More importantly, the number of unresolved Scorchers went to zero. At the same time, no one complained about needing to install Chrome Frame. I had a few issues with insufficient permissions, and a few lingering CSS tweaks that needed rolled out, but the ease of the fix really was astounding.

I’ve since retrofitted most of my production apps and web servers to take advantage of my users newly capable Microsoft Browsers and plan on making the strategic retreat a deployment strategy for many new projects. While I don’t plan on abandoning support for IE, I look forward to minimizing its impact on project risk.

Note:  This post was updated on 2011.6.16 due to a mistake in my account.

For those of you not aware, Hype is a new OSX app for building interactive HTML5 in a Timeline / WYSIWYG interface.

It’s not the first product in the space (Sencha Animator), it’s the first well publicized version 1.0 I’ve come across.  It’s also pretty reasonably priced at 29.99 a seat.

First the good points:

• Ease of use: This is definitely a pretty straightforward tool in this regard.
• Interoperability: The Hype API and ability to execute arbitrary javascript inside the page DOM make this a great option for extending the capabilities of an existing web app.  I’d obviously like it to be richer, but it’s a decent compromise for a rev 1 product.
• OS integration: For those of us on OSX, the drag and drop support  and polished UI are incredibly nice.

So what needs improvement:

• Animation along a path with key frames:  I realize this isn’t as embodied in css3 transforms as other options, but YUI Animation and Sencha Animator do it, so It’s demonstrably possible.
• Dynamic Sprite creation: The fact we can play arbitrary timelines from javascript is nice, but I would like to be able to add timelines to the frame.
• Direct Sprite manipulation: Changing sprite colors or the text in a block might be useful.

Earlier this week, I discovered that Safari doesn’t support dates in ISO 8601 UTC combined format:  “2010-06-19T03:11Z”.  This was a problem as my production system was delivering me a json file with dates in this format and my project was simply a new UI for the existing server.  A quick round of googling found DateJS a powerful chainable Date extension that enables both unified parsing and mask based date rendering.  I’d only played with it for a few minutes before I was completely hooked on it.  Just look at what it can do.

   1: // What date is next thursday?

   2: Date.today().next().thursday();

   3:  

   4: // Add 3 days to Today

   5: Date.today().add(3).days();

   6:  

   7: // Is today Friday?

   8: Date.today().is().friday();

   9:  

  10: // Number fun

  11: (3).days().ago();

  12:  

  13: // 6 months from now

  14: var n = 6;

  15: n.months().fromNow();

  16:  

  17: // Set to 8:30 AM on the 15th day of the month

  18: Date.today().set({ day: 15, hour: 8, minute: 30 });

  19:  

  20: // Convert text into Date

  21: Date.parse('today');

  22: Date.parse('t + 5 d'); // today + 5 days

  23: Date.parse('next thursday');

  24: Date.parse('February 20th 1973');

  25: Date.parse('Thu, 1 July 2004 22:30:00');

And Yes It supports ISO 8601 UTC combined format!.

A quick replacement of my existing date toolkit in the project and my bugs were fixed.

Wiki’s are amazing and powerful tools, unfortunately their dependence on specialized markup creates a huge barrier to their general adoption in many organizations.  This is a first step at building a wysiwyg editor for wiki markup.  While I will be focussing on the syntax unique to the popular MediaWiki platform, these techniques should be applicable to any wiki system.

The general flow of the converter is as follows:

1. Converter is passed the root node of an html fragment to translate.
2. Converter recurses through each of the child nodes and converts them.
3. Root node tag is replaced with wiki markup.

There’s really only 2 key components involved in this first pass. A converter object and the recursive method.

The Converter Object

The converter object is little more than a collection of name value pairs.  The name corresponds to an html tag.  The value is a Prototype template to use in the direct replacement of the given node. By convention we’ll write all of the tag names for the converter object in lower case.

var Converter = {
strong: new Template("'''#{body}'''"),
b:  new Template("'''#{body}'''"),
em: new Template("''#{body}''"),
i:  new Template("''#{body}''"),
h1: new Template('=#{body}='),
h2: new Template('===#{body}=='),
h3: new Template(‘===#{body}===’),
h4: new Template(‘====#{body}====’),
h5: new Template(‘=====#{body}=====’),
h6: new Template(‘======#{body}======’)  }

The Converter Function

The Converter function always performs 2 checks before attempting to convert a given node.  First it ensures that the node is in fact a node and not a stray function from the Prototype enhanced object.  Next it verifies that a converter exists for the tag.  The toLowerCase() on the tagName is necessary due to the inconsistent behavior browsers demonstrate with this attribute.  While all browsers return the variable in all caps for traditional html, they are not reliable about returning lower case values for xhtml markup.

function convertToWiki( textNode ){
//make sure textNode isn't a function on the object
if( typeof textNode != 'function'){

//provide a way to stop execution on select sub trees
if( !textNode.hasClassName( 'stop')){
$(textNode).childElements().each( convertToWiki );
}

//make sure a converter exists for the given tag
if( liteConverter[ textNode.tagName.toLowerCase() ] ){

//replace the text node with a converted version of itself
textNode.replace( liteConverter[textNode.tagName.toLowerCase()]
.evaluate({body:textNode.innerHTML}));
} } }

Let’s face it, prototyping and mock-ups are a pain in the rear. I’m always looking for ways to streamline the early phases of the design process. Today I found one that is simply brilliant.

Meet GUIMags: Simple, whiteboard magnets of common UI components.

Now you can do mockups on the whiteboard with high fidelity symbols that photograph well. Instead of sketching out the entire design for each iteration, you can simply rearrange elements and erase / rewrite labels as you collaboratively work through a design. When you’re done. You can simply take a picture of the whiteboard and start coding your mockup.

You can find GuiMags here:

http://www.guimags.com/index.php

pi.debugger is a new debug console that acts as a graceful counterpart to firebug.  I’ve  and Firebug is an awesome tool for debugging, hands down.  Unfortunately, it is Firefox specific and has to be installed on the clients machine.

Firebug lite is great, but it is extremely limited and provides little more than a logging console.  pi.debugger sits somewhere in between.  It’s not as full featured as firebug, but it does provide the ever useful evaluation console as well as a DOM browser.

Check it out here:

http://code.google.com/p/pi-js/

And test drive it here:

http://kodfabrik.com/app/pi.debugger/