I’m teaching a jQuery class!

categories: front-end development, javascript, jquery

One of my goals this year was to get up in front of people and talk. To that end, I'm happy to announce that I'll be teaching a jQuery fundamentals class July 29-30 at Carrboro Creative Coworking in Carrboro, N.C.

In my work with jQuery beginners, I often find that the library is so easy to learn that it's possible to skip over the fundamentals of JavaScript. With that in mind, we'll start the class with a high-level overview of key JavaScript principles, including concepts like logic, objects, variable scope, and closures. From there, we'll move on to a thorough overview of the jQuery library -- selecting, traversing, manipulating, effects, events, XHR (Ajax), and plugins. Throughout the class, we'll focus on best practices for writing and organizing jQuery code for easy reuse and refactoring. Participants will leave the class as upstanding members of the jQuery community, armed with a solid understanding of the concepts of both JavaScript and jQuery, and ready to start leveraging the library in their projects.

If you have any questions about the class, drop me an email at rebecca@rebeccamurphey.com, and I hope to see you there!

jQuery validation: Indicate that at least one element in a group is required

categories: jquery, plugins

I had a need today to indicate that at least one of a set of input fields was required. I was hoping there was a direct way to do this in the jQuery validation plugin; while the method isn't quite as straightforward as I was wishing for, it's still fairly simple.

To start with, I put class="required_group" on each of the elements in the group. Then, I added a custom validation method:

 
jQuery.validator.addMethod('required_group', function(val, el) {
        var $module = $(el).parents('div.panel');
        return $module.find('.required_group:filled').length;
});
 

... a custom class rule to take advantage of the new method:

 
jQuery.validator.addClassRules('required_group', {
        'required_group' : true
});
 

... and finally a custom message for the new method:

 
jQuery.validator.messages.required_group = 'Please fill out at least one of these fields.';
 

What I'd love to see is a way to specify a dependent group without using a custom class rule, but I'm not sure what this would look like, as all validation rules are either keyed off an element's class or the presence of the element's name in the rules object. Thoughts? I'm open to the possibility that there's a far better way to solve this --

On gaining respect as a front-end developer

categories: front-end development, thoughts

Someone wrote me today:

Where I work, design is highly valued with the leader of that group being our Creative Director, back end programmers are also highly valued, but front end ... not so much. Partly I think its that I don't toot my horn but I know there are other reasons. At times, my bosses haven't even understood what it is that I do. Back end programmers look down on front end assuming that its trivial or something that should be relegated to compilers.

I was wondering if this is a common thing or more so something that is happening at my particular company, and if you have any advice or pointers on this.

I thought my response might be worth sharing:

I do think this attitude is common but not necessarily the rule. In my experience, I've found that by having a proven value proposition, you can gain converts and respect.

Front end developers are in a unique position to improve page performance (perceived and actual) by using best practices such as the YSlow tests. Front end developers are also in a unique position to help develop templating systems and to write thoughtful CSS, both of which help enable the rapid prototyping and rollout of new features. A focus on results and best practices -- demonstrating that you aren't just pushing pixels around -- is the key.

Back end developers respect people who think like they do. Be mindful of opportunities for abstraction and reuse. Write object-oriented CSS and JavaScript. Craft solutions that are maintainable and documented. Learn and make use of version control systems. Look for opportunities to participate in developer conversations about new features, and understand what the back end developers are up against. They'll appreciate all of this.

Take the time to teach and to learn. Be sure you have at least a passing understanding of the code the back end developers are writing, and leap at opportunities to share your knowledge. I've worked with more than one back end developer who was surprised to discover what all they didn't know about the front end, and through our conversations about how we approached problems, we both learned a lot.

Finally: identify opportunities for quick victories, execute on them, and make the results known. Benchmark before and after. Can you reduce the number of HTTP requests on a page, decreasing both the perceived and actual rendering time? Are you keeping your JavaScript out of the <head> as much as possible, preventing pages from stalling while rendering? Can you write JavaScript that is primed for reuse, and demonstrate opportunities for that reuse? Has your carefully crafted CSS allowed the rapid rollout of a new feature? Don't be afraid to tell these stories -- they'll tend to strengthen your position by clarifying the important role the front-end developer plays in a site.

Good luck :)

My first guest post!

categories: front-end development, howto, jquery

