Auto-Building YUI 3 Custom Modules

The details of my development strategy to automatically build YUI 3 Custom Modules that I outlined in my talk at YUICONF 2009.

YUI 3’s modularity and instance sandboxing invites developers to create their own custom modules, breaking apart their specific application logic.

Diagram depicting the categories of YUI 3 modules on a scale from general to specific

YUI 3 Modules Categories from General to Specific

Having developed over 30 Custom YUI 3 Modules in the last year I quickly realized I needed a sane way to go from writing code to running it in the browser. So, I set out to connect the YUI Builder with my IDE.

For the last three or more years I’ve been using Aptana Studio IDE for HTML, CSS, and JavaScript code development. Aptanta, which is built on Eclipse, can be used standalone or as a plugin to Eclipse. The concepts here are not specific to Eclipse; the details of my technique on implementing the concepts are however.

Goals and Reasons

  • Synchronize UI building with the rest of the project code.
    Compiling of JavaScript (when needed) should occur along with any server-side code compilation. IDEs such as Eclipse, ‘Build Automatically’ a project’s Java code; I want my YUI 3 Custom Modules to ‘Build Automatically’ as well.
  • Faster turn-around.
    I don’t want to switch from my IDE to another program to run builds on my UI code. The IDE should recognize when it needs to re-build my UI code. I want a process where I: hack… hack… save… refresh-browser…
  • Easier for non-UI developers.
    Teams of developers are usually working on a shared code-base; a mixture of server-side and client-side code wrapped up into one project. If the UI code is built automatically, like the server-side code, the non-UI developers won’t bitch don’t have to do anything UI-related.
  • Cmd + S = JSLint, Compress, & Deploy.
    Anytime the source file(s) to a YUI 3 Custom Module change, the YUI Builder tool runs, giving me: JSLint-ing, YUI Compressor-ing, and YUI 3 Module wrapping.

Continue reading ‘Auto-Building YUI 3 Custom Modules’

Simple Tab View with YUI 3

Tab Views (i.e. tabbed-content) are ubiquitous on the web.

Examples of tabbed content areas from popular websites

Tabbed content is everywhere on the web

These interface elements are super simple to implement these days, so it seemed useful to show how a simple Tab View could be created using YUI 3.

The HTML Markup

The markup is a navigation list linking to content sections in the content area; simple and semantic. Some CSS classes are added to help with the layout, styling and JavaScript hooks.

<div class="tabview">

	<ul class="tabview-tabs">
		<li class="tabview-active"><a href="#content1">Tab 1</a></li>
		<li><a href="#content2">Tab 2</a></li>
		<li><a href="#content3">Tab 3</a></li>
	</ul>

	<div class="tabview-content">
		<div id="content1"><p>Content for Tab 1</p></div>
		<div id="content2" class="tabview-hidden"><p>Content for Tab 2</p></div>
		<div id="content3" class="tabview-hidden"><p>Content for Tab 3. bla bla bla…</p></div>
	</div>

</div>

The JavaScript Using YUI 3

Using the Y.Node Class made adding the behavior a breeze.

When a tab is clicked:

  1. I add the tabview-active CSS class to it and remove the class for all other tabs.
  2. I then find the corresponding content section and remove the tabview-hidden CSS class from it and make sure all the other content sections are hidden.
YUI().use('node', function(Y){

	Y.all('.tabview').each(function(){
		this.delegate('click', toggleTabs, '.tabview-tabs a');
	});

	function toggleTabs (e) {

		var tabview = e.container,
			tabs = tabview.all('.tabview-tabs li'),
			contents = tabview.all('.tabview-content > *'),
			tab = e.currentTarget.get('parentNode');

		contents.addClass('tabview-hidden')
			.item(tabs.removeClass('tabview-active').indexOf(tab.addClass('tabview-active')))
				.removeClass('tabview-hidden');

		e.preventDefault();
	}

});

Working Example

Screenshot of the Simple Tabs Example

The example using this code

View working example

RGBA — IE Fallback

I’ve been using RGBA color values, border-radius, and box-shadow CSS3 features all over in my current projects. Since Internet Explorer (6, 7, & 8) does not support any CSS3 features I wanted to find some suitable fallbacks. RGBA color values are the most important (of the three CSS3 features I’m using) to find an IE-alternative; without one, IE will inherit the last non-RGBA color value (which maybe no color value, i.e. transparent).

