Christian Effenberger has a Christmas contribution for us, Quickchoice:
Quickchoice is a Speed Dial clone for css transform supporting browsers.
It’s a simple and quick “public domain” implementation of Opera’s Speed Dial.
Currently useable with Safari 3.2 and probably Firefox 3.1 -
through the http-protocol.
For personal use you need to save the html file (save as) and push to
your htdocs folder (localhost) or upload via ftp to your domain!
David King has created a small JavaScript library dlink that styles your links to let the user know if the link is internal, external, a subdomain, an anchor on the same page, or an email link.
I started creating an operating system like user interface in JavaScript. I had intended to use it for the admin sections of my content management system(that runs this website), but through developing it I started to question it's usability and decided to discontinue development.
Features in it's current state:
Start Button
Task Bar - view open windows and set focus/minimize
Windows (Create, move, maximize, minimize, resize, etc.)
Show Desktop on right click
Properties (Theme Color, Text Color, Background Color, Background Image)
Properties saved in cookies for next visit
Still don't know how to create a new window other than a Google one, and I am never quite sure when people will use these (even fully baked). I am sure it will happen, but not until the browser platform has gotten to a point where it actually can. Calling this an "OS" is funny too ;)
Thomas Fuchs and Amy Hoy are back with another web site, this time Freckle, a new take on time tracking.
Thomas posted about it on his site and shared that it uses an early build of scripty2 which lead me to peak around on GitHub. It looks nice indeed.
You can see the evidence of Script.aculo.us throughout the UI. The calendar morphs between months as you flip around. Jumping between headers rolls around nicely (e.g. reporting mode from insertion). Inline modal popups. Nicely done.
I noticed the new iPod Engraving Gallery that is a nice use of Coherent to show a slick UI with engraving suggestions.
I was also talking to a friend that has leopard beta bits and he was playing with an updated Dashcode. It appears that the Coherent library is now used for the widgets too. Yay data binding!
One of the more mesmerizing websites I've worked on recently was for a lingerie boutique in the UK. Aside from the unenviable task of having to look at pictures of women in lingerie all day, I was also forced (forced!) to write a bra size calculator.
The theory behind bra size calculation is arcane and somewhat magical. Understanding of it does not come easily to man nor beast, so it is lucky that I, falling cleanly into neither category, have passed through pain and torment to save you the trouble.
After hours of testing he came up with the BraCalculator:
Damian Wielgosik has created Drawter, a web based tool to layout pages:
Drawter is a tool written in JavaScript and based on jQuery library. It provides you the possibility to literally draw your website's code. It runs on every single web-browser which makes it really useful and helpful. Each tag is presented as a layer you have drawn.
Currently Drawter is available in Pro version, which means that it is intended for webmasters use only - knowledge of HTML and CSS is required.
Drawter is not a tool for laymen, for the time being, but the whole team behind the project is putting every effort to launch a new version called "Amateur". Soon you will be able to draw your websites without any knowledge of HTML or CSS. Launching soon, really soon.
He has a detailed screencast of the tool in action where you see how you can flip between draw and edit modes to build up your page. Nicely done!
Julius Eckert has renamed and relaunched chosr to keyboardr.
keyboardr is a homepage. It speeds up your internet experience. And if you like, it helps you keeping your hands on the keyboard.
In the first place keyboardr is a meta-search. You get Google, Wikipedia, Youtube altogether. The instant search and the keyboard navigation are replacing the feeling of “searching” with the feeling of “launching”.
For the future we have big plans for keyboardr:
keyboardr will utilize much more webservices. Among from usual websearch services like google, we are planning to support friendfeed, delicious, twitter, flickr, google docs and many more. And in the final stage, we will have an extension system, open for any developer, to integrate any webservice into our interface. So keyboardr will be a central station for you to get all your common internet tasks done much faster.
It is a nice showcase of an Ajax and mashup application. I am curious to see if it will get uptake. Having a launcher that lives in a web page may not be enough. In comparison, Ubiquity as an addon can do so much more. You want to do the cool stuff from any page, in any application, and you want to be able to write your own extensions. keyboardr has a good start showing the FriendFeed extension, and with an open API it will be good to see what gets added.
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.