Steve Reynolds, web services manager at Sony Computers (SCEE), contacted me last week about writing a guest post on his blog, reynoldsftw.com, and I happily obliged. Check out my post there about custom events in jQuery, and how they can change your approach to event binding by putting the emphasis on the element being acted on, rather than the element doing the acting.

New JSMag out today

categories: javascript

The second issue of the new JSMag is out today, and among other excellent content, it includes an article from me about using object literals to organize your JavaScript features. Some good stuff for people who may be accustomed to writing more procedural jQuery. Here's the setup:

In the past few years, JavaScript libraries have given beginning developers the ability to add elaborate interactions to their sites. Some, like jQuery, have a syntax so simple that people with zero programming experience can quickly add bells and whistles to their pages.

Adding all those bells and whistles, even some pretty elaborate ones, seems to be just a few Google searches away. A copy here, a paste there, a plugin or a few dozen lines of custom code — the client is duly impressed, and you’re adding jQuery to your resume.

But wait. Now the requirements have changed. Now the thing that needed to work for three elements needs to work for ten. Now your code needs to be reused for a slightly different application where all the IDs are different.

We’ve all seen the snippets that make jQuery (and other libraries) look dead-simple. What those snippets leave out — and hey, they’re just snippets, right? — is how to design your code when your needs go beyond dropping in a plugin or doing some show() and hide().

The magazine is a paid PDF download ($4.99/issue), and with great articles on JavaScript profiling and JazzRecord for JavaScript databases, plus community news and an in-depth interview with members of IBM's Dojo team, I promise it's worth it. Do check it out.

JSMag: Volume 1, Issue 1

categories: javascript, jquery

Just a heads-up that I was lucky enough to be asked to write an article for the first issue of JSMag, a new magazine published by Michael Kimsal and dedicated to all things JavaScript. The magazine will be coming out in the next day or two, and features articles about unit testing, ExtJS, JavaScript debugging, functional programming, and more.

My article focuses on the changes in jQuery 1.3; I was lucky enough to score an email interview with John Resig about jQuery 1.3 and his thoughts about 1.4, and I got Brandon Aaron to tell me about his rewrite of the offset() method.

The magazine is a PDF download; for those of us accustomed to getting our information for free, it may seem a little weird to pay a few bucks, but trust me, it's worth it. Don't trust me? Download a sample of the first issue.

Announcing Triangle Web Women

categories: thoughts

When I noticed that a conference I'm attending didn't have any female speakers listed, I contacted the organizers to see what was up. As soon as I wrote them, though, I realized that I didn't even have anyone to recommend for inclusion. Thus was born Triangle Web Women, my local effort to foster connections, promote knowledge-sharing, and generally establish a community among local female web professionals.

Interested? Check out triwebwomen.ning.com, the fledgling website where I'm gathering participants and sharing events.

Before the site was even set up, we had an initial gathering at a local restaurant, with five of us drinking wine, eating tapas, and talking about everything from accounting software to time-tracking to whether the world needs yet another content management system. I'm looking forward to our next gathering, March 19, location TBA, with a few more web-working women. We may not take over the conference circuit, but it's a start, right?

Twitter for personal branding: Getting started

categories: howto

This post is focused on using Twitter for "personal branding" -- establishing yourself as an influential voice on a topic in which you have some expertise. I want to say up front that I don't deign to suggest that I'm adding anything new to the sea of "getting started on Twitter" content that's out there. However, I just got home from drinks with a friend, and when we parted she seemed intrigued by the idea of using Twitter to more firmly establish herself as an expert in her field, a task for which I think Twitter is particularly well suited. I was going to write her an email, but instead I thought I would write down some notes for her and anyone else who happens to be reading.

If you've read any posts on this topic already, there's probably not much new to read here; if you haven't, I suggest you read this and then keep reading -- there are a whole lot of opinions on how best to use Twitter for all sorts of purposes, and these are just mine.

That said, here's my abbreviated list of steps for getting started on Twitter if personal branding is your goal. Below this list, I've also noted a few Twitter vocabulary terms you'll probably want to know.

Getting Started

Twitter Vocabulary

Some of the words surrounding Twitter can make it sound a bit foreign, or at least geeky and slightly uncool. Here's what they mean so you won't be so intimidated:

Good luck! Don't forget to follow me @rmurphey.

CSS vs. Tables: Maybe the design is to blame?

categories: css, front-end development

