var icon = Raphael("picker", 23, 23).colorPickerIcon(11, 11, 10);
icon.attr({cursor: "pointer"}).node.onclick = function(){
document.getElementById("benefits").style.visibility = "visible"; var out = document.getElementById("output");
out.style.visibility = "visible";
// this is where colorpicker created var cp = Raphael.colorpicker(document.body.offsetWidth / 2 - 150, 250, 300, "#eee", document.getElementById("picker2"));
Aaron Newton of MooTools fame is now at Cloudera, the awesome Hadoop startup, and has posted about the rich Cloudera Desktop project he has been working on.
In the post he discusses the implementation and how it uses new features in the new MooTools 1.2.4 release such as:
MooTools Depender
MooTools ships with a dependency map that powers its download builder. The modular nature of the library yields itself to custom builds, putting together a library specific to the task at hand. This allows MooTools to power, for instance, a mobile application with only a small amount of JavaScript. For the Cloudera Desktop, we knew we were going to end up with a LOT of JavaScript, and loading it all on startup didn’t make much sense. Instead, we authored the Depender application. It’s an easy-to-deploy, real-time library builder and dependency mapper. This allows our application to load with a minimum of JavaScript. When users launch specific applications, Depender loads any dependencies for that app that aren’t loaded already, and then display the application. In addition to the server side component (available in both PHP and Python/Django), there are two client side components: a stand alone version to be released in MooTools 1.2.4 and a server side application that ships with a client that talks to the server for you, which lets you do this slickness:
Depender.require({
scripts: ['DatePicker', 'Logger'], //array or single string for one item
callback: function(){ //your code that needs DatePicker and Logger } }); //later, you need to load more dependencies...
Depender.require({
scripts: 'Fx.Reveal', //array or single string for one item
callback: function(){ //if, for some reason, Fx.Reveal is available already, //then this function will exeute immediately, otherwise it will //wait for the requirements to load
$('someElement').reveal(); } });
MooTools ART
MooTools at the moment doesn’t have an official, public UI system, but that’s changing, and in no small part due to our contributions to the MooTools ART project. MooTools ART is an in-development UI library that currently outputs canvas. It’s an abstraction of the canvas API and it allows developers to make style-able UI elements like buttons, windows, and icons. At the moment it only outputs to canvas (limiting its support to browsers other than Internet Explorer), but we’re working on wrappers for VML and SVG.
In addition to these drawing tools provided by the ART API is a widget-based system that has numerous features including keyboard management, event bubbling, custom styling, and more. This widget system is the foundation for many of our UI elements, though not all of them. While the basic ART API was developed by the core MooTools Team (of which I am a part), we’ve contributed most of the widgets available in the library built with that API, including a window manager, a history interface, pop-ups for alert, confirm, and prompt, split views and more.
What are the major changes in MooTools 1.2.4?
Browser feature detection favoured over browser user agent sniffing
Added Trident 6 (IE8) detection
Request can take an instance of URI as a url
JSON.stringify and JSON.parse native methods are now accessible
DomReady always fires before load event
Fix for creating a Request in early versions of IE6
Sprockets is a build time Ruby tool that reads in your JavaScript files, preprocesses and concatenates:
It takes any number of source files and preprocesses them line-by-line in order to build a single concatenation. Specially formatted lines act as directives to the Sprockets preprocessor, telling it to require the contents of another file or library first or to provide a set of asset files (such as images or stylesheets) to the document root. Sprockets attempts to fulfill required dependencies by searching a set of directories called the load path.
It is created by Sam Stephenson, and he tells us why you may be interested to use it:
Extract reusable code and share it across multiple web sites or applications.
Speed up your site by automatically concatenating JavaScript into one file.
Organize your JavaScript source code into multiple commented files and directories.
Use bleeding-edge framework and library code in your application.
Sprockets is documentation-friendly
The preprocessor uses a require/provide pattern (Dojo has dojo.require(), dojo.provide() and can do build time and runtime work):
require
Use the require directive to tell Sprockets that another JavaScript source file should be inserted into the concatenation before continuing to preprocess the current source file. If the specified source file has already been required, Sprockets ignores the directive.
The format of a require directive determines how Sprockets looks for the dependent source file. If you place the name of the source file in angle brackets:
//= require <prototype>
Sprockets will search your load path, in order, for a file named prototype.js, and begin preprocessing the first match it finds. (An error will be raised if a matching file can't be found.) If you place the name of the source file in quotes:
//= require "date_helper"
Sprockets will not search the load path, but will instead look for a file named date_helper.js in the same directory as the current source file. In general, it is a good idea to use quotes to refer to related files, and angle brackets to refer to packages, libraries, or third-party code that may live in a different location.
You can refer to files in subdirectories with the require directive. For example:
//= require <behavior/hover_observer>
Sprockets will search the load path for a file named hover_observer.js in a directory named behavior.
provide
Sometimes it is necessary to include associated stylesheets, images, or even HTML files with a JavaScript plugin. Sprockets lets you specify that a JavaScript source file depends on a set of assets, and offers a routine for copying all dependent assets into the document root.
The provide directive tells Sprockets that the current source file depends on the set of assets in the named directory. For example, say you have a plugin with the following directory structure:
Assume plugins/color_picker/src/ is in your Sprockets load path. plugins/color_picker/src/color_picker.js might look like this:
//= require "color"
//= provide "../assets"
When <color_picker> is required in your application, its provide directive will tell Sprockets that all files in the plugins/color_picker/assets/ directory should be copied into the web server's document root.
Build time constant replacement
You may need to parameterize and insert constants into your source code. Sprockets lets you define such constants in a special file called constants.yml that lives in your load path. This file is formatted as a YAML hash.
Continuing the color_picker example, assume plugins/color_picker/src/constants.yml contains the following:
/* Color Picker plugin, version <%= COLOR_PICKER_VERSION %>
* (c) 2009 <%= COLOR_PICKER_AUTHOR %>
* Distributed under the terms of an MIT-style license */
var ColorPicker = {
VERSION: '<%= COLOR_PICKER_VERSION %>',
... };
The resulting concatenated output will have the constant values substituted in place:
/* Color Picker plugin, version 1.0.0
* (c) 2009 Sam Stephenson </sam><sam @example.org>
* Distributed under the terms of an MIT-style license */
var ColorPicker = {
VERSION: '1.0.0',
... };
Constants share a global namespace, so you can refer to constants defined anywhere in your load path. If a constant is not found, Sprockets raises an error and halts further preprocessing.
Joining with the Web 2.0 "go-meta" business model that's so popular these days, iWidgets provides a service that lets you build widgets once and deploy them to various popular widget APIs and platforms.
At the heart of iWidgets is a "PowerPoint-like" widget builder that takes strong design cues from Yahoo! Pipes, but as Peter Yared (CEO of iWidgets) says:
then again Pipes looks a lot like Prograph (the original dataflow programming company, where I worked from 1992-1995)
The site transforms the widget you build into:
a native FBML or GoogleGadget/OpenSocial, which are two completely different architectures (serverside vs. clientside), and then call the destination-specific API's for things like persistence whenever possible.
The builder was constructed using jQuery and like Pipes renders the connection lines using <canvas>. Peter shared some of the back story behind building the application:
I wrote the initial builder in [another framework] and found it obtuse. After spending literally a week trying to turn the date picker into a color picker, I threw in the towel. A friend of mine turned me on to jQuery and I fell in love with how clean and fast it was, the way it separates the HTML from JavaScript is beautiful. So I rewrote the builder we had at the time in jQuery in a two week coding session! Soon after that I got funding from Opus Capital, and when I looked to hire people, I found 3 out of 4 of our engineers through the jQuery mailing list. It's funny how things like that work out; I ended up finding total rockstars because they were playing with a cool new library.
Peter also shared some details on the overall development process:
It took us 10 months to build the site, we have had one guy (Richard Hensel) full time on the builder UI with another guy (Jeremy Stanton) on it about 1/3 time, with the rest of his time on the overall site doing the wizards and getting things like the %#$# back button to work. Then there are two guys working on the backend, one on FBML and the other on Gadget/OpenSocial, and we just added a junior AJAX guy. We contribute back where we can, for example Jeremy contributed to the Selectable in jQuery UI. The iWidgets site itself is completely AJAX, data from the server is sent as JSON, and page fragments are rendered with Wicket. We persist the widgets you build as JSON and then transform them on the server into native Facebook, MySpace, iGoogle, etc.
The team has some future plans building on top of an already very cool site:
We have a bunch of features we are rolling out, such as calling JSON and piping the results into different components, repeating table, paging, cut/copy/paste, z-order control, live dataflows in the builder, a background process at amazon that sends out notifications like "joe just shot 2 over par at pebble beach" to newsfeeds to drive virality, more platforms such as the iPhone, etc.
I wonder if this should somehow integrate with Yahoo Widgets, Apple's Dashboard, and other desktop widget platforms... maybe emit a bundle you can download and install into these services?
The new Layout Manager allows you to create multi-pane user interfaces that are collapsible and resizable.
The Flash-enhanced File Uploader control might be known to you from Flickr and and allows you to easily batch-upload files and images with progress bars.
The JavaScript Profiler now has a graphical front-end to make the information more easily understandable
The YUI Data Table performs faster and got new features, including horizontal and vertical scrolling, a paginator class, drag and drop columns and an API to access, add and remove columns.
The Image Cropper control allows you to pick a part of an image to be cropped server-side
The Cookie Controller provides a wrapper for all things to do with cookies
The Slider Control got updated to support multiple handles to define a range rather than just a state.
In addition to that, some of the components left beta status. These are the Get Utility to retrieve scripts and style sheets on the fly, the ColorPicker Control, the JSON Utility to validate JSON, the ImageLoader Utility to load images on-demand to increase page performance and the YUI Test Utility.
The Flash-y folks at Yahoo! have released a slew of Flash and Flex components in their ASTRA suite:
New Flash components:
AlertManager — a user interface component that creates alert windows and manages their queue.
AudioPlayback — a set of controls for audio playback.
MenuBar — a component that renders hierarchical data as a row of buttons with nested menus (using the Menu component)
On the Flex front, we have:
AutoCompleteManager is a component that manages a set of input controls, popping up suggestions when a user types into one of the fields. Instead of replacing TextInput fields with a specific AutoComplete control, you can simply point the manager to one or more TextInputs, and you’ll get a slick pop-up or auto-fill interaction.
Color Pickers:
ColorPlaneAndSliderPicker is a user interface component that allows the user to pick a color value. It combines a one-dimensional color slider with a two-dimensional color plane.
ColorSliderPicker is a user interface component for Flex that allows the user to pick a color value. It combines a set of sliders where each slider represents a component of a colorspace. For example, a ColorSliderPicker displaying an RGB color includes a red slider, a green slider, and a blue slider.
DropDownColorPicker is a user interface component for Flex that allows the user to pick a color value. Similar to the standard Flex ColorPicker control, the DropDownColorPicker also gives the developer the ability to completely change the dropdown control to give the user a variety of color views.
IPv4AddressInput is a user interface component for Flex that allows the user to input an Internet Protocol version 4 address. This control includes a field for each separate byte and full keyboard navigation.
TimeInput is a user interface component for Flex that allows the user to input a time value. This control include fields for hours, minutes, seconds, and AM/PM. Styling options allow the time to be presented in 12- or 24-hour formats.
TimeStepper is a user interface component for Flex that allows the user to input a time value. This control include fields for hours, minutes, seconds, and AM/PM. Styling options allow the time to be presented in 12- or 24-hour formats. Up and down buttons allow the user to increase or decrease the currently selected field.
October has been a busy month. We are currently in a political and emotional roller-coaster that peaked after the ECMAScript 4 Language Overview was released. It is as though EC4 just sprang up, when in fact it has been chugging along for ages. Brendan has been talking about it for some time. At this point opinions are being aired all over the shop and as I finished the last post, I hope we can de-polarise the situation and get to work.
Browsers seem to be taking the charge recently. Webkit keeps adding greatfeatures, and with Leopard we now have Safari 3 churning out.
Mozilla is also branching out with projects such as Prism and Mobile Firefox. IE8 is still dark.
I covered the fact that Sun has announced how they have a new Java Plugin that is in the works. Many still scoff at Applets, which may by itself be the downfall. However, if Sun pulls it off, I think that Applets have a real place on the Web. Before you scoff think about how cheesy little XHR lay dormant for so long. Java down right in the browser can be a nice bridge to advanced functionality where you still can script away in JavaScript.
JavaScript on the Web keeps getting more featureful too though. I was really proud of out Blog.gears example that shows the path for rich read/write mashups, in this case also working offline. The open source Google Caja can also help us have the freedom to allow JavaScript to be in a page and not collide to do evil things. Caja makes a lot of sense when you think about OpenSocial.
All in all a great month, and here is to an exciting November that includes OpenSocial APIs, Dojo 1.0, and more.
Some pickers try to generate the entire color map in JavaScript by drawing a 256x256 grid made of div. This is very slow, which is why color pickers that go the JavaScript route often don't draw the entire map, but instead only 4x4 or 8x8 blocks.
ImageLoader operates on the premise that image data for some images is unnecessary at the initial paint of the page, usually for one of two reasons:
1. The image is “below the fold†— that is, outside of the viewport;
2. The image is in the DOM but will not be made visible until some user interaction takes place, as is the case in some TabView implementations.
In the following video, Yahoo! Travel engineer Matt Mlinac, developer of the YUI ImageLoader Utility, discusses the use cases for the new component along with examples on how to leverage it:
YUI 2.3 has been released with six new components, as well as a skinning architecture and a new look for the components.
Features
Rich Text Editor: Cross-browser support has always been a major challenge for RTEs, and we think you’ll be impressed with how well this editor works across the various environments. You can instantiate it with just a few lines of code for simple implementations
Base CSS: Nate Koechley continues to extend and refine the YUI CSS foundation. Base CSS itself applies consistent and common style treatments for the foundation
YUILoader: A mechanism for loading YUI components (and/or your own custom components) on the page via client-side script.
ImageLoader: Allows you to defer the loading of some images to speed initial rendering time on your pages.
ColorPicker: The Color Picker provides a powerful UI widget for color selection, featuring HSV, RGB, and Hex input/output and a web-safe color-selection swatch.
YUI Test Utility: YUI Test introduces a flexible unit-testing framework for the YUI ecosystem and serves as the foundation for our own unit-test battery.
Version 1.3 is the first to be released with the new open process:
Our open source charter, "Making GWT Better," explained that GWT development would take place in the open, and that we'd even publish our engineering meeting notes. We're happy to report that it's working out really well. We've had many fruitful discussions on the contributors forum, and we've already received and accepted some patches that will make it into the next version of GWT.
As part of the open process you can dip into the development plan for 1.4 which includes items such as:
New widgets: RichText, CollapsiblePanel, DateFormatter, ColorPicker, and more.
Development: True JS output, new Java classes, line precise reporting, and more.
Performance: simple inlining, dead code elimination, optimized bootstrap, and more.
Unfortunately, not all web developers are gifted with a sense of design and color. They code up their pages to work and plan on then worrying about "the fluff" around it when they're done. Thankfully, there are several resources out there to help just such people, including this handy tool from Sharewonders.com.
When you load up the page, you'll see a bar on the left-hand side with a "Show" link at the top. Click that (you'd get the same effect by hitting the "Pull out the color tool" link) and you'll be greated by a simple, clean interface to help you pick coordinating colors surrounding your selection. By clicking on one of the colors in the top row of blocks, you'll see how the areas below populate with the matching colors. The larger color blocks can them be dragged over to the boxes on the far right of the page to create a color scheme for your site.
So it's just another color picker, right? Well, there's a bit more to it than that. When you've selected the colors in the right-hand boxes, you can save them with a scheme name and description and they'll be added to the "Ten Most Recent Schemes" list. They use an Ajax connection to talk back and forthe between the server on this, so the save is seamless. Click on the "View" link next to a scheme and the page will update with those colors.
The site is still in development, so I know there's more features to come. One feature I'd like to see is a few more layouts and color options. I do like that you can "fine tune" the pre-created schemes, making slight changes to the colors until you're happy with them.
At thursday's ajax event, one of the sites recommended for demo was Etsy.com. It bills itself as "the place to buy and sell all things handmade". It has some of the most innovative ajax techniques I've seen on an ecommerce site. Make sure and check out the time machine (my favorite), color picker, and the geolocator.
The widgets linked above are flash, though I think at least a couple of themcould be done in plain old javascript+xhr. The "wow" factor is high, although I don't know how usable they would really be in the long term. It would be interesting to see how much regular shoppers of the site really use the time machine or geolocator, versus standard searching or browsing.
DomAPI is an application-centric development environment targeted at version 5.0 or better browsers running on Windows, MacOS and Linux, written by the authors of JSCruncherPro.
It has a lot of components, and also has an RPC Wrapper. The components need a designer to go through and pretty them up though.
ColourMod is a suite of colour pickers, including a dhtml version (as well as Konfabulator, Dashboard, and I am sure Windows Gadgets soon?).
Why would you use this in an application? Imagine if you were offering a personalized area of your app. You could allow the end user to choose what colours they want to see with this nice little widget.
The DHTML version of ColourMod is free of charge. There’s also a Konfabulator version and a Dashboard version for web developers who need a quick way to pick Web colors, and an unbranded version for $15 that loses the ColourMod logo so you can pretend it’s just another part of your fancy code.
To find the right colors you can check out colr.org
