Cameron Adams has another fun Javascript experiment in JS-909, a drum machine he built from scratch. It plays sound without Flash, along with a check that your browser is capable of playing sound this way, and also includes a little canvas-powered psychedelic graphics engine.
At the recent Web Directions JavaScript libraries panel, I was in charge of representing the hard-working non-library hacker. (Of which there exist approximately two in the wild.) And when it came to the final exercise – the one with the aim of blowing people’s minds – there was but one thing I could do: make a drum machine. Without libraries. Without Flash.
I’m fully aware that there’s muchbetter ways of working with sound on the Web, but I’m also fully aware that I like making useless toys. The result of these two realisations? JS-909.
Sound comes via the <embed> tag, relying on native browser functions:
for (var sound in sounds)
{
var embedContainer = document.createElement(”div”);
embedContainer.className = “embedContainer”;
document.body.appendChild(embedContainer);
embedContainer.innerHTML = soundElementString(sound, sounds[sound]);
}
I recently found it’s possible to combine this no-flash sound technique with data: URLs, so you can build audio web apps without Flash and offline, running from a single file. It’s all very experimental at this stage though.
Chris Vanrensburg has added a nice little effect at Zazzle. Mouse over a product in the results, and you will see it zoom in for a closer look. Ben and I often talk about the zoomable UI that Apple uses in their store (and many others) and how it makes shoppers feel like they can see a lot more of the product and sense that they are really interacting with it. This hopefully leads to more sales as you don’t get the “hmm, don’t know if I can buy this online” feeling.
Chris talked to us about the features, including the implementation:
On the technical front one of the major requirements for that feature was to have little (ideally zero) impact on the page weight and load time. Criteria we considered, in this regard, included things such as:
1) not adding any extra image load to the initial page load (so, none of the larger images are loaded in initially - they are loaded on demand when the effect is activated)
2) not adding any extra DOM that would add to initial page render time (so the extra DOM node used for the zoom & pan effect for each cell is added dynamically when the effect is activated)
3) not adding too much to initial page wiring time (so, progressive wiring of cells to defer impact to when effect is activated)
4) not adding too much extra JS code (so, just efficient implementation and good code reuse satisfied this requirement).
Other UX requirements were…
1) It should be discoverable (accomplished with this implementation, because if someone’s interested in something, they will contemplate going to the product page and, therefore, hover over the cells and discover the interaction).
2) Operation should feel intuitive and “lightweight” (so, no added control UI needed for the interaction). Our user testing found that users learned quickly how to pan, understood the interaction well, found it compelling, and quickly became addicted to inspecting every product that way.
3) Shouldn’t create a minefield. We wanted to ensure that users wouldn’t develop an aversion to the results grid (potentially disastrous for sales). We didn’t want to deliver a seizure inducing experience every time the user moves their mouse from one side of the screen to the other, so there is a rest delay before the effect is activated. This is different to a hover/mouseover duration threshold, in that the user needs to have rested the mouse for a minimum amount of time (easily configurable, we used 150ms) before the effect is activated - long enough to prevent triggering as the mouse moves around, but short enough that the user doesn’t become impatient.
4) We didn’t want an experience that would add obscuring overlays on top off the grid and risk the user creating a clutter that might frustrate them and that they might not be able to recover from / clean up. We deliberately wanted to “contain” the experience within the real estate of each cell, to not have the interaction block other results from view (ala a lightbox UX), potentially contaminating the user’s receptivity to adjacent results and potentially creating confounding data points in our conversion metrics.
Some other points…
1) Zoom level was designed to be easily configurable, but we chose 2.5 (too high a zoom and the interaction starts to feel very touchy / sensitive to mouse movement).
2) An early version of the effect switched immediately to the zoomed image with pan activated. Ultimately, we decided that the zoom in animation was key to the user understanding the effect when they experience it for the first time, and not feeling disoriented by immediately being thrust into the higher zoom level where they may lose the context for what they’re seeing.
3) Immediately as the effect is activated, lowsrc is used for the zoom node so that the already loaded and cached smaller image is stretched to stand in as a proxy for the larger image while it loads (so, no waiting to load the large image before the zoom effect is initiated - it starts immediately once the mouse rest threshold is crossed).
Needless to say, search is a critical link in the flow that leads to conversion and revenue, so we didn’t approach adding this feature lightly. Fortunately, we looked for - and found - other areas that could be performance optimized in the search results page to buy some budget for the new feature. That, combined with heavy emphasis on a low impact approach to the implementation, allowed us to add this enhancement to the results page while simultaneously doubling the number of results in the grid from 15 to 30, while still achieving a small performance improvement in the page.
Nicholas C. Zakas has posted about a new Yahoo! home page that uses YUI 3.x. They are currently testing the new home page out, but having it use the latest and greatest dogfood on a web page as trafficked as the Y! home page is a big deal. Save a few bytes here or there and you are talking serious benefits. Anyway, Nicholas talks us through some of the benefits that he saw:
I felt that building on YUI 3 would make implementing our design much easier based on several goals that we had for the framework:
Eliminate global dependencies. We wanted each part of the page to operate separately from all of the others. Each part should have no knowledge of what else is on the page and therefore can’t depend on objects to be globally available. The 2.x library is based on the global YAHOO object, which we would have had to abstract away; the 3.x concept of YUI instances that could be individually manipulated worked perfectly to achieve this goal.
Make it small, make it fast. The Front Page can’t afford to be slow, so we needed to have as little code as possible to get everything up and running. YUI 3 impressed us with its organization into small, atomic units that allowed us to specifically include parts of the library that we wanted while eliminating parts that were unnecessary. Further, one of the goals of YUI 3 was to optimize for runtime execution and make it faster than the 2.x version. Once again, YUI 3’s approach was directly in line with the Front Page’s goals.
Create version independence. From the start, we didn’t want to have dependencies on specific versions of YUI components as this can lead to maintenance issues. What we really wanted was for each part of the page to be able to use whatever version of the components that they wanted. The sandboxing feature of YUI 3 opened up the possibility of having two (or more) YUI instances each loading different versions of various components while not interfering with each other.
Allow code portability. Having worked at Yahoo! for a combined five years, Steve and I knew that anything we put on a Yahoo! property could be a candidate for porting to someplace else. We knew that this possibility meant the code had to stand on its own and not make assumptions about the environment in which it was placed. We thought about the most difficult environment possible: a locked-down browser environment where the JavaScript code has no direct access to the DOM. Since YUI 3 can abstract away the DOM through its Node interface, we had the entrypoint necessary to make this requirement a reality.
Be forward compatible. The project to create a new Front Page is an incredibly long one and we wanted to be as forward-looking as possible. We knew that if we created the framework on YUI 2.x that we’d be hard pressed to get time to upgrade later on. By building on YUI 3 from the start, we eliminated the need for developing an upgrade path later on.
Greg Sherwood sent us a link to a video showcasing MySource Mini, a web-based content management system with a super-sexy Ajax interface:
A short demonstration of the MySource Mini showing some of the amazing new features that differentiate it from other CMS products:
- True inline WYSIWYG content editing
- Inline editing of complex asset types
- Built-in graphical audit trails
- Content versioning with browser screenshots and PDF downloads
- Integrated context-sensitive help
One of the cooler features is a forth-coming open-source editor framework that allows arbitrary text nodes in the page to be edit-in-place, firing events as necessary, etc.:
Viper is different to other WYSIWYG editors in that it is not only completely written in JavaScript, but also does not use the browser’s editable region. All changes are made to the DOM directly and everything has been hand-coded, right down to the flashing caret. This gives the MySource Mini a true inline editing interface where the WYSIWYG editor is integrated completely into the editing mode.
Check out the video; like Fluxiom before it, it shows just how sexy Ajax applications can be.
There’s also another video that goes into more detail on the app.
I have seen some of the great applications that SitePen produces, but unfortunately too many of them are for companies behind the firewalls.
It is great to see Sensei a really compelling Dojo application that SitePen wrote for their training class. This isn’t one of those simple training examples that you normally get though. This says quality.
Revin Guillen explains:
When conducting Dojo training courses, we’ve found it to be very valuable to go beyond simple code snippets to demonstrate APIs, patterns, and other key concepts. Snippets and demos are useful, but they often lack a very important quality: context. Nothing beats having a full application in front of you—with code available to read and modify as you learn the ropes—so we built the Dojo Sensei Reader, a rich, powerful RSS reader realized as a single-page web application.
We designed Sensei specifically for training sessions. We wanted something that demonstrates the major areas of functionality Dojo offers, but as a single cohesive application rather than a collection of unrelated demos. We wanted something small enough that training groups could easily grasp the entire codebase, yet large enough to be worth using as a real-world application. We wanted something that shows the development process from start to finish, to demonstrate the level of polish you can achieve in a Dojo-based application. Beautiful as well as functional, it does all of this while providing a great, fast user experience.
One of the beautiful things about Sensei is that it proves that you don’t have to sacrifice maintainability to build a fast application. One key goal in our development process was to create an easy way for training groups to introspect the code, follow the app as it works, and even modify or augment its behavior at run-time by swapping code in and out. To deliver on this, we designed and integrated what we call Blox, a small JavaScript package with the power to make it all possible (it’s Sensei’s flux capacitor; we’ll cover it later). The result is a codebase that is very easy to work with but incurs negligible performance impact for its trouble.
Here’s an interesting link for a Friday. Viktor Zeman on Quality Unit sent us a link to “PostAffiliateXpress“, some boring IT application with an interesting interface and an even more intriguing back-end.
The UI combines a Vista-like “Start” menu along with an OS X-like dock (using everyone’s favorite fish-eye widget). It also has a built-in widget system that leverages Google Widgets. Overall, it’s a pretty nice implementation of a desktop and windowing in Ajax.
The framework itself is “GwtPHP” which attempts to take all the advantages of GWT and deploy them to PHP backends in an attempt to solve the problem of limited Java-friendly hosting services. Unfortunately, the framework isn’t available for use until sometime in early November.
Dual-License
The developers intend to use the familiar “free for hobbyists, pay up for commercial use” licensing model (what their licensing page calls a “what for what” model).
Give some feedback
Viktor says that they are quite keen to get feedback from folks on the project, so interested folks should get in touch, let them know what you think about the licensing model, and perhaps get early access, etc.
SproutCore jumped onto the scene when MobileMe launched to much acclaim on the visual side (even if the back end couldn’t handle the load).
It doesn’t seem to be a one-hit wonder, especially in the field of e-mail. OtherInbox “provides consumers with a free email account that automatically organizes newsletters, social networking updates, coupons and receipts from online purchases”, and showcases SproutCore again.
If you are looking to build desktop-looking applications, it is worth giving SproutCore a look.
Ruven Pillay has updated the JavaScript image viewer that we posted on awhile back. We asked Ruven what he has done and he told us:
Well, I’ve just released a new version which updates the libraries to Mootools 1.2 and adds a whole bunch of useful features like navigation buttons, a draggable navigation window and the ability to create layers.
I’ve also tried to push javascript to it’s limits and build an advanced visualization application around the IIPMooViewer. There is a demo of a multispectral viewer, which allows you to blend between different kinds of scientific imagery of the same painting. For example, you can blend between a normal colour image and an X-ray / UV or infra-red view. You can also view the spectral curve at each point on the painting when you click on the main image. The whole thing is pure javascript (using Mootools) with the graphing done using Canvas/VML via the MooCanvas library.
Scott Schiller (SoundManager 2, cool games, and dhtml guru) shows that Flickr still has a lot of fun left in it. They have given a sneak peek at a new home page and you can migrate that version.
If you click on the link:
Then you will get an inline popup, and you will start to see some Flickr snow, and you will hear something courtesy of SoundManager 2. It’s a small thing, but this is what the Web is about :)
Tripeedo is a new little site that uses Prototype to power a command line for travel. You just type in where you want to go and when, and it will launch you into a search. I really enjoy the command line interfaces, and much prefer them to the long forms that travel sites put up for you. The calendar components normally always suck.
Tripeedo is a showcase of the wundrbar that has been customized for the world of travel.
Chosr is another Quicksilver inspired piece of software, that lives in the Web, created by Julius Eckert using GWT.
Very interesting to see the interactions, although I wonder a little on the usage. The great thing about Quicksilver is that you hit a quick key combo and you are there. You type what you need, and you are sent off again.
In this case, Jacob has created amazing visualizations of the data using JavaScript and Canvas:
I figured it would be a nice little experiment to try visualizing this data using JavaScript and Canvas so I went and did just that. The data is simply point clouds, meaning a whole bunch of points with x,y,z values (and intensity) for each frame. The data on Google Code is about 800 MB, so obviously a bit of trimming had to be done. You can’t expect 30 fps with Javascript doing with this kind of data, so I’ve only used every 5 frames giving us a framerate of 6 fps, not great but acceptable. Then the actual points, each frame has about 12,000 points. No way this will render with 6 fps in any browser, so again I’ve taken only 10% of the points. Additionally, I’ve tried to filter away the noise around Thom Yorke’s head since that took up a good deal of points. The interesting bit is him singing, anyway. In the end, we have a dataset of about 4 MB (converted to a JS array) for the one minute clip they released.
Now the data is in a more manageable state and the visualization can begin. It’s not as good as the real thing, obviously, but I think it’s ok (it’s best when you look at Thom in profile). The audio clip is as usual played via SoundManager 2 which also gives us free timing information to sync the rendering to. I’ve played around and made a few different effects that you can toggle on and off (by pressing keys 1-9). While it is playing you can also rotate around the vertical axis by moving the mouse horizontally over the video. Also try clicking/doubleclicking.
Great publicity for Radiohead too. When you are first to do something, that is often the case.
Thomas Fuchs and Amy Hoy have teamed up again for a micro-app called Creativescrape “an inspration utility for those moments when you just seem to be braindead. It comes with a OS X screensaver for your enjoyment.”
All via 188 lines of fun living on top of Prototype and Script.aculo.us.
// Update the values for the next time a gesture happens
width *= e.scale;
height *= e.scale;
rotation = (rotation + e.rotation) % 360;
}
Some readers might have noticed that a gesture is just a prettier way of looking at touch events. It’s completely true, and if you don’t handle things properly, you can end up with some odd behavior. Remember to keep track of what’s currently happening in a page, as you’ll probably want to let one of these two operations “win†when they come in conflict.