There's been some backlash lately against CSS, and some of it seems so well reasoned that even I find myself wondering if tables are really so bad after all. From giveupandusetables.com, which says the maximum time to spend before abandoning CSS is 47 minutes, to the well-illustrated blog post by Ron Garret, the general argument is that CSS isn't up to the task of faithfully reproducing elaborate designs cross-browser in an acceptable amount of developer time.

In his post about Garret's article, Dion Almaer at Ajaxian opines:

CSS purist[s] may poo poo him and say "he is just dumb and doesn't REALLY know CSS." The problem though is that most developers run into exactly the pain that he describes. We’ve all been there. It drives you nuts and when frustrated what do you do? You fluster about and change CSS like a mad man until it kinda looks right. And, you never learn what the real problem was, and thus destined to make the same mistake again.

It seems that while developers are thinking about sacrificing web standards for the perceived simplicity of tables, the viability of the design rarely enters the debate, and that's a shame. In my experience, some of the most difficult designs to produce using CSS were fundamentally flawed from the get-go, created by designers who failed to grasp that the web is not like print.

The web is not like print. In print, designers have near-total control over the output, because the number of new "pages" -- items of content -- is limited by the cost of printing. If a print designer wants text vertically centered in a fixed-height column, or two columns that are exactly the same height, or rounded corners with drop shadows on top of gradients, there's no reason they can't have that. The cost of printing is sufficiently high, and print graphics programs are sufficiently sophisticated, that making those design decisions has no impact on the marginal cost of production.

On the web, the marginal cost of creating a new page of content can be approximately zero, but to achieve that we must build pages that adapt to unpredictable content and unpredictable users. If we don't, we won't realize the economies of scale that the web has to offer. The tradeoff for that infinitesimally small marginal cost is that the rules have to be different, because the cost of implementing those print-centric design decisions is inordinately high. Instead of sophisticated graphics programs, the web has mere humans to turn PSDs into working pages; instead of content created by experts and pored over by editors, the web has volumes of user-generated content, and the ability to change it on a whim.

On the web, equal-height columns will cease to be equal height when the content changes; vertically centered content will outgrow its fixed-height bounds; and rounded corners with drop shadows on gradients can't possibly be worth the cost of producing them. These are not problems with CSS that should be solved with tables. They are, fundamentally, problems with the design.

When I talk about this to other developers (and any designers who are willing to give me the time of day after I'm done pointing out how costly their design will be to produce), I make the analogy that it's just as absurd to impose these print-centric design conventions on the web as it would be to use holograms for every picture in a magazine. Sure, you can, but that doesn't mean you should.

So what's a web developer to do? When designs reach the desk of the CSS developer, more often than not they've been through so many rounds of review, revision, and approval -- by people far-removed from the realities of the web -- that the developer has little choice but to toil away at reproducing them faithfully.

The best defense may be a good offense, which is to say, the burden is on you, dear developer, to educate the misguided designers. Here are some tactics I've used:

The burden's also on you to get better at CSS. I am lucky in that, when I first started playing around with web production, I was a little intimidated by tables. A background in print production steeped in templates and stylesheets made tables seem awkward and strange to me; CSS, temperamental as it was, at least bore some resemblance to the cascading style sheets of print production programs like Quark and InDesign.

These days, it's rarer and rarer (but not unheard of) that I find myself beating my head against the wall over a CSS problem. I've learned HTML and CSS patterns that I reuse often, and I've learned to spot -- and speak up about -- design-induced ratholes. If you're finding yourself sucked in by the latest round of CSS vs. tables debate, take heart, stand firm, and reconsider the source of your frustration.

Useful things:

jQuery validation and TinyMCE

categories: howto, jquery

Just solved a problem where the jQuery validation plugin wasn't playing so nicely with TinyMCE -- the validation plugin was trying to validate the textarea before TinyMCE had a chance to copy the editor contents back to the textarea. I was about to yank TinyMCE out of the page but a little reading through the TinyMCE docs led me to try this:

 
$('#mySubmitButton').click(function() {
    var content = tinyMCE.activeEditor.getContent(); // get the content
    $('#myTextarea').val(content); // put it in the textarea
});
 
$('#myForm').validate();
 

And what do you know, it works. One note: it's important to bind the content replacement to the click event of the submit button, not to the actual form submission, or else the validation may try to run before the content gets copied back to the textarea.

« Previous Entries