Since transitioning to the role of startup founder and open-source developer, communication has become an even larger part of my day. Below is an analysis, including my humble suggestions, for improving the state of your projects by improving your team’s ability to communicate.

Communication is about winning. Whenever you engage someone in communication, it is a competition. Who has the better story? Who can talk/write more? Who has the better code? And if you don’t win, you lose.

False.

Fact: if you win a conversation, then you also lose. This is especially true when your conversation must accomplish some achievable goal.

Actionable discussion

Let’s first define “actionable conversation” as that in which we are trying to achieve some explicit goal, whether to persuade someone of something or to find a solution to some problem.

Now, let’s divide actionable conversation topics as one of two types:

Opinion vs opinion

The majority of the time, there is no right or wrong, only opinion and differing opinion. To consider yourself right here is to disregard the differing opinion as decidedly wrong. Be careful, doing this makes it difficult to ever grow and learn.

Fact (true vs false)

Then there are topics for which there is a right and wrong. Let’s say you and I are arguing the solution to 1 + 1 = 2. You say it’s 2, but I say it’s 3. In a technical sense, you are right and I am wrong.

In the context of communication, though, what is the point of being right if you can’t convince others, or help them to arrive at the correct conclusion with you? If you are arguing with me, then you’ve already deemed it worthwhile to convince me. Therefore, our conversation is not about being right, it’s about convincing me that you’re right. And in this regard, you may be right and still be wrong.

Furthermore, true/false is a zero-sum game; if you win, then I must have lost. And if I lost, then I must not be on the winning side with you. And if I’m not on the winning side with you, then you must not have thoroughly convinced me. Which means, in the context of the conversation at hand, you still lost.

This doesn’t even address the effect “winning” has on your ability to engage me in future conversations.

The only way to actually win a conversation is to make sure we both win.

When arguing fact against someone’s disregard for fact, the best thing you can do is this:

1. Present your facts
2. Listen to mine
3. Acknowledge the validity of my side (even if I’m wrong, there must be some convincing reasoning behind it for me to disregard your facts)
4. Leave it alone. This is called, picking your battles.

In other words, pick your battles.

The only winning conversation is the conversation in which everyone wins. In a game of Ego, the only winning move is not to play.

Persuasion

When trying to affect change, we often need to convince someone to help. There are entire books on the art of persuasion ^[1], so I won’t delve deeply into the subject here. I will instead share one lesson I’ve learned the hard way: Once a person becomes defensive, the conversation is over.

Human intelligence is an interesting thing. We tell ourselves that we employ logic to arrive at conclusions. More often though, we use emotion to arrive at conclusions, and then we mold logic to justify them. Sometimes it’s astounding how malleable logic can be. Once someone becomes emotionally attached to their idea, logic becomes irrelevant ^[2].

The lesson here is to avoid turning any conversation into an issue of right and wrong, because then it is a competition. Competition evokes emotion and entrenches people in opposition. Instead, consider every conversation as an opportunity for everyone involved to grow, learn, and develop together.

Communication and software / engineering

Bringing these concepts back around to software and engineering, every conversation should be viewed as an opportunity to increase the project’s reliability and applicability. If you can increase everyone’s understanding of the project, consider the dialogue a success. This is a subtle departure from the norm, where conversations are started to fix a project that is broken in some regard, or to explain why the other person is doing it wrong.

For example, don’t submit a bug report with the mindset that “this code is bad, causing this bug in this situation.” Instead, think, “here’s an opportunity to make this code applicable for this situation.” This simple change of perspective will come through in your communication and make it much easier for the recipient to react in a positive way.

Communicating with engineers

Enough of the mental voodoo; how do we actually communicate with other engineers?

Engineers and software developers tend to view ambiguity and verbosity as fluff that weakens the point and hurts credibility; we tend to be succinct. However, succinctness and efficiency can easily be perceived as assertiveness and aggressiveness, which can trigger defensiveness and effectively kill the conversation.

In the real world, to prevent others from becoming defensive, we soften our stance with “I think that…”, or “I feel that…”, and use other qualifying terms like, “maybe” or “perhaps”. In the engineering and programming worlds, these can be downright annoying, especially in written form. So we must walk this line. We must learn to understand our situation, audience, and goal; tailoring our message accordingly.

Communication in open-source

Communication can be a barrier to progress from the perspectives of both the user and the maintainer of open-source software.

