YUI Carousel Component (2.6.0)

On October 1, 2008 Yahoo! announced the release of YUI 2.6.0. This
release contained the official YUI Carousel component.

As you know, the intent of my carousel component was to fill in a gap in the YUI library. In 2006, I created the ycarousel component. Thankfully, many people have found it useful over the last 2 years.

Before I left Yahoo! in 2007, I spent some time with the YUI team,
discussed the ideas behind the way I approached my component, what I
liked about it and more importantly what I did not like about it :-)

The newly released YUI component shares some of the same
properties/api with my component but has been written from the ground
up. So I am excited about their
new carousel and encourage everyone to migrate to it instead of using
the carousel shown at this site.

The fact is you will get better support for their component. I am just
too busy with other projects to really support it the way I would like
and there is just no reason to cloud the space with two components
(even named similarly ;-)

You can find the new YUI Carousel component at the YUI library site.

The latest version of my carousel can be found at my site.

Why Protoscript?

Ok, the last thing in my mind when I created Protoscript was for it to be YAT (yet another toolkit).

I have been asked several times what really makes this different than toolkits like jQuery. And what is the compelling reason that someone would use Protoscript.

The motivation is straightforward:

• Prototyping is too hard for non-techies

The reasons Protoscript can help solve some of the difficulties with prototyping are as follows:

• Simplifying how we express interactions is a good thing
• Behavior injection is a powerful iterative design tool
• Plug-in Behaviors guarantee a growing set of prototyping solutions
• By focusing on prototyping, things get simpler
  

Prototyping is Too Hard for Non-Techies
The end goal of Protoscript is a simple GUI that will allow non-techies to:

• Go to any web page
• Sprinkle simple to complex interactions onto that page
• Do all this without writing code, but simply through an intuitive interface

I am a huge proponent of breaking down the barriers for the non-techies among us to be able to do what us techie geeks can do.

I have been fortunate to work with some awesome talent, many of which do not have the skills, the time or patience to prototype in Javascript.

Do I want to exclude them from the party? No.

If I can let more team members literally play with a working site and tease out better interactions then I have raised the state of the art (even if ever so slightly).

Simplifying how we express interactions is a good thing
By allowing an interaction to be expressed in a consistent, stylized declarative fashion (JSON) a whole set of goodness becomes available:

• Widely variant interactions captured with same simple syntax
• Nested syntax communicates the relationship between behaviors, events, callbacks & attributes
  
• Non-programmers can read Protoscript better than JavaScript code. jQuery comes the closest to making Javascript readable by non-programmers (see discussion below on Protoscript and jQuery).
• It is a lot easier to write a GUI tool that reads and writes JSON than it is to read/write Javascript. (This is why so many tools use XML or JSON since they are declarative formats)
• JSON can be sent over the wire. This means a simple REST service could serve up and/or save JSON to remote services.
• JSON is easier to parse
• JSON is easy to write out to a database or as a flat file

Behavior Injection is a Powerful Iterative Design Tool
The Protoscripter bookmarklet is the first step in providing behavior injection. It allows you to popup the bookmarklet on any web page and type or paste in Protoscript code to inject interactions. (You can get it from the Protoscript Home page.)

Here is a fun example of this... Watch as I experiment with burritophile.org (mind you this is a contrived example)