A great article, Working With RGBA Colour, recently appeared on the collaborative web development blog: 24 Ways. The ‘Supporting All Browsers’ section of the article fell short of describing a robust way to “support” IE without punishing the other browsers.

Falling back to a PNG

In cases where you’re using transparency on a background-color (although not on borders or text) it’s possible to fall back to using a PNG with alpha channel to get the same effect. This is less flexible than using CSS as you’ll need to create a new PNG for each level of transparency required, but it can be a useful solution.

Using the same principal as before, we can specify the background in a style that all browsers will understand, and then overwrite it in a way that browsers without RGBA support will ignore.

h1 {
	background: transparent url(black50.png);
	background: rgba(0, 0, 0, 0.5) none;
}

Drew McLellan, 24 Ways: Working With RGBA Colour

I had a feeling, as did Martin Klepsch, that this code would result in downloading black50.png in browsers which wouldn’t even use/need it (i.e. non-IE browsers). Running tests and investigating alternate fallback techniques for RGBA color values in IE shined some light on this issue. Continue reading ‘RGBA — IE Fallback’

Web Application Development with YUI3

The slides and video from my talk at YUICONF2009.

This talk discusses techniques for deploying YUI 3 custom modules within a larger server application environment, using a working application as a reference. You’ll learn how to streamline your development and deployment process, ways to organize your code for maximum efficiency, how to integrate with the Eclipse IDE, and some tips and tricks around build strategies and server-side tooling.

Slides:

Video:

Web App Development with YUI 3 from Eric Ferraiuolo on Vimeo.
…The video is also on the YUI Theater.

Facebook Style Overlay in YUI 3 & CSS 3

While wandering-around the Internet looking for examples of overlays in web application interfaces I thought of a challenge: create a working Facebook–styled overlay. I’m in the process of creating an application-wide design for overlays and needed some inspiration. Facebook uses overlays extensively and they have a distinct style [that others imitate, maybe even me :-) ]; I set-out to re-create this style.

Not wanting to mess around — I whipped up a working example of Facebook-styled overlays using only YUI 3 and CSS 3; things are nice and easy to do when you use the latest technologies.

The code is short enough I’ll just lay it all down here:

The JavaScript — YUI 3 is doing all the heavy lifting

YUI().use('overlay', 'dd-constrain', function(Y){

	var fbOverlay = new Y.Overlay({

		contentBox : '#fbOverlay',
		width : '540px',
		height : '300px',
		visible : false

	}).render();

	// make overlay draggable
	new Y.DD.Drag({

		node : fbOverlay.get('boundingBox'),
		handles : ['.yui-widget-hd']

	}).plug(Y.Plugin.DDConstrained, { constrain2view : true });

	// show overlay
	Y.get('#show-fbOverlay').on('click', function(e){
		if ( ! fbOverlay.get('visible') ) {
			fbOverlay.align(this, [Y.WidgetPositionExt.TL, Y.WidgetPositionExt.TR]);
			fbOverlay.show();
		}
	});

	// hide overlay
	Y.get('#hide-fbOverlay').on('click', function(e){
		fbOverlay.hide();
	});

});

Oh, and if you didn’t notice these Facebook–styled overlays are drag-able; Facebook doesn’t do that…

The CSS [3] — This is all me… and Facebook’s colors

#fbOverlay { display: none; }

.yui-widget #fbOverlay {
	display: block;
	background: rgba(0, 0, 0, 0.5);
	border-radius: 6px;
	-moz-border-radius: 6px;
	-webkit-border-radius: 6px;
	padding: 10px;
}
#fbOverlay .yui-widget-hd {
	border: #3B5998 1px solid;
	background: #6D84B4;
	color: #fff;
	padding: 0 10px;
	cursor: move;
}
#fbOverlay .yui-widget-bd {
	background: #fff;
	border: #555 1px solid;
	border-top: none;
	border-bottom : none;
	padding: 0 10px;
}
#fbOverlay .yui-widget-ft {
	border: #555 1px solid;
	border-top: none;
	background: #f2f2f2;
}
#fbOverlay .yui-widget-ft > div {
	border-top: #ccc 1px solid;
	padding: 5px 10px;
	text-align: right;
}