When submitting patches or bug reports (as a user)

When submitting a patch or bug report, realize that the project is someone’s creation, the product of their time, work, and care. It’s their baby. Their reward comes from others who use and benefit from their work (and the recognition that comes with it). Avoid telling them their baby is ugly.

Make it clear that you see this as an opportunity to improve their project. Avoid making demands which convey entitlement (e.g. “this is a serious bug that needs to be fixed now”). At the same time, don’t powder your prose with disingenuous praise or flattery; this is tomfoolery, and engineers are sensitive to that. (We tend to be easily annoyed).

When responding to patches or bug reports
(as a maintainer)

More importantly, to open-source authors: realize that the worst thing we can do is discourage people from submitting patches or starting and engaging in conversations about our projects.

We often receive bug reports where our first response is, “You’re doing it wrong.” This is discouraging to the submitter and potentially embarrassing. One technique I use in this situation is to assume that I’ve misunderstood the problem. In these situations, I start with some form of, “I don’t think I understand the issue you’re having,” which leads into, “Could this be accomplished this other way instead?…”

Often this yields one of two outcomes:

1. They read through my alternative solution and realize it does work. I usually get some response like, “Oh, you’re right, I get it now, thank you!”
2. Or they explain why my solution won’t work. Now I understand their problem better, and can either pull in their code or start working on a solution.

In either scenario, we’ve both won. In the first scenario, I’ve helped them to grow and learn without embarrassment (a necessary part of a conducive learning environment). In the second scenario, I’ve learned the true nature of their problem by working with them, rather than assuming they were wrong and then having to backtrack — embarrassing myself in the process.

In either case, I try to conclude by making it clear that their time and efforts are appreciated. Even if they were wrong, the fact is that some level of reasoning brought them to that conclusion. Chances are, others are on the same path. Also, they will now be able to apply the sort of reasoning you gave to their next issue.

Open-source authors, remember that people who submit patches to your projects are not saying that you’re wrong or incompetent. If they believed that, they wouldn’t use your project. You have the upper hand in this situation, so it is ultimately your responsibility to ease the tension.

Give every ticket the benefit of the doubt. Instead of immediately concluding that the other person is doing it wrong, assume you don’t completely understand what they’re trying to accomplish. This is an opportunity for everyone who sees the project, to grow.

Pulling in user-submitted patches

One last thing while I’m on the subject. If someone submits a patch that comes close to something you’d want in your open-source project, pull it in!

I’ve seen the following situation happen too often:

1. Someone submits a patch (or pull-request) for some open-source project.
2. One of the project’s maintainers asks a couple questions about the patch.
3. The maintainer doesn’t like some aspect of the submitter’s code, so they implement the solution themselves and then close the submitter’s ticket.

I think one of the reasons this happens is that the maintainer has been on the other side of the fence (being the maintainer of a successful project), for so long, having responded to hundreds or thousands of questions, comments, and commits project. They’ve forgotten how rewarding it is for other developers to see just one of their patches or ideas incorporated.

The next time you find yourself about to do this, I propose a different approach. If their code requires numerous changes, politely ask them to make those changes, and resubmit the patch. To really encourage collaboration, provide them with some guidance or encourage them to further improve their solution.

Protip: On Github, they don’t even need to submit a new pull request. They can make the necessary change(s), amend their last commit (git commit --amend) and then force push to their branch (git push -f myrepo fixbranch). The existing pull request will be magically updated.

If only minor changes are needed, such that it’s not worth the effort of asking them to make said changes:

1. merge in the submitter’s patch
2. make any necessary changes in a new commit
3. push both commits to the public repo at once

If they submitted a patch, it shows they have invested the time and effort to fork your project, figure out your code, research and solve the issue, then make and test their changes. To see their work re-implemented and pulled into the codebase without recognition or thanks is demoralizing, if not altogether insulting.

I won’t say I’m guilt-free of committing such atrocities myself. When I have made this sort of mistake, I’ve tried to make it abundantly clear why. I did this by assuring the submitter their work was appreciated and encouraging them to continue submitting patches and bug reports in the future.

Conclusion

Effective interpersonal communication can be difficult, but learning actionable techniques helps overcome common barriers that prevent progress and growth in open-source, software, engineering, and the world. Above all else, cultivate the habit to recognize how your communication is perceived by your audience in order to increase reception and make your message more effective. Likewise, learn to recognize when your own emotions are preventing you from being receptive to new ideas and possibilities.

