I’ve been meaning to mention this for a while, but was waiting on a couple post-launch releases that added some “extras” that I liked.

NikonUSA.com was re-designed and re-built by my company, Molecular. We launched in late February and this was a total overhaul: new CMS (Interwoven LiveSite/TeamSite), new design, and plenty of custom code. I built the entire front-end here, from the overall architecture to writing XSL to build HTML to build pages.

There’s lots and lots of custom stuff I wrote from “Quick View” overlays to DOM stylesheet manipulations, and plenty of YUI, awesomebox, and yCarousel to go around, too.

Cool stuff to look for:

• “Product Detail” page— This one mashes up YUI’s tab component, custom flyout code that I wrote, ycarousel, awesomebox for lightboxing images/swfs/video, and all kinds of loading magic. The D300 serves as a nice example. Take a look at that “Media Bar” right there! Plenty of jazzy stuff.
• Pages I designed: the low-bandwidth homepage and search results page.
• JavaScript-to-XML-to-Flash (built by Alisdair Mills) on the homepage.
• Product views, sample photography, and other images being cranked out by ImageMagick scripts that I wrote (ah, Perl!).
• Liberal uses of iepngfix for good old IE6.
• Plenty of tricks (view source) to add in browser-specific stylesheets and extra print media targeting.
• The CSS-only top nav. Tried and true but always nice to show as cross-browser.

I’m most proud of being able to wrangle some nice, semantic HTML in there. The “AJAX” features feel natural, too, something I always like to do in an app: the lightboxes and carousel presentation makes sense and feels right in context; it doesn’t feel “bolted on”, like these flashy bits sometimes do. I can also now give dissertations on Flash/DHTML layering, ImageMagick, and many other cool things.

I may add a few posts describing bits and pieces of functionality in the future; the front-end here was huge, and I built a lot of stuff (and trained users, and designed pages…). But, it’s still a launch!

Tags: nikon, nikonusa, design, build, launch, javascript, html, flash

One method deserves special attention: elementFromPoint(). This method expects two coordinates and then reports which HTML element is located at these coordinates. This is a godsend for drag-and-drop scripts. If the user drops an element, get the mouse coordinates and use this method to find out which HTML element is located at these coordinates.One catch: you first have to temporarily hide the dragged element, because otherwise elementFromPoint() would always report the dragged element — after all it itself is the topmost element under the mouse.

Google Reader (1000+)

PPK reports on the new W3C CSSOM spec. I’ve wanted a getElementFromPoint() method forever.

Tags: dom, css, javascript

Ernst & Young have just launched a site that I had a hand in building. EY Insight is a college prep tool for students interested in a career at EY. It’s the closest I’ve seen to a true JavaScript and Flash hybrid, mixing them together so well that you can’t really tell them apart. And, this is true high-fidelity JavaScript animations sitting on top of full-screen Flash video: they are damn smooth and look damn good all the while!

Why is it cool? It’s one of the first sites I’ve seen that mashes up JavaScript (in this case YUI) and full-screen Flash video. There’s some pretty complicated Flash/JavaScript interaction going on, and I really haven’t seen too much like it. (Thanks SWFObject and Alisdair Mills). This is the biggest YUI app that I’ve launched, and brings a nice, high profile to how much fidelity you can get out of a JavaScript app.

What did I do? With the design/UX team, I helped drive the interaction design for this one, especially the Picture Yourself app. Really cool, snappy, sensible interactions there: this is how to make a quiz "not boring". I also did a lot of the JavaScript heavy lifting (a big chunk of the JavaScript back-end and the Object modeling) as well as the bulk of the Flash / JS interaction work before helping David (below) when I could spare a minute or two.

Props to David Tong of Molecular’s San Francisco office, who was the sole full-time engineer on the project for doing some really nifty work.

Yes, I snuck in conditional compilation on this, too. Another interesting note: IE6 has some interesting issues while trying to destroy Flash objects and Flash streams. Seems to orphan them a lot. This might be worth another post in the near future.

Tags: yui, launch, production, ajax, flash, video

The W3C gives us the First Public Working Draft on HTML5, and outlines what exactly we’ll see that’s different from good ol’ HTML4. Really cool stuff here, on a semantic, mark-up geek level. I’m as exctied about input type="email" as anybody.

Edit: Snook points out that using the HTML 5 Doctype will automagically put IE into "IE 8 mode" without the use of the meta tag.

Tags: html