If you View Source you’ll see the contents of the overlay are in the (X)HTML; I’m making sure the hide these overlay–contents until the YUI Overlay Class instance grabs them up.

Not much to it; the only CSS 3 stuff is in the second rule, background: rgba(0, 0, 0, 0.5); giving the background some transparency and border-radius: 6px; to round-them-corners. Funny thing, these two style declarations save so much time and effort; look the source for Facebook’s overlay and you’ll see a nasty-mess of tables.

If you missed the link to the working version of the code above: here it is again.

Adaptive CSS-Layouts: Compromising Ideals

Smashing Magazine recently published an article posing a question [as it's heading]:

Adaptive CSS-Layouts: New Era In Fluid Layouts?: “Fluid web designs have many benefits, but only if implemented correctly. With proper technique, a design can be seen correctly on large screens, small screens and even tiny PDA screens. With bad coding structure, however, a fluid layout can be disastrous. Because of this, we need to find ways to work around most, if not all, of the cons of fluid design.”

(Via Smashing Magazine.)

Intrigued, I read through the lengthly article; which, seemed to answer the posed question positively; or at least suggested the possibility of a yes answer.

The article is a prescription of six “effective techniques to create 100%-functional adaptive CSS-layouts” (quoted from article). These techniques are not independent from one another; they must be used together, and implemented correctly to achieve their prescribed solution to the Adaptive/Fluid layout problem.

All of these techniques can be implemented in one design to create a very user-friendly fluid layout. A smart use of the fluid grid can create an adaptable layout whose proportions remain faithful to the Rule of Thirds, balance and other design principles…

I’m left dissatisfied with Smashing Magazine’s solution. Spending time to understand and apply six different, seemingly independent, layout techniques to an interface feels too compromising. The one-size-fits-all approach to User Interface design leaves you compromising on crucial interface components and aspects of usability. The interface for a web site/application on a computer isn’t going to best serve a user on their iPhone; users with a computer screen resolution of 800×600 are rare; users with wide-screen monitors don’t browse at full screen.

Contorting the development of one interface to serve vastly different devices is not ideal. To achieve a better, more usable interface you must design for the device. I’m not buying the idea that we, as web developers and designers, can get away with forcing our compromised interfaces on user’s screens big and small.

I posed a somewhat opposing question about layout— regarding it’s flexibility, in October 2008: Layout Flexibility – Still A Requirement?

Questioning my own pervious layout techniques and use of Elastic Layouts (em’s to specifying box-model dimensions). Concluding that the adoption of full-page zoom in modern browsers leaves the elastic-layout technique obsolete.

Writing HTML From JavaScript

JavaScript developers know the DOM API sucks: very verbose, and hairy across browsers. Some JavaScript library developers have chosen an innerHTML— approach for dynamically writing markup (DHTML). I’d argue this is just as crazy as trying to use the native DOM API.

Some [including me] are fed up with either alternative and decide to create a new API for writing markup in JavaScript:

Jeethu: “One of the sweetest parts of Mochikit IMO has been Mochikit.DOM. This is something which I’ve always missed with YUI. innerHTML is fast, but icky and it feels a little inelegant. So, I ended up writing something like Mochikit.DOM for YUI while writing Tagz. Thought it might be useful to others as well. So, here’s the mercurial repo with the code.”

(Via A Mochikit style Dombuilder for YUI | Jeethu’s Blog.)

Jeethu has something here; but I’m not psyched about the API design. The simple example on his blog post lacks clarity; the nested tree structure feels overly complicated. When creating a document in (X)HTML, nesting makes sense, you’re authoring the document as a whole thing. When programatically outputting (X)HTML, there isn’t a clear vision of the document as a whole. I prefer to keep with the semantics of programming when generating markup by writing meaningful statements.

At Oddnut Software, my small company (just two of us), we’re thinking about this issue with a broader vision: a unified API for writing XHTML on the server (Java) and on the client (JavaScript). We plan to open-source our project once it’s ready; we’re working out some of the final features.

Webpage Thumbnails — Screenshots via Page Glimpse in JavaScript

For quite some time I’ve had a desire to fetch screenshots of webpages in thumbnail form. My last round of development in the area involved a somewhat overly complex solution using Amazon’s AWS Alexa Site Thumbnail service. I chose to integrate with the AWS Alexa Thumbnail service over other services because it just returned an image, no extra crap (Snap’s thumbnails are grotesque) and no ads. Although the service wasn’t free, it only cost a few pennies to use.

The other requirement I have is to retrieve the thumbnails in JavaScript. This lead to the creation my Ajax Alexa Thumbnails project. The AWS Alexa Thumbnail service required a client to interact via a XML web service (similar to the other AWS services), this means signing the request with your AWS credentials; something I wasn’t going to do in JavaScript. The project became too complex for the task; it involved making an Ajax request to a local PHP file which dealt with sending the request to and receiving the response from Amazon. Crazy I know, which is why I’m deprecating the Ajax Alexa Thumbnails project along with the deprecation of the AWS Alexa Thumbnail service in favor of my new solution [below] using Page Glimpse. Continue reading ‘Webpage Thumbnails — Screenshots via Page Glimpse in JavaScript’

Smart Polling

I’m working on the rich UI of a small web application which has a problem I need to solve: the data from the server which the UI is presenting could change at any time. The first iteration of the UI has a refresh button. Clicking this button sends an Ajax request to a resource on the server which responds with a JSON data structure, and the UI is updated with any changes in the new data. My business partner doesn’t like the refresh button; he questions why it’s there and states how annoying it is to press the button all the time. His suggestion is the rich UI should smartly poll the server for changes to the data, and update the UI automatically.

Intrigued by his idea, we continued our discussion leading to a definition for what it means to smartly poll a server’s resource:

  • Use conditional GET requests
  • Retain the most recent Etag and Last-Modified date of the polled resource
  • Disable polling when the browser window is inactive

Implementing a smart polling process in our application’s rich UI gives us some desired benefits:

  • Removal of the refresh button
  • Automatic updating of the UI when the resource on the server has changed
  • Less repainting of the page since the DOM is touched only when the data has changed
  • Changes to the UI only happen when the window is active (the user sees them) as polling is paused while the user is doing something else

Creating a reusable component to achieve a smart polling process feels like the correct approach as I foresee a need to use this functionality in future projects as well. Continue reading ‘Smart Polling’

The Sun Amongst The Clouds

Sun Microsystems now has a cloud-based computing business. Not only are they going to start offering cloud-based services similar to that of Amazon AWS and Rackpsace Mosso; they’ve also released a Cloud API specified with RESTful HTTP and JSON. Maybe more interesting than the technology choices, is that Sun is releasing it as an open-source project licensed with Creative Commons Attribution.

Tim Bray, the Director of Web Technologies at Sun Microsystems, blogged about his involvement developing the API:

The Sun Cloud: “This is a unified view of the storage and compute and networking services. It’s built around the notion of a ‘Virtual Data Center’ (VDC), which contains networks and clusters of servers and public IP addresses and storage services. The idea is to give you the administrative and operational handles to build something really big and ambitious. The VDC notion is really slick and I think something like it is going to be required in any serious cloud API going forward.

At the bottom level, the interface is based on HTTP and tries hard to be RESTful. All the resources—servers, networks, virtual data centers—are represented in JSON. [Don’t you mean XML? -Ed.] [Nope, JSON is just right for this one. -Tim]

(Via ongoing.)

After reading Tim’s post, I went directly to the Cloud API project site on Kenai and read all the docs for the API specification. Reading the specs raised some questions, most of which others were already discussing in the forums. I’m really digging the RESTful HTTP with JSON APIs. It just feels more natural then the Amazon AWS APIs.

Sun is retaining the separation between the APIs and the implementations and encouraging other cloud providers to also implement their APIs. Potentially allowing a client to have interoperability between CSP (Cloud Service Providers). I feel similarly about CSPs adopting Sun’s Cloud APIs as I do with JavaScript libraries adopting the Sizzle JavaScript Selector Library; i.e. Amazon AWS should provide an implementation of Sun’s Cloud APIs, or someone should write an adapter.

While the Cloud APIs are still in-flux, they are defiantly on the right path here. Sun is listening to the community while taking the feedback seriously; great to see from a big company with their open source project. Sun is stepping up the game by providing not just cloud-based resources, but an API built on current technologies (RESTful HTTP and JSON) and allowing any cloud-based service provider to use it.