TL;DR (too long; didn’t read)

• Communication is important.
• All conversations should be seen as an opportunity to learn and grow, for all constituents.
• Emotion trumps logic; avoid letting emotions enter technical conversations.
• Once someone becomes defensive, the conversation is over.
• Engineers like succinctness. This can be misconstrued as aggressive or rude; walk that line carefully.
• Be courteous but clear when submitting patches or bug reports to open-source projects.
• If someone submits a patch to your open-source project, don’t dismiss their work by re-implementing their patch yourself.
• NEVER discourage anyone from submitting patches or bug reports to your open-source project, or any other.
• Effective communication is a skill worth improving, inside engineering and out.

• Load tabs via AJAX
• Nest tab-set inside another tab-set
• Use non-standard markup for panels (for example, fieldsets inside a form)

See demos for each new feature below

AJAX tab content

It’s been a long-time coming, and it’s finally here. EasyTabs now supports loading content into panels via ajax.

EasyTabs has always placed emphasis on semantic, meaningful markup. Traditionally, markup for a tab/panel pair would look something like this:

Notice that in the above example, if JavaScript is disabled, we’re left with a normal anchor and anchor link in the page, which browsers understand by default.

The easiest way to modify a tab in order to specify that it’s content comes from some ajax url would have been to add an HTML5 data- attribute, such as data-ajax. However, if JS were disabled, we’re now left with an anchor link to an empty div on the page, with the actual url hidden behind a function-less data attribute.

So instead, I took a different approach with EasyTabs. If we want content for a tab to be loading via ajax, we put our ajax url in the href attribute where it belongs, and move the id of the target panel to a data attribute called data-target.

We can also load a page fragment with something like:

By default, EasyTabs will load the content via ajax the first time the tab is clicked, and then hide/show the loaded content in the panel for each tab-change thereafter. If we want to have the tab re-request the ajax content each time it’s clicked, we can set { cache: false } in the easytabs options.

And finally, there are two new event hooks to which we can bind custom functionality, which will only be fired for ajax tabs: easytabs:ajax:beforeSend and easytabs:ajax:complete.

For example:

• 
  View AJAX tab demo

Nested tabs and anchors

We’ve always been able to have multiple instances of EasyTabs on one page. However, we couldn’t previously deep-link to a tab-set which was nested inside the panel of another tab. That is no longer a problem.

So for example, if we had markup such as this:

We can now bookmark Subtab 2 directly, by sharing http://example.com/page#subpanel-2, and EasyTabs will automatically open panel-2 and subpanel-2 by default when the page loads.

• 
  View nested demo

Non-standard markup for panels

Panels no longer need to be div element, they can now be any markup we want. For example, the following now works:

• 
  View custom panel markup demo

Get it now!

Check out the updated plugin homepage to download and view the docs.

• 
  View plugin homepage
• 
  View changelog

The two major changes for v1.0 are:

• New jQuery 1.6 iframe-transport instead of dependency on form.js
• New rack middleware does away with configuration

With the release of v1.0, the new officially maintained repo for Remotipart has moved from here to the JangoSteve fork on Github.

There is also now a more robust test suite. Read more about that in the Remotipart docs.

New jQuery iframe-transport

Previously, the process of submitting files via an ad-hoc iframe element and inserting the response back into the page (described here) was done by the form.js. For those who aren’t familiar, form.js is an awesome plugin that does a lot of really useful things. However, we weren’t really doing it justice by requiring it as a dependency for only one small part of its capabilities.

Also, with the introduction of ajax prefilters and transports in jquery 1.5, there is now a more native way of extending jquery’s standard ajax capabilities. Since I finally removed support for jquery 1.4 in the Rails jquery-ujs, remotipart can safely rely on these new transport protocols.

And so for v1.0, we’ve switched remotipart’s to use the jquery iframe-transport.js instead.

Rack middleware

In remotipart v0.4, we added a railtie (for rails 3.0) and a rails engine (for rails 3.1) to automatically add remotipart.js and its dependencies to the JS :defaults and asset pipeline, respectively. In v1.0, we’ve taken it another step further.

There is now a new rack middleware which sits snuggly between the request and your rails app. It automatically communicates with the iframe transport when needed.

