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

DOMAssitant 2.7 is a solid improvement to the DOMAssistant framework with a clear focus on CSS.

New functions:

• cssSelect
• AJAX
• setStyle
• setErrorHandling
• first

Other Improvements

• Dramatic Improvements to the CSS Selector performance: I personally consider CSS selectors the most important feature of a framework so the dramatic improvements really help sell me the benefits of the 2.7 release.
• Unicode Support.  This can be a really big one for a variety of reasons.  Personally, I think it should be built into all frameworks from day one (It is built into javascript after all).

You can find out more about the new release here:

http://www.robertnyman.com/2008/04/09/domassistant-27-released-better-faster-slimmer-new-features/

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/

Tab Boxes are one of the most ubiquitous and popular of widgets. They pop up in everything from news sites to accounting software and for good reason. After all, tabs are one of the simplest and most efficient ways to cram more into a given block of screen real-estate than would fit otherwise.

Ajax24’s drop tabs replace the normal tab-box behavior concept with a twist. THese tabs pull blocks of content down from a tab bar to make them available and float them above the background content. (think window blinds or drawers as opposed to tabbed sheets of paper). I have a few reservations about the use of a widget with such slightly unconventional behavior. But all in all, the smooth motions of the widget and it’s novelty surely warrant exploration in more playful interfaces.

You can find the widget at

http://www.flash-free.org/en/2008/04/05/e24tabmenu-–-menu-desplegable-ajax/

Firebug and its kin are awesome for debugging javascript, but once our scripts are in the wild we really don’t have any feedback of any kind about the state of the browser.  DamnIT from JupiterIT attempts to alleviate this by providing an automated feedback system for javascript applications.

How it works:

1. A box appears prompting you to describe your most recent actions:
2. One of the following occurs:
   • you type something and click send
   • you click “close”
   • 10 seconds pass with you doing nothing
3. DamnIT emails you the following information:
   • Browser
   • Page
   • HTML Content
   • Description (if you entered one)
   • Error message
   • File name, line number, and stack (if the browser supports them)

On the surface this is an incredible system.  In practice there are a few key issues that I think need addressed before the product is an ideal fit for every situation.  Basically, I have severe reservations about the email only nature of the system and its dependence on central management.  Both of these are key issues when dealing with sensitive information or large volumes of error messages and I’m sure will be addressed with future versions.  I am going to integrate the system into the next release of BLT and will be providing feedback from those efforts in the near future.  In the short term, you can check out DamnIT here:

https://damnit.jupiterit.com 

 As much as I love jQuery, prototype templates have made it into more than one of my projects because of their versatility and ease of use.  They are a capable and amazing tool for formatting and displaying output on the client side and I thought I’d take a few minutes to dive into them.

So what are templates.  In short they are a string with symbols embedded that are replaced at the time of evaluation to create a new string.  For example:

var apple = { fruit: "apple", variety: "honeycrisp" };

var templ = new Template( "My favorite fruit are #{variety} #{apple}s."  );

console.log(  templ.evalaluate( apple ));

>>> My favorite fruit are honeycrisp apples.

This basic example is really all there is to templates.  But, they can be incredibly useful for formatting and displaying JSON data. and repurposing things in universal ways across an app.

It’s been a crazy several months, new town, new job etc…

I’m finally in a position to start posting again, so you can expect semi regular updates from here on.

Hi everyone,

I haven’t been posting lately and I apologize for that.  I’m in the process of orchestrating a move and all the headaches that entails as well as finalizing all of my projects at my current job.  I simply don’t have time for AB right now.
Regular updates will resume in March.

A question emerged out of my boredom on my flight yesterday.  Which is faster, implicit vs explicit conversion.  Most javascript developers use implicit conversion out of habit. For example:

!!x; instead of Boolean( x ); and x + “”; instead of String( x);. 

I decided to try an experiment for myself and record the performance of casting a number to a Boolean or String on my Windows box in Safari 3, Firefox 2, Opera 9 and IE 7.

The Verdict:

Implicit conversion wins handily, demonstrating over a 7 fold performance increase in one test. Overall, the performance gain for using implicit conversion averaged out to 53% across browsers after 10 tests.

The Numbers:

You can find the code I used after the jump.

Keep reading →

ParseInt is one of the handiest universal functions in javascript. Even though javascript’s ability to cast most any primitive to any other primitive on the fly is handy to say the least, sometimes we need to explicitly parse a string to make sure we have a legitimate number to work with.

ParseInt does this for us. What most developers don’t realize is that parseInt is base agnostic. While it typically assumes base ten, any base between 2 and 36 can be used and is indicated by the optional second argument.

Why is this a problem you might ask? Because octal numbers can be represented by a leading zero. In practice this can cause some interesting effects in your code.

For example:

var x = "010";

console.log( x );

console.log( x - 0 );

console.log( parseInt( x ) );

console.log( parseInt( x , 10 ) );

Returns:

"010"

10

8

10

Note: “010″ is equivalent to 10 in  “x - 0″!