CSS+Javascript power. Fancy menu. Really nice Flash look-and-feel in JavaScript, which means “I have something that looks cool that will degrade gracefully.” Very bouncy and round. I was right when I thought it used the famous Sliding Doors technique for its stretchiness, which means I follow A List Apart too closely. (via Molecular colleague Paul Irish.

technorati tags:mootools, menu, stolenlink

For all you obsessive designers that feel the need to style every possible form input (thus making the web browser look and feel exactly like the Mac’s Aqua interface).

File inputs (
) are the bane of beautiful form design. No rendering engine provides the granular control over their presentation designers desire. This simple, three-part progressive enhancement provides the markup, CSS, and JavaScript to address the long-standing irritation.

Styling File Inputs with CSS and the DOM // ShaunInman.com

I’m all for making things pretty. However, users have been trained for a long, long time to expect things like file inputs to look and feel a certain way. Are our designs worth retraining users or bending users’ expectations for how these things should behave?

(via Ajaxian).(Also, the top Flash thing on that site with the trick makes me sea-sick, in a “wow, that’s cool” way. :-)).

technorati tags:design, forminput, css, javascript

I dug up this blog post while trying to tweak Aptana’s performance on my (old) laptop. Check out the first comment to the post; following those recommendations really sped up and improved Aptana’s performance. Definitely worth trying, especially if you’ve got an older machine.

technorati tags:aptana, eclipse

I’ve been building an animation-heavy demo here at work using YUI. Initially, I was using the old “give the animation a duration and let the computer figure things out. But, that doesn’t yield a smooth animation: in fact, it can make things kind of choppy, especially if lots of animations are running at the same time.

That’s when I did a little bit of digging into the YUI Animation object, and it’s timing options. I’d noticed the useSeconds flag kicking around, but I’ve never really used it. I gave it a shot, and it’s great.

var b =  new YAHOO.util.Anim(ch,{
    height:    { to: 175 },
    opacity:   { to: 1.0 },
    top:       { to: 10 },
    width:     { to: 175 }
},
.700,
YAHOO.util.Easing.easeOut);
b.setAttribute('useSeconds',false);
b.animate();

We’ve created b, an Animation, and told YUI that we’re not using seconds, we’ll be using frames instead. The .700 in the duration parameter refers to the number of frames that we’d like to use; the decimal is multiplied by 1000. In this case, that gives us .700 x 1000 or 700 frames. We can fudge this value as much as we’d like, getting the exact number of frames we need to make everything super-smooth (761 or 445); you just can’t get this level of detail using time-based animations.

I’ve now got super-smooth animations, right down to the very frame.

technorati tags:yui, dhtml, animation

As a Aptana fan, it’s time to tout one of its features. (Prerequisite: download the app. It’s a really good IDE that becomes a must-have app if you’re doing anything with RIA or Rails, as they’ve merged RadRails into their larger project.)

In the Aptana perspective of the IDE, click the little yellow triangle with an exclamation point in it, right under the top menu bar on your screen. See a bunch of little yellow triangle icons and bars appear around the document you’re working on? Those are warnings; they show you things your should fix to improve your code and knock out minor bugs (missing semicolons in your JavaScript, missing alt attributes on your images, etc.). Improve your code! Click the yellow triangle!

Just for the heck of it, I’ve been messing around with YUI’s Drag and Drop utility. In the past, over on Phondoo, I’d used Dojo’s Drag and Drop implementation, so it took a little bit of work to get used to the YUI way of doing things.

The essential difference in the two is that Dojo’s implementation is more widget-y (if that’s a word) while YUI’s implementation is more customizable. Dojo Drag and Drop more or less works out of the box; with the YUI version, you’ll have to write a bit more custom code to achieve the out-of-the-box Dojo effects. However, because it’s so customizable, you’ll be able to really turn it into an application with a look-and-feel that’s all your own.

Because bulleted lists improve readibility, here’s pretty much exactly what I just said, all bulleted out for scanability:

• Dojo’s widget-ness– Without any customization, you’ll be able to do a lot more with Dojo’s Drag and Drop. Basically, Dojo’s provided a fill-in-the-blanks kind of implementation, where you create a couple objects, and bang! it all works. With YUI, you’ll need to write more code.
• YUI is more customizable– YUI’s Drag and Drop API has a lot more exposed, especially in regards to event bubbling: you’ll be able to access more points in time during an interaction cycle with YUI.
• YUI has a more open API– You have a lot more access with the YUI drag and drop API. Event bubbling aside, you can more easily customize (or choose not to implement) pieces of the Drag and Drop cycle, which leads to code that fits your situation better.

Which works better? Well, if you’d like to get up and running right away, Dojo’s widget-y implementation is your choice. If you’re not afraid to write some code, YUI will give you a more robust, customized solution. In all, once you’ve gotten used to (and learned to enjoy and take advantage of) YUI’s event bubbling you’ll find that these hooks can make all the difference in your application (they provide many more opportunities to have your code do something when it needs to be done). Both implementations are very nice, work very well, and, although I’d give YUI the edge, come recommended.

technorati tags:yui, dojo, draganddrop, javascript, dhtml