Because the new middleware does all the translating necessary for ajax file uploads, you no longer need the old remotipart_response block in your js.erb response templates.

Additionally, you no longer need to request the JS data-type (you could request other data-types before, but anything other than JS or HTML could be a bit buggy in IE). Remotipart is now compatible with all data-types.

AJAX file uploads are easier than ever

So what does all this mean? It means that AJAX files uploads in Rails 3 are now so incredibly easy, I have no problem dubbing this v1.0.

Let’s say you have a Rails 3 app with a remote form. Everything goes great, but then you add a file input to the form. Suddenly, the form won’t submit via ajax anymore. This is by design, since a simple ajax request is incapable of uploading files.

Just install Remotipart 1.0.

For rails 3.0 apps, run:

For rails 3.1 apps, require remotipart.js in your app/assets/application.js:

Done! The form will now upload the file via ajax no problem.

• 
  View Remotipart Homepage »
  

In my last article, we discussed the difficulties of file-uploads via AJAX, and how the iFrame method works around the issues to provide an AJAX-like interface for uploading files to the server.

So how does this relate to Rails?

Rails 3 uses Unobtrusive JavaScript for remote links and forms (and comes packaged with the jquery-ujs driver via the jquery-rails gem as of Rails 3.1!). However, because jquery-ujs relies on jQuery’s standard .ajax() function, it is incapable of doing AJAX file uploads.

The Remotipart gem

Remotipart to the rescue! The Remotipart gem does two things:

1. When non-blank file input fields are detected in a form, remotipart.js hijacks the remote form submission, and instead submits the form using via form.js’s .ajaxSubmit() function, which uses iFrame technique described in the last article.
2. Secondly, Remotipart provides the remotipart_response block method in our response js.erb views. This method first checks to see if the form was hijacked by Remotipart and was thus submitted in an iFrame, and if so, it returns our generated JS inside a textarea element, so that it automatically gets executed in our parent window.

If you’re curious about the name, it’s a contraction of “remote” and “multipart”, as in multipart forms for file uploading. Pronounced remote-ee-part.

Getting started

Update: Newer versions have been released since this post. See the Remotipart homepage for the most up-to-date info.

New release! Remotipart 0.4 for Rails 3.0 and 3.1

I just released Remotipart version 0.4, re-written to work seamlessly with Rails 3 apps. Among other conveniences, this makes installation much simpler. Also, for Rails 3.1 apps, it now works with the built-in asset pipeline.

Check it out

For installation, documentation, and demos, check out the new Remotipart homepage:

• 
  View Remotipart Homepage »
  

A note on extending Rails jQuery UJS

Because we’ve opened up jquery-ujs’s internal functions to be interactive and configurable, it is now easy to augment and build plugins on top of jquery-ujs. Check out the Remotipart source on Github to see this capability in action.

AJAX file uploads, how do they work?! Well, they kinda don’t.

Browsers don’t allow file uploads via XMLHttpRequest (aka XHR) for security reasons. If we try to submit a form remotely via XHR, it will work, except with the file field stripped out of the request parameters. This sort of partial, silent failure can lead to unicorn black-eyes. (I punch unicorns in the face when I’m frustrated.)

Workarounds

So, there are a couple workarounds that give the impression of AJAX file uploads (and thus the same workflow and UI from the user’s perspective), without actually submitting the file via XHR.

One method is to use Flash. Since Flash makes connects to the server outside the scope of the browser’s connection, it essentially plays by it’s own rules.

Another, more popular method (since it works in browsers without requiring Flash to be installed) is known as the iFrame method. And here’s how it works.

The iFrame method

From here on, I’ll be referring specifically to the ajaxSubmit() method built into the jQuery form.js plugin, but the concepts are generally the same for any library that uses the iFrame method.

Assuming we have a form with a file-type input field, the iFrame method of uploading files can be summarized in the following steps:

1. Hijack the forms submit event to execute our custom iFrame-method function (e.g. .ajaxSubmit() from the form.js plugin).
   
2. Using JavaScript, create an iFrame element and insert it into the current page (and make the iFrame tiny and invisible to the user).
   
3.  
   Thanks to spinn over on Reddit for catching this. I’ve updated this step to illustrate the more correct way.
   Thanks to malsup in the comments for keeping me honest here and suggesting a further clarification.

   Change the target attribute of the form, such that the results of the form submission are rendered in the new iFrame instead of the current window.
   

