By Rebecca | June 15, 2009
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!
No Comments »
By Rebecca | April 15, 2009
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 --
Tags: form validation | 6 Comments »
By Rebecca | April 13, 2009
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 
11 Comments »
By Rebecca | April 1, 2009
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.
1 Comment »
By Rebecca | April 1, 2009
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.
No Comments »
By Rebecca | March 3, 2009
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.
1 Comment »
By Rebecca | March 3, 2009
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?
Tags: tww | No Comments »
By Rebecca | February 18, 2009
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
- Step 1: Sign up for a Twitter account at twitter.com. Since the focus is on personal branding, choose a username that has some association with your actual name. Pay a quick visit to the Settings page, and pay special attention to the Notices tab; you'll probably want to receive e-mails about direct messages from other Twitter users, and also e-mails when people follow you. On the Account tab, make sure the "Protect my updates" checkbox is NOT checked -- otherwise, you're defeating the purpose.
- Step 2: Download a desktop Twitter application. I run TweetDeck on my desktop, and TwitterFox in Firefox. TweetDeck is great because it allows you to have several panels that you can view at once. I have one for viewing messages for people I'm following, one for capturing tweets related to a search term, one for public replies to my tweets, and one for direct messages from people I'm following. TweetDeck and other applications are also great because they have built-in tools for filtering tweets, replying to tweets, following users, shortening URLs, etc. -- once you start using TweetDeck or something similar, you'll rarely need to return to the Twitter site.
- Step 3: Start tweeting. If you read something interesting related to your area of expertise, write about it. If you do something interesting for work, write about it. If you're traveling, write about it. If you have a question about your field, ask it. Strive to be professional but human. Remember that you only have 140 characters, so choose your words carefully, and strive to include keywords. Remember to shorten URLs so long ones don't eat up precious characters.
- Step 4: Follow people. After you've been posting ("tweeting") for a few days and you're ready for people to start paying attention, go to search.twitter.com or use TweetDeck to search for keywords related to your area of expertise. Read what's being said, and click on the usernames of the person saying it. If that user's posts ("tweets") are generally interesting to you, click the button on their page to follow them, and you'll start to see their tweets on your Twitter homepage. It's customary (but not required) that users follow people who follow them, so if you choose the people you follow with care, chances are they will follow you back.
- Step 5: Keep participating. Take a little time each day to scan the tweets from people you're following and from search terms you're watching. Reply to people, retweet interesting things other people are saying, and post your own new content. Over time you'll discover the interesting people, and start to accumulate your own followers. Remember that people will decide whether to pay attention to you based on how much you're contributing -- that doesn't mean you need to tweet 20 times a day, but once or twice a day is a reasonable pace.
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:
- Tweet: Messages posted by Twitter users, or, as a verb, the act of posting a message on Twitter.
- Follow: This is like "friending" someone on Facebook; when you follow someone, you are saying that you want to read what they say. Their tweets will appear on your Twitter homepage, as well as in TweetDeck and other Twitter applications.
- Reply: Replies are like notes to people posted on a public bulletin board: there's no strict guarantee they'll read it, and anyone else is welcome to read it. You can reply to any user, and sending topical replies to people can be a great way to get them to follow you. To reply to someone, put an @ symbol before their username. For example:
@rmurphey great tweet!
- Direct Message: Direct messages are like e-mail, and in most cases they'll arrive in the user's actual email inbox. Unlike replies, they are not public; only the user receives them. To send a direct message to someone, put a d followed by a space before their username. For example:
d rmurphey this is a secret message.
- Retweet: If you like someone's tweet, you can retweet it. There's no official syntax for this, but the customary way to do it is to put RT before their message (and then to truncate their original message as necessary). For example:
RT @rmurphey just wrote a great blog post.
Good luck! Don't forget to follow me @rmurphey.
Tags: twitter | 1 Comment »
By Rebecca | February 13, 2009
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:
- Impose yourself early in the process, insisting on wireframes and information architecture documents (even if they're just sketches and an outline). Identify potential problems early on, but don't become a naysayer -- make sure you offer ideas, not just criticism.
- Push back -- gently but firmly -- on design decisions that have the potential to cause problems down the road. Ask lots of "what if" questions and insist on answers.
- Be honest about how long it will take you to accomplish a design -- with yourself and with your boss or client -- and identify opportunities to make cost-saving changes to the specifics of the design without changing its spirit.
- Have examples at the ready of similar problems solved in more web-centric ways. The Yahoo! Design Patterns Library can be an excellent resource for this, but look also to other sites in your industry or genre.
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:
15 Comments »
By Rebecca | January 12, 2009
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.
12 Comments »
« Previous Entries