Beyond the bookmarklet, it should be straightforward to create a Greasemonkey script that loads Protoscript (Alex Russell's suggestion) or a Firebug extension that adds prototyping to Firebug (Steve Souders led the way with YSlow) or a full on Firefox extension that brings palettes of behaviors to a page and adds smart element selection to make behavior injection simple.

And of course the extensions also open the door for being able to save the configuration to your desktop and recall/edit as needed.

Plug-in Behaviors guarantee a growing set of prototyping solutions.
Non-partisan, extensible plug in architecture allow an ever-growing set of interactions. Out of the box I support YUI as the behavior set (behaviors, events, callbacks and attributes) and jQuery as the selector mechanism (supports CSS selector syntax and XPath). But Protoscript allows you to add any number of new behaviors, write your own behavior set on other Javascript toolkits and plug in a different selector query mechanism.

This means that Protoscript is really not in opposition to tools like jQuery. I really like jQuery. I have always been a fan of syntactical sugar. It lessons the cognitive load when writing code.

jQuery has a powerful chaining and filtering mechanism that allows you to control the scope of elements you are applying behavior to.

Some of the advantages of Protoscript over jQuery for prototyping are:

• In jQuery, behaviors are passed parameters and since they can vary in the number of parameters that get passed to them it is not easy to parse, stylize of guess at what must be passed. Protoscript promotes the parameters to be attributes in the JSON thus making the syntax the same across all behavior plugins. Since they are attributes they can also be read by external gui tools to automatically create a GUI interface
• Protoscript uses a nested syntax instead of a single line of chained code. This allows protoscript to express chained behavior, changing scope and attaching behaviors & events (both can be done easily in jQuery). Where the JSON syntax gives a novel twist is now you can express in one interaction set a number of serial as well as chained actions.
  
• Event expression is richer in JSON since you can express multiple events in serial fashion along with multiple callbacks thus capturing the forking nature of interaction as a tree instead of a single list.

Now I hasten to add that I do not believe Protoscript in anyway replaces jQuery. That in my mind is wrong and missing the point. Heck, I wrap jQuery and use it for my query selection (but not for behaviors, callbacks, etc. in the YUI reference implementation). jQuery does more in raw power than Protoscript ever aims to do.

Quite simply I am focused on prototyping. jQuery certainly can be used for prototyping. I just think that for all the reasons above it made sense for me to take a different approach.

By focusing on prototyping things got simpler
Protoscript just says, hey what if we did not try to everything that you need to do write a full-blown application... but instead focused on what you need to do to prototype.

When I looked at it that way it simplified the building blocks and the way you might hook them together.

The design of the JSON syntax was actually driven by the way I imagined the prototyping GUI tool would look like. That is certainly a different approach than most toolkits take. And the only reason I could take that approach was because of the laser focus on prototyping.



Doesn't this make sense?
Look, I have created this and plan on continuing to grow and expand its capabilities. I have no aspirations to replace what anyone else is doing. I have struggled with this problem for over 25 years and especially the few years trying to bring richness to the web.

I have tried to make this as non-partisan as possible.

Hopefully others will create behaviors around their favorite toolkits (or adapters to their behavior sets) so that the GUI tools built for this will be able to seamlessly use them as well.

Announcing Protoscript

Wow. It has actually been 2 months since my last post. Nope. I have not fallen off the planet. This has been one of the craziest times I have experienced in a long time so while I have had a lot to chat about I have not had the time to blog coherently.

One of the projects I have been working on is a way to make it easier for all of the non-techies (as well as techies) to be able to experiment with various interactions on a web page in lightweight manner.

By lightweight, I mean to say a way to take an existing web page or a prototype of a web page and "sprinkle" rich behaviors to play with concepts. Ideally you should be able to express an interaction in a declarative manner without having to write JavaScript directly (but not kept from it if you need to). And even more ideally you should be able to build up the "legos" of interaction in simple GUI tool embedded in the browser so that you are not encumbered with even a simple syntax to type in.

So back in July, I was slated to give a talk at the Ajax Experience. I promised a few months before that I would have 2 new talks. One on Anti-Patterns (yes I owe several blog posts on that one) and the other on prototyping.

The problem was exactly one week before both talks I had literally had not time to put those talks together. So I dropped out for a few days to create a very early version of what is now protoscript. The good news was that it was actually fully functioning and I gave a peek of it at the conference.

I got a lot of good feedback from the talk and went back and rewrote it a couple of times, changed up some of my approach, moved to a plug-in style architecture, etc.

So, ok, what is protoscript?



Protoscript is a simplified scripting language for creating Ajax style prototypes for the Web. With Protoscript it's easy to bring interface elements to life. Simply connect them to behaviors and events to create complex interactions.

The key abstraction that came out of my thinking was to express everything as objects (think HTML elements), behaviors (think patterns) and events (both events and callbacks).

In some ways it is similar to jQuery. And in fact I use jQuery for the selecting of elements. Protoscript, however, is a very stylized way to describe interactions. This makes it ideal as a building block.

For example, since the language is so simple (It is actually in JSON format) it makes it easier to extend to multiple toolkits (currently I use YUI, but I have built a simple example with Mootools), add new behaviors and events and even more importantly be able to build GUI tools on top of it.

As a first hack I created Protoscripter a bookmarklet that brings a GUI interface to any web page allowing you to play with protoscript (without any installation, other than the bookmarklet) and experiment with interactions.

I have been careful about pushing protoscript out because of this layering approach. Ideally I would have the whole stack. I would have a complete GUI as a FF extension allowing designers, product marketing or web devs to quickly sprinkle interactions onto their prototypes and quickly iterate to the best design. Well that is not reality. I have invested about 2-3 weeks of time so far and feel I have gotten it to the right level to release to the public.

There are 31 behaviors, 40+ live demos, a simple GUI tool (protoscripter). The scripting engine seems to be pretty solid (knock on wood). I have a full wiki with full documentation on all those behaviors. The code is over in Google Code in a repository ready for open source contribution.

So to kick it off I am giving a talk this morning at the Rich Web Experience here in San Jose. You can get a PDF version of my talk here: Prototype Presentation.

And most importantly start checking out prototoscript.com (right now the best experience is in Firefox).

Carousel - 0.4.0

New release of carousel. More documentation, better runtime configuration support, methods that let you show, hide and recalculate size.

Check it out at the carousel site.

Designing a Component

I’ve designed a number of software widgets, components and gadgets throughout my career. In the early days of Mac programming I created small desktop accessories and my own set of components to enhance my application development (e.g., geographical map component, 3D graphics library).

Later in the days of Motif I wrote numerous components (spreadsheets, charts, directed graphs, server-side grids). I also made a trek through the TCL community creating components for the incr Widgets set.

I spent several years working in the world of Java Swing building components (in fact I built at least three completely different component sets for three different companies—thank God that we now see more things getting open sourced!)

I finally ended up in the land of web development taking trysts through HTC components, JSP/Struts components (tag libraries) and finally pure JavaScript components. There are a lot of lessons I have learned over the years in how to create useful components. There are three that stand out in my thinking:

• Make the component specific in purpose, yet flexible in use.

Avoid the do-everything component. Instead make it do the main thing well. But make it pragmatic by keeping it flexible.


• Separate the concerns of interface, interaction, and content.

Avoid hard-coding visual style, give flexibility in the interaction model and provide flexible ways to manage data content. Keep these three areas independent to allow them to be customized separately.


• Document the interface and use the component before releasing it.

You know the experience. You think you have a great idea. Then when you go to explain it to another person you immediately see the holes in your logic. Documentation provides a way to explain your interface; writing demos allow you to exercise the component to test its ease of use and flexibility.

Make it Specific yet Flexible
Make the component specific in purpose, yet flexible in use.


The agile community expresses the idea of simplicity over over-generalizing. One of the traps that people fall into is trying to build a component that does everything. Not unlike feature creep in application development, a component can collapse under the weight of too many features. One of the sure signs of this is when certain parts of the API start competing with other parts of the API.

As an example, let's look at the carousel. It is just a simple list view manager. You can actually make the carousel look like a tabset or a slideshow. However, I chose not to provide additional tabset or slideshow functionality. Why? I knew from experience that the interface would become unwieldy. Lots of new configuration parameters and methods would get added that only made sense if you were using the carousel strictly in slideshow mode. You can imagine that with enough features, some of the API would only apply to these tangential behaviors. The result would be a carousel component that ends up with portions of API that don’t even apply when the carousel is behaving “just” as a carousel.

A nice way to keep a component flexible is by providing a simple configuration mechanism. The Yahoo! UI library provides a Configuration object for just this purpose. (The first time I saw this mechanism in popular use was with the Prototype library.) Instead of having to pass lots of parameters to the carousel’s constructor (new Carousel()), you pass in a configuration object. The configuration object is really just an object that contains parameters and values encoded in JavaScript object notation. Here is an example from the wrap example:

   var carousel = new YAHOO.extension.Carousel("dhtml-carousel",
       {
           numVisible:        4,
           animationSpeed:    .8,
           animationMethod:   YAHOO.util.Easing.easeBoth,
           scrollInc:         3,
           navMargin:         40,
           size:              17,
           loadInitHandler:   loadInitialItems,
           prevElementID:     "prev-arrow",
           nextElementID:     "next-arrow",
           loadNextHandler:   loadNextItems,
           loadPrevHandler:   loadPrevItems,
           prevButtonStateHandler:   handlePrevButtonState,
           nextButtonStateHandler:   handleNextButtonState,
           wrap: true
       }
   );

Each configuration parameter has a default value. If the user provides a configuration parameter it is treated as an override and is applied to the internal set of configuration values. The carousel then uses these values in its operation.

Keep Concerns Separate
Separate the concerns of interface, interaction, and content.



If you have read other articles on my blog or heard me speak you will notice that I often fall back on this idea of separation of concerns along the lines of interface, interaction and content (or data). Sometimes I express it as feedback, interaction and information. And often I just state in the way I first learned it from the boys at Xerox as simply Model-View-Controller.

When I wrote the carousel I started with the basic understanding that I was creating a list view manager. The underlying HTML structure I chose to control was an “unordered list” (UL & LI HTML tags). Keeping my thinking general in this matter allowed me to separate several areas of concern. Here is how this concept of separation played out in the carousel.

1. Flexibility of Visual Style
First I wanted to provide flexibility in the component’s presentation. One of the ways I did this was by putting all style choices into a stylesheet (CSS). It’s really easy to hard-code style choices into the component logic. By placing style considerations externally you can help fulfill the first point above – keep it flexible. The other way the presentation was made flexible was by providing configuration parameters that select the way items are displayed. Control over the number of visible items, the animation speed and method, the size of a page of information, and the orientation are all ways that the carousel is flexible enough to adapt to most environments.

2. Flexibility of Interaction
Second, I decided that the interaction should be completely flexible. I did not want to constrain it to my choice of navigation controls or method of user interaction. In most of the current examples, previous and next arrow buttons control the carousel. While this is the normal case, it is easy enough to allow mouse over events drive the interface. The carousel exposes the same interfaces it uses internally. You can simply wire your events to the same internal mechanisms used by the carousel internally.

Microsoft Altas (now called Microsoft Ajax Framework) does a nice job of separating behavior from its components. For example, they isolated the behavior of auto complete from the components. This means that if you add this behavior to say a text field you would have an auto complete text field. It also means that you can write your own components and by obeying an interface contract, have your component support this behavior. In essense the interaction is packaged as a separate entity and just attached to the component needing the behavior.

3. Flexibility in Content
And third, I felt that there had to be flexibility in the way content gets displayed in the carousel. The simplest mechanism for this was to allow developers a way to shove their own HTML into any item in the list. The innerHTML technique is very useful in this regard. It is very friendly to PHP, JSP, ASP and other page generation techniques. It’s also the native way to express an interface on the web. What this means is that each “item” in the list could be a complete page of content, a single photo from a photo stream, a set of form elements—in short anything you want a “list item” to be it can be.

Another dimension of content is in how the data actually gets loaded. By externalizing the loading mechanism through a set of function callbacks (functions that you write that let you decide how to load the initial set of data and fetch the next and previous set of data) the component is able to support static data, client side generated data or server-side fetched data (e.g. via Ajax). Recently someone wanted to wire the carousel up to RSS feeds. Even though I had not considered RSS feeds, since the data loading was externalized, it turned out to be a fairly trivial exercise.

Test by Documentation and Usage
Document the interface and use the component before releasing it.



Alan Cooper advocates that designers design in pairs. One takes the role of Interaction Designer (ID), the other the role of Document Communicator (DC). In design sessions the ID takes the lead role in pitching ideas. The DC tries to capture the ideas and wherever there is difficulty in capturing or explaining the idea it is forced to go through some iterations to make it easier to communicate. The idea is that by having to explain your ideas. This doesn’t just work in designing user interfaces, but it also works in designing programmer interfaces.

As I am writing this blog post I am sitting next to Luke Wroblewski on a flight back from Lisbon. He saw this point in my article and reminded me of a post he wrote a while back on Nine Lessons from Nine Years of Interface Design. One of the lessons he notes is that “writing it down forces you to think it through.” On this point he summarize three good reasons for writing it down:

• Solidifies the approach. Guards against localized decisions.


• Articulates the rationale. Puts the solution in context of its use.


• Ensures clarity. If you can’t explain it, then nobody else will be able to either.

I find the exercise of both documenting and writing demos for components to be refreshing. It gives you a chance to come above the code cloud and both talk to the user and be the user of the component you are writing.

I finished the first version of the carousel in just 2 days. I spent the better part of the next 2 days writing documentation and creating demos for it. All during that phase I was constantly going back and rewriting parts of the code. Documentation can seen as a kind of test-first strategy for writing APIs. Writing demos is a good way to create tutorials as well as experience what it is like to really use your component.

Of course the biggest caution I would have about trusting too much in the demo applications you write is to realize that they are only demo applications. It really takes being exercised in several real world examples to fine tune an interface.

This lesson follows something that we try to employ at Yahoo! We call it “eat your own dog food.”

The phenomona of Yahoo! Hack Day has had a profound impact on the web services and APIs throughout Yahoo! (I would go so far as arguing that this has been the biggest impact of Hack Day—causing our services and APIs to become more robust.) When the Hack Team attempted to put together a combination of our APIs (events, maps, search, etc.) they discovered just how many things were missing. The creation of just that one demo pushed the discussion of what needed to be added or corrected—-and the result is a much richer API available to everyone (public included.)

Carousel Updates - Wrapping, Auto Animation, etc.

New update to the carousel component.

Now supports wrapping at content end as well as an autoplay feature. Read the docs to find out all the gory details. 4 or 5 new examples of what you can do with the carousel.

I have had several people request styling navigation differently or providing different types of navigation. Its important to realize that these concepts are externalized from the carousel to provide the most flexibility. The carousel is really just a content scrolling mechanism. As such one can simulate stock tickers, news carousels, scrolling lists, news tickers (as in gmail), slide shows, advertising carousels or even a module tab set.

Check out all the examples and docs at:

http://billwscott.com/carousel/index.html

Carousel Component - Y! UI Library Example

Ok, so I have been extremely, extremely remiss in writing up what has been rattling around in my brain lately. So I have some pretty good excuses (lots of talks, lots of work, writing for the yui blog, writing various articles, lots of family visiting and so on.) But I have always felt that it was better to share something on this blog when I felt like I had something worthwhile to say (or share.)

So just a week back I took on a weekend 'geek' project. For a project at work we needed a carousel style component. Here is an example:



I started on a Friday morning and was essentially finished on Sunday night. Although I will confess that I have tinkered with it on and off over the last week or so.

I think this component is fairly flexible and does a good job of illustrating how to write a component for the Yahoo! User Interface library.

I was going to wait and write up an article explaining how the component is built. But until I can get that post together, I will point you to the component and the documentation I have already put together for it.

It's not finished. Probably has some code that could be refactored and certainly could use improvements. Based on my testing it works on most recent browsers. Let me know if it is useful or if you think an extended article given as a tutorial for the Y!UI library using the carousel component would be helpful.

Check the out the carousel component here.