4. Submit the form to the iFrame normal-style (non-AJAX).
   
5. Allow the iFrame to navigate to the response page (since it was submitted normal-style). Note that because this happens in the iframe, the parent window does not go to a new page or get redirected, only the hidden iFrame.
   
6. Copy the response content from the iFrame back into the parent window.
   
7. Delete the iFrame, reset the form’s target attribute to its original value, and inform the .ajaxSubmit() (from form.js) function’s callback hooks that the submission is complete.
   

It’s that easy! Er, not quite…

Complications

The above steps have a couple implications to further complicate things…

Response headers and status code

Since the submission takes place normal-style in an iframe, the parent window cannot inspect the response headers or status code (from step 5 above), due to browser security restrictions.

So, .ajaxSubmit() in the parent window must assume, once the request is completed, that it was successful. There are ways around this, but as of this writing, they have not yet been pulled into the form.js plugin.

Response JavaScript not automatically executed

Furthermore, if a JS response was returned, it won’t get executed in the parent window, because it was returned to the iframe. We would thus need to manually check if the response was JS code (instead of HTML markup or some other format), and execute it ourselves in step 7 above.

Form.js has a workaround which allows you can return some javascript code inside a textarea element as the response content. So then, if the iframe response content contains a textarea with some text value once the iframe form is submitted, it will copy that textarea content back to the parent window and execute it as javascript.

AJAX file uploads in Rails 3

Now that I’ve set the stage, in my next article, I’ll show how we can seamlessly add AJAX file upload capabilities to Rails 3 by extending jquery-ujs.

Future-proof

Thanks to Gábor in the comments below for bringing this up and prompting me to add this section.

Of course, we must ask, why are the browsers making it so hard for us to do something so simple? After all, is it really making the user’s interaction any more secure if there is such a workaround, as described here, which is as useful as it is popular? The answer is, no not really. And that is why the newest browsers have started to implement an actual AJAX file upload API.

As mentioned in the comments, we can see that a few of the latest browsers are already supporting this. For an idea of how to use this API, check out Mozilla’s documentation for using it with Firefox 4.

In my last article, Rails jQuery UJS: Now Interactive, I talked about my push to make Rails jQuery UJS (aka jquery-ujs) more interactive and easier to customize and extend with third-party plugins. Along those same goals, let’s discuss another recent change: ajax:aborted hooks.

There are now two scenarios where remote forms will not be submitted, and the AJAX submission will instead be aborted. When this happens, jquery-ujs now publishes hooks, to which we can bind handler functions to gracefully handle these situations.

Let’s take a look at each of these scenarios and how we can utilize the event hooks.

Required fields

The Opera browser has some interesting behavior (useful, but inconsistent) in which forms do not get submitted if they contain any blank required inputs. So, submitting a form containing the following blank fields would cause nothing to happen:

So, we implemented the same functionality in jquery-ujs for all browsers. If there are any blank required fields in a remote form, the AJAX submission is aborted, and we trigger the event hook ajax:aborted:required. A simple example for using this hook could look like this (in our application.js or whatever):

Notice that the required fields that caused this event to trigger are passed into our handler function, allowing us to do whatever we want with them.

Plugging in

Also, we may want to override the default behavior of jquery-ujs, and submit the form via AJAX anyway. We can do this by binding to the ajax:aborted:required hook with a handler function that returns false. For example:

Keep in mind that Opera does not trigger the submit event for forms with missing required fields, so the ajax:aborted:required event would never get fired in Opera, and thus, neither would any handlers bound to this hook.

File upload fields

Due to security restrictions, browsers do not allow file uploads via AJAX. There are workarounds, including the iFrame method, which allow us to simulate AJAX file uploads, but they tend to be a little more involved. So, jquery-ujs now aborts attempted AJAX file uploads, and instead makes it really easy for third-party plugins to extend rails.js to handle this functionality.

The following would cause jquery-ujs to abort the AJAX submission and fire the ajax:aborted:file event hook:

For the curious, if we try to submit a form containing a file input field via AJAX with jQuery, an AJAX request will be submitted to the server, but with the file input stripped out from the request parameters.

Unlike the required field functionality of jquery-ujs, file uploads don’t cause the form submission to be completely aborted. Instead, only the AJAX form submission, allowing the browser to submit the form normally with a page refresh. Also note that this behavior only occurs for non-blank file inputs; otherwise, the form is AJAX-submitted as usual.

Plugging in

But what if we want to cancel the browser’s standard form submission and provide our own AJAX file upload functionality, like the iFrame method mentioned above? That’s where the ajax:aborted:file hook comes in handy. We can bind a handler to this event hook that returns false to prevent the browser’s default functionality:

Third-party gems and plugins, like our own Rails Remotipart gem, can also use this event to automatically intervene for file uploads and provide AJAX upload functionality.

Yeah buddy

I’d like to send a shout-out to Neeraj Singh and Mislav Marohnić for helping get these changes pulled into Rails jQuery UJS.

In other news, I’m now on the Rails jQuery UJS core team. So, stay tuned for more on the latest developments in jquery-ujs.

If you liked this, check out our Definitive Guide to Rails 3 Remote Links and Forms Part 1 and Part 2.

The Rails jQuery UJS adapter (aka jquery-ujs) has undergone some major renovations over the past few weeks. This particular change is one I’m very excited about, as I’ve been wanting to do this for a while. Without further ado, jquery-ujs is now Interactive^TM.

What do I mean by “interactive”? Well, we can now plug into every facet of jquery-ujs, binding to custom events, and even customizing internal functions, without hacking or monkey-patching the rails.js file itself.

We’ll start with a brief explanation of the change and then dive into a few examples.

Feel free to bypass my blabbering and check out the the commit.

Closure style

Previously, rails.js was one big closure.

Before:

This closure design had many advantages. However, the biggest advantage, in this case, happened to be the biggest disadvantage as well: everything inside was self-contained and inaccessible by the outside world.

So, what if we like most of what jquery-ujs does for us, but just want to modify one little function? Before, we’d have to open rails.js in our editor and start hacking away. But no more!

Object literal style

A relatively simple refactor using the object literal design pattern now allows us total control, by placing all internal functions into the externally-accessible $.rails object.

After:

Now, inside rails.js, we simply change any fire() function calls to rails.fire(). And outside of rails.js, we can similarly call $.rails.fire().

Furthermore, we could even redefine the fire() function with our own: $.rails.fire = someNewFunction();.

In the excerpted code from rails.js above, the “before” looks simpler, but the “after” actually does a nice job of keeping things clearer and better organized when there are more functions.

Some examples

So, how might we actually use this now in a production app? Let’s look at a couple examples.

Direct access

For starters, let’s say that we want for a particular form to be submitted the same as :remote => true forms, but for whatever reason, this form does not have the remote attribute. We can now take advantage of the functionality provided by rails.js directly. In our application.js, we might have:

And now, rails.js will set up our AJAX request, serialize our form, etc., just as if it were a remote form. Of course, this example is a bit contrived, but hopefully it illustrates the potential for being able to access rails.js functions directly.

Redefining jquery-ujs functions

And of course, as mentioned before, there’s also the ability to redefine functions. For example, in our application.js, we could add:

And now we have our own custom fire() function which will now be used internally by jquery-ujs without having to open up and modify rails.js.

On a side-note, the fire() function in rails.js is probably one of my favorite little functions that I’ve actually used in several other projects, including the jQuery EasyTabs plugin. But we’ll take a closer look at this function another time.

Redefining selectors

And as an added bonus, we also moved the CSS selectors, to which jquery-ujs binds all its functionality, into the $.rails object. How could this be useful?

Let’s say we want the ability to kill all jquery-ujs form bindings for a particular form (maybe after it’s been submitted once already). In rails.js we have:

Now in our application.js, we could do something similar to the following:

W00t

Well I hope this was helpful. One of my goals with these changes was to spur the development of additional plugins and gems that build off of and extend the great out-of-the-box functionality that rails.js provides.

As another way to help maintain third-party plugins that extend jquery-ujs, I also added a new Changelog. This will hopefully make it easier to keep track of notable changes to the “api”.

I’d also like to send a big thank-you to Neeraj Singh, who has been very helpful keeping me sane and in getting changes pulled into jquery-ujs.

Stay tuned for more on recent developments in Rails jQuery UJS. In the meantime, I encourage you to check out the source.

If you liked this, check out our Definitive Guide to Rails 3 Remote Links and Forms Part 1 and Part 2.

• Panel height animated transitions
• Animation transition options

• 
  View demo with new features
• 
  View plugin homepage
• 
  View changelog

Animated height transitions

In many cases, the tab panels (where the tabbed content lives) are not the same height. Now, EasyTabs automatically animates the height transition between panels of differing heights. The speed for the animation to scale panel heights depends on the animationSpeed option.

View the demo to see this new effect in action.

Animated transition options

As requested, EasyTabs now gives more control over the effects used to transition between panels. The default transitions are still fadeIn and fadeOut, respectively. But now, you can specify any other jQuery effect to use as well. The new options are:

For example:

To see this in action, check out the demo.

• uiTabs option
• collapsible option
• Cancel tab-change in ‘easytabs:before’ hook
• Useful parameters in callback hooks

• 
  View demo with new features
• 
  View plugin homepage
• 
  View changelog

uiTabs option

Perhaps my favorite addition to the EasyTabs options, when uiTabs: true, EasyTabs will automatically add and use the same class names used by the jQuery UI tabs. This feature opens the doorway to making EasyTabs a drop-in replacement for jQuery UI tabs once you’ve outgrown UI’s out-of-the-box theming and structure.

If you are currently using UI tabs with this:

Simply replace the above line with this:

And your tabs will still look and function the same as before. Now you can start customizing the CSS and HTML markup with the flexibility of EasyTabs.

Note that EasyTabs currently only supports the collapsible option of UI tabs (for now). So if you’re using any of UI tabs other options, these will need to be removed. If you would like support added for a specific option, request it in the GitHub issue tracker, or even fork the project and submit a pull request.

collapsible option

By request, the collapsible option has been added to EasyTabs. This allows an active tab to be “de-selected”, or collapsed, when clicked again.

This will also cause all tabs to be collapsed initially. However, this behavior may be overridden (such that the default tab will be expanded by default) with the collapsedByDefault option:

Alternatively, if a defaultTab is specified, then the default tab will be expanded by default as well (as if collapsedByDefault were true).

Also, when a panel is collapsed, EasyTabs adds the collapsed class name to the tab, so that it may be styled uniquely (perhaps grayed out) in your CSS. You can override the collapsed CSS class name with the collapsedClass option:

Cancel tab-change in before-hook

And finally, also by request, you can now cancel the tab change event in the easytabs:before event hook. If a function bound to the easytabs:before hook returns false, then the tab-change event will be aborted. A simple use-case for this might be:

Useful parameters in callback hooks

In the callback hooks, it’s useful to know what tab was clicked, what the target panel is, etc. Now it’s possible. All three callback hooks (easytabs:before, easytabs:midTransition, and easytabs:after), pass the following parameters to the handler functions:

So, for example, we can do this:

• 
  View demo with new features

The JavaScript response from my js.erb is being interpreted as text and not being executed.

I usually point to this comment in GitHub Issues, which I posted the first time I came across this problem. But GitHub Issue comments are difficult to link to, and almost useless in search results due to all their ajaxy-ness. So, I’ll repost and explain here for future reference.

The problem

The problem usually isn’t that the JavaScript in the js.erb isn’t being executed, it’s that it’s being executed and incurring an error. By default, when jQuery processes a JavaScript response, it does two things. It executes (or evaluates) the response, and also returns it as a text.

Except, if there is in error in the JS evaluation, we will not see that error in our favorite JavaScript console; the automatic JS evaluation fails silently, so it appears that jQuery is only interpreting the response as text and nothing else.

Great, so now what?

The diagnosis

First, let’s make sure that this is indeed what’s happening. To verify that the response is getting interpreted as JS and not plain text, go to the Rails log and make sure the remote request looks like this:

If the “as JS” bit is in there, then what we have is a JavaScript problem (which is addressed below). If not, then see my post on remote link and form data-type.

The solution

Here is my process for debugging this type of solution. Firebug works best, because it contains all the tools needed in one place.

1. In Firebug, in the “Console” tab, turn on “Show XMLHttpRequests”, so that we can see AJAX requests and responses in our console. Also make sure that “Larger Command Line” is enabled.



2. Reload the page and click the remote link or form in question.
3. Click the AJAX request, which should have shown up in the Console, then click the “Response” tab.



4. Copy and paste the rendered JavaScript response into the command-line pane, and click “Run”.



5. Now, any JavaScript errors will show in the console. Fix the errors in the js.erb file and repeat until it works.