Two Banjos At Once: The Blog

Living with standards compliance

12+ People I Owe

January 14, 2010

So here’s a pretty satisfying thought experiment/daydream: if uncountable buckets of money suddenly landed in your bank account one morning, who would you invite to share the windfall? Just in case this happens to Yours Truly, I’m writing up a list of people who devised things which made my professional life easier over the years, so that I can compensate them appropriately before I retire to a villa in Tuscany.

This villa is absolutely positioned. Photo by Maney Digital

12+ People I Owe

  1. Jesse Ruderman, for the Web Dev bookmarklets
  2. Felix Ritter, for View Formatted Source. Yes, Firebug has assumed its function, but I’m nostalgic for the day this add-on removed tons of guesswork from my project.
  3. Eric Meyer, for his Reset CSS, which introduced us to a sparkling world clean of browser defaults
  4. Joe Hewitt, Rob Campbell, et al., for Firebug
  5. Mike Buckley and Lorne Markham, for Pixel Perfect
  6. Kevin Freitas, for MeasureIt
  7. Lorenzo Colitti and Philip Chee, for FlashBlock
  8. Alex Sirota, for ColorZilla
  9. James Anderson, for Leechblock

Who will receive your gratitude?

Productivity System Smackdown: FlyLady vs. GTD

October 19, 2009

Many of us, it seems, meet day’s end with disappointment, not satisfaction. We started ambitiously, worked steadily–at something. But what is there to show for that? A barely diminished to-do list, and a burden for tomorrow.

I confess that my favorite way to procrastinate is to read productivity blogs. It’s by way of this habit (bad or good? Let me know) that I’ve learned about the following productivity systems. Readers familiar with both might be astonished that I’m comparing these, since they’re oriented towards such different audiences and spheres of activity–but having used and experienced both, I think they’re ultimately about the same subject, which is reaching that thrilling moment when your to-do list is blank.


GTD

Contender #1: Getting Things Done, a.k.a. GTD

Who:
David Allen
How:
the book (Getting Things Done ), the seminars, the applications, the fans.
What:
GTD© is the productivity system outlined by David Allen in his 2001 bestseller. Allen proposes that a profound gain in one’s productivity follows from writing things down, rather than keeping them in one’s memory. Much of GTD centers on organizing that written data into recognizable prompts for action.
Ritual object:
Many items hold great importance in the GTD system, such as daily calendars, notebooks, and PDAs, but when I read GTD, nothing seemed more crucial for the system’s implementation than the File Folder.
Pros:
  • As you can see from the options above, there are many sources of information about this system. Any practitioner seems ready to pounce on your least little question about how to use the system.
  • Held in great esteem in the US corporate workplace. Casually mentioning your reliance on GTD practices in a job interview will probably score you points.
  • Several of the principles are quick to implement and easy to remember (I expect Allen would prefer we make notes about them down instead).
Cons:
  • Though Allen does include non-workplace examples, his is not a system to apply in all situations. I can’t imagine how blue-collar or domestic workers would use some of the GTD principles.
  • Generates more physical artifacts than I find comfortable. For instance, Allen suggests making file folders to organize even unique documents. Having joyously reduced my own files to just one letter-size box, I’m reluctant to add to their bulk again.
  • Has no apparent built-in protections against tipping into obsession. Taken to its limits, GTD could easily absorb all that time one used to spend in leisure or paying work.

FlyLady

Contender #2: FlyLady

Who:
Marla Cilley, the “FlyLady” (the moniker comes from her love of fly fishing)
How:
the Website, the online discussions, the publications, the occasional workshops
What:
The FlyLady’s system treats domestic concerns almost exclusively. Practitioners receive daily emails from the FlyLady reminding them to undertake various household chores in small (5- or 15-minute) chunks of time. The emails include testimonials from grateful participants, and homespun pep talks from the FlyLady.
Ritual Object:
The Shiny Sink, maintained nightly by faithful practitioners, though the Timer, the Calendar, and the Control Journal assume almost as much importance
Pros:
  • Very easy to implement and follow. Much of the system establishes routines. One can begin them at any time.
  • Corny as they are, the FlyLady’s pep talks do address self-defeating behaviors such as perfectionism and procrastinating.
  • Many of the FlyLady principles can apply to other than domestic work.
Cons:
  • The very feminine and very folksy tone of FlyLady messaging is likely to irritate most men and not a few women
  • Nearly all FlyLady emails will contain exhortations to buy one or more of the housecleaning tools for sale through the FlyLady Website
  • Since it is a system used by one of the most despised, “uncool” sectors of the population (middle-aged, middle-class, nonurban women), you probably won’t garner job interview points for mentioning it.

The Winner

The FlyLady.

Yes, really. Why? Because her system is simpler, doesn’t leave a lot of stuff behind (among her frequent themes is reducing clutter), and really addresses why we don’t Get Things Done: it’s because 1) we think we have to do them perfectly; and 2) we think they will take more time to accomplish than they really will. Though Allen does have the rule about working immediately on any task which will take fewer than two minutes, FlyLady combats procrastination by not even requiring one to assess which tasks those are.

As other systems are discovering, one’s best tool for productivity is a timer. Set the timer for an easy-to-accommodate sliver of your day, and work on one task, whether it’s decluttering your sock drawer, making cold calls, or even writing blog posts. The timer rings; you stop–and there’s one less thing to do.

How to demoralize your front-end developers

October 2, 2009

Stop failing at this apparently necessary chore; I’m here to help.  I can verify that all the following techniques have worked on for me.

How to Demoralize Your Front-end Developers

  1. Constantly change requirements. It’s, what, the day before the scheduled launch?  And the product doesn’t include that absolutely requisite feature you didn’t think to require until now?  Well, shoot, just demand it!  And make drastic changes to the visual and interaction design as well–where’s the glory in completion?
  2. Constantly change the visual design. You took that one-day course in CSS and remember only that it was a way you could change all of a site’s visual elements from one file.  Okay, then, let’s start by making all the blue things red, and all the red things green–but only on Tuesday–wait, change them back again, make the old red things red again–and oh, all the gray things white and the white things gray, and the grayish-white things brown, on alternate weekdays.  And all the wide things “smaller” and the narrow things “a little bigger” and the tall things “a smidge shorter” and… just marvel  how enthusiastic your front-end dev grows.
  3. Give them a lousy setup. Cram your developers into a spot at an unergonomic table in between the gal who has the obnoxious sound themes enabled on her workstation and the guy who spends his entire work day shouting into a speaker phone. Don’t let your devs use their preferred operating systems or software–point out that you’ve generously provided work computers exactly like your own, with that reliable ten-year-old OS and the proprietary groupware that cost you a bundle.
  4. Decide midway that you need pixel-perfection in IE 6 after all. So you visited your hermit, anti-consumerist brother-in-law living in a shanty with a hand-me-down Gateway 2000 accessing the Web over intermittent dial-up, and you looked like a putz because your beta site didn’t render perfectly in Internet Explorer 6.  Well, crack the whip so he can enjoy those rounded corners, PNGs with alpha transparency, and painstakingly mitered grid layouts.
  5. Critique the browser rendering against one in a different medium. Different media, you say?  Hardware?  Pshaw!  Do as I’ve actually witnessed:  hold a paper print-out of the intended design up to the monitor, and compare the rendered page unfavorably to the PDF print-out.  Remark on the differences in proportion and color.  Watch your devs writhe in either agony or amusement at your request to make the two formats identical.
  6. Assign visual design tasks to your developers. Get rid of that pesky professional, and go with a leaner team equipped with mere adequacy in Web design.  Start with vague instructions to your front-end devs (“This area of the page needs to really say ‘breathy,’ but not ‘vaporous’”), and end with your looming over them, jabbing at the display of a competitor’s site on a monitor, and shouting, “See? See?!  Like this–only different!”
  7. Pit your developers against each other. Break up that predictable day with a bout of office politics as bloody as any combat in the Colosseum!  Let one developer bully another, favor the least productive developer over the others, and disclose important project details only to the dev most likely to hoard the information.  When one dev leaves at 6pm to tend to the rest of his life, assign all his duties to the other one still in the office. Whatever you do, don’t let these people end up liking each other.
  8. Constantly interrupt with phone calls, e-mails, IMs, or in-person meetings. You know, if you give your developers the chance to concentrate, to get into the flow of working, there’s no end of disaster which could happen:  they might  finish the tasks you’ve assigned to them, or write bug-free scripts, or finish a work day with a sense of accomplishment.  Then you’d all miss an important feature of the Development Drama:  the climactic battle in which each side slays the other in murderous frenzy.
  9. Ridicule their professional opinions. Don’t listen to the nay-sayers when you describe that pop-up with autoplay Flash, animated GIFs, and blinking text you’re confident will add loads of appeal to the application.  Show them your teenaged son’s MySpace page and pointedly ask why they can’t make something like that if he can.
  10. Don’t use a bug tracking system. Sheesh, you already send all those e-mails.  Why repeat yourself in some persnickety little data entry form with those dropdown things which force you to prioritize the issue?  Just repeat: everything’s critical and of highest priority.  See, easy to remember.

Hmmm, something’s missing.  What have I left out?

My First Web Page

September 21, 2009

Some digging in a dusty file box the other day yielded no fewer than three floppy disks. What wisdom might these ancient tablets convey? Fortunately, there was at least one device in the house which still had a floppy drive. Result: mostly disappointment. The files were either first drafts of things I’d sent off to magazine editors in the late 1990s, or grouchy letters to my landlords of the same era. However, there was, archived with apparent pride, my first effort as a Web developer.

Step into the WABAC Machine. The year is 1997. I was the admin assistant for a team of software engineers. I was also something of a mascot; if the guys (yup, all guys, except for me) had a noncritical technical task they thought I could handle with a little instruction, they threw it to me, because I guess I looked really grateful to be doing something besides ordering lunch and taking the abusive phone calls of the company CEO. The most enduring instructions they gave me was how to use FTP, IrfanView, and NotePad to develop the team Web site. Of course, these tools seemed insufficient once I made a few changes–I wanted colors! Silly typefaces! Dizzying background images! And HTML seemed so hard to learn…

I remember downloading a lot of trial versions of the trendy WYSIWYG software of the time: an early version of Frontpage (which had me puzzling over these things called “stylesheets”), Adobe PageMill, and the editor which came with Netscape Gold. The one I used the most seemed to be NetObjects Fusion, which I notice is still available. It was a big, handholding, friendly giant of a program; it set everything into tables and FONT tags, and we were buddies. I felt masterful.

Nobody I worked with was a Web professional–no designers, no information architects, no UI devs. Creating Killer Web Sites had only just been published, Web Pages That Suck was treated mostly as a humorous diversion, and even Jakob Nielsen was as yet rather obscure to the average person making a Web page. It was in this Wild West environment that I devised this:
My First Web Page

I’ll enhance that retro atmosphere with a sample of its markup:

<HTML>
<HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (WinNT; I) [Netscape]">
   <META HTTP-EQUIV="Page-Enter" CONTENT="revealTrans(Duration=1,Transition=6)">
   <TITLE>ES Home Page</TITLE>
</HEAD>
<BODY BACKGROUND="amoeba.jpg">

<CENTER>
<H1>
<FONT FACE="Wide Latin"><FONT SIZE=+4>Engineering Services</FONT></FONT></H1></CENTER>

<CENTER><IMG SRC="grey_dots.gif" ALT="grey_dots.gif (6699 bytes)" HEIGHT=47 WIDTH=890></CENTER>

<CENTER><FONT FACE="HELVETICA"> </FONT></CENTER>

<UL>
<LI>
<FONT FACE="HELVETICA"><FONT SIZE=+2><A HREF="[...]">ES
Quote Status</A></FONT></FONT></LI>

<LI>
<FONT FACE="HELVETICA"><FONT SIZE=+2><A HREF="[...]">Current
ES Status Report</A></FONT></FONT></LI>

Yeah, go on. Snort, carp, whatever. But this is how we did things then, back when browsers “innovated” with crap like BLINK and MARQUEE. A year later I was back to using text editors–haven’t touched a WYSIWYG since. Just a year later I was using CSS and disdaining FONT, and a year after that I was riding the dot-com boom as it crested. So it’s worth examining your old work product, if only to swell with pride over how far you’ve come since then.

What was your first Web page like?

A visit with HTML 5

September 9, 2009

Now that HTML 5 has been declared victorious over XHTML 2, the last six to eight weeks have yielded a bouquet of tutorials, introductions, cheatsheets, and blog postings about it. I guess we’re so excited about anything new in markup we’ll even cheer a draft proposal. I can’t excuse myself from the mob, having joined it on a recent project for a future-minded client who encouraged me to take up the fashion for <!DOCTYPE html>.

On first and even second glances, the HTML 5 element list seems conservative, not much of a change. There are the intriguing new tags like <canvas>, but with limited cross-browser support. <menu>returns from, what, HTML 3.2?, but this time dressed up as a way to group form inputs (easy to confuse with how we’ve been using <fieldset>). Other elements, such as <header>, <footer>, and <section>, are good substitutions for the over-worked <div>, which lingers in HTML 5 for your block element needs. <article> is interesting–it’s supposed to enclose “standalone” content. <nav> is easy to type and remember.

However, some of these tags seem to presume usage in rather old-fashioned situations. For instance, which of the navigational blocks on your application screen will you exalt with <nav>? No fair using it more than once–it’s supposed to designate your primary navigation. And which of your content blocks are <section>s and which are <aside>s, especially if the user can rearrange them?

Where HTML 5 seems more ambitious, seems to pose more of a learning curve, is on attributes and APIs. Form elements seems especially enriched in this specification. I didn’t use any of these on this project, but I’m eager to try them when the browser support is sufficient. Many of the proposals will remove tedious DHTML chores, if ever supported; for instance, this block will replace all those unordered lists distorted by CSS and JavaScript into popup menus:

<menu type="popup">
    <command  label="Check messages" icon="messages.gif"/>
    <command  label="Logout" icon="logout.gif"/>
</menu>

By now I expect you’re asking, “But what about IE?”

Yeah, what about that? Hmmm.

I was blessed to have a client who’d discarded concern for IE 6. Problem solved, you think?

Not at all. IE 7 ignored even the most basic HTML 5 tags–even <section> proved uncharismatic. To the rescue, JavaScript; more specifically, the “HTML5 Shiv” (love the name, which captures the mood of destructive exasperation IE inspires) script popularized by John Resig and Remy Sharp.

Overall, it was an enjoyable stroll through HTML 5’s more accessible areas. Maybe XHTML 2 would’ve been a more thrilling excursion, but I’m content. Shiv or not, it looks to be sunny ahead.

6 Things to Know About Developers

August 16, 2009

No surprises here, or none for techs, anyway. A lot of the following sounds like banal repetition of common sense. But the thing about common sense is that it isn’t…common. And so, even after twenty years of Dilbert cartoons, I feel compelled to list a few points I want my non-tech colleagues to remember.

6 Things to Know About Developers

  1. We hate lengthy, freeform meetings.
    I’m really disappointed I have to write this it at all. I thought all the books, blog posts, satire, and research results had convinced everyone with at least functional literacy of the total buzzkill, the utter torment, the massacre of productivity, that the typical business meeting means for programmers and developers. And format doesn’t matter–don’t think that conference call is any less loathed.

    Solution: schedule only short meetings (<1 hour) with strict agendas, if you must schedule any at all.

  2. We really don’t need to see all of the marketing presentation.
    I don’t question that the marketing people worked really, really hard on what is just about the world’s best preso, the one that’s gonna reap all the financing and press attention. But I’d prefer to take your word for it; I’m about as enthusiastic and informed an audience for this material as the marketing people are for, let’s say, a prolonged discussion of JavaScript debugging tools.
  3. We require specifics.
    We can tell you’re excited about your idea, and it sounds to us like a good idea, and sure, let’s build it. But we can’t act on the sparse outline of it that you’ve provided: “It’s like MySpace–only for dogs!!” says nothing to us about where you want to start.
  4. We have specialties.
    Yes, there certainly are many people who can design an application, copywrite its content, write all the HTML/CSS/JavaScript for the interface, and develop all the scripting that communicates to an optimized, secure database. The people who can do all these things well are scarce. In fact, they’re usually not for hire since they’re too busy speaking at conferences or writing books.

    Scrupulous developers often qualify their self-descriptions with terms like “software,” “application,” “Java,” “Flash,” “user interface,” or “front-end” prefixed to the noun “developer.” You’ll save a lot of bother noting this qualifier, since it’ll keep you from asking software devs about JavaScript and front-end devs about Java.

  5. Not all of us are white, 20-something nerdboys.
    I don’t know why this stereotype persists. Many, perhaps even most, developers of my acquaintance fail to embody at least one of the qualities listed above. Maybe I just know a select coterie of middle-aged, female, humanities-educated, and/or non-Caucasian techs. Anyway, few of us seem anticipated by the majority of tech firms, who try to lure us into their employ with promises of foosball and all-you-can-drink Red Bull.

    Snore.

  6. We need fresh air and sunshine too.
    So many tech workplaces seem fashioned by prison architects: no windows, horrible, glaring fluorescent overhead lighting that is about a million times brighter than necessary, and even gray cubicle walls subdividing the room into a bunch of sensory deprivation chambers.


    How come you want to work from home?
    Photo by cackhanded

    Ask yourself if you could spend 8+ hours working where your devs do. Even better, take a high school algebra or trigonometry textbook, and try to work out the solutions to every problem in the textbook while seated in one of these spaces. If you can’t, it might not be entirely due to a failure in your math abilities.


What do you want everyone to know about developers?

Frameworks are tomato paste, not cake mixes

August 10, 2009

Alright, I’ll start by admitting I was wrong, all wrong: using frameworks isn’t a sign of laziness or incompetence. Today’s frameworks aren’t yesterday’s Hot Scripts or Dynamic Drive slop. They aren’t Dreamweaver cruft or FrontPage junk. Using them requires more than cutting and pasting; you use them better if you understand their basic technologies of JavaScript, CSS, and HTML. And you use them as replacements for something you do indeed know how to do by hand, but find so time-consuming or boring that you’re thankful somebody has provided the means for you to accomplish those tasks quickly.

Basically,
Frameworks are tomato paste, not cake mixes.

By “cake mixes,” I mean those boxes of processed ingredients, to which you just add one or two more, stir, then bake into the final product. The process requires very little time and almost no culinary skill. The mixes were first widely marketed in the 1940s to women who were anxious to produce acceptable cakes at home, despite time constraints in the servantless households of the post-war era.

Cake Mix Magic!
Hmm, jQuery or Prototype?
Image courtesy of saltycotton

Cut ‘n’ paste scripts or visual editor snippets work a lot like these mixes–there isn’t much tailoring you have to perform to have them function in your project. And like cakes baked from mixes, the discerning won’t mistake them for something made from scratch.

But sometimes you can obtain outstanding results using a pre-made ingredient.  One staple in many households is tomato paste, which replaces the lengthy process of transforming ripe tomatoes into concentrate. Yes, maybe using the freshly made paste would be superior, more satisfying–or maybe it wouldn’t. Most likely it would be drudgery, just as typing document.getElementById() can be. If your recipe is for the sauce, not the paste, spending so much time on one ingredient is inhibiting. So why not use a framework to get to your real project goal sooner and with less effort?

After all, frameworks don’t remove the challenge from the project. They take over the dull, utilitarian portions of it, like constructing a grid layout or a database query, freeing you to fret instead over PNG transparency in obsolete versions of Internet Explorer (no, wait; a framework could handle that too). Once you configure the framework, you’re freed to do more interesting tasks, such as choosing other frameworks to assume yet more of the burden. Certainly it feels odd the first time you let something like Blueprint float all the columns, but that shouldn’t be confused with weakness.

Think of all that time you can now use to make your own tomato paste.

Elements of a productive work day

July 22, 2009

Having spent the past few weeks playing Whac-a-mole on a project, and waking this day with some leftover sanity and a lot of work done, I think I’ve arrived at a framework.

Elements of a productive work day

  1. Turning off clients for IM, IRC, and e-mail. The benefits of working without distractions have been well-publicized.  I’ve long detested trying to work with IM and IRC anyway; this time I decided to enjoy hours of even deeper productivity by turning off e-mail as well except for an hour at 9am, 12pm, and 5:30pm.  Regrettably, many customers/project leads haven’t modernized to this way of working, so expect indignation when you try this.
  2. Queueing up the right tunes in Last.fm.  I prefer instrumental music when I work, since I won’t drift away into parsing lyrics.  Normally, I’m indifferent to classical music, but I like working to it, since it reminds me of being in a classy bookstore, instead of being huddled at a desk sweating over support for :hover in IE7. Strangely, both middlebrow “light” classical and less favored experimental works (try typing in “Delibes” and “Xenakis” into  Last.fm’s artist search) seemed acceptable background music.
  3. Configuring LeechBlock. I’ve got Firefox hot-rodded with loads of add-ons, and one of the newest to me, and most valuable, is LeechBlock.
    Get back to work

    Get back to work

    It works by blocking your browsing to certain sites after a given time period.  I set mine to a reasonable 25 minutes spent on my favorite time-wasting Web properties.  It’ll probably become a boast or social marker to confess which sites you find so compelling you require LeechBlock to take them away from you.  For the record, mine are Netvibes, Facebook, Twitter, Wikipedia, and the New York Times.

  4. Water. Seems so obvious, but a lot of people forget to drink water.  Granted, I’m lucky to have good tap water piped straight from the California mountains, so it’s not hard to choke down.  It also helps to have a glass you like.  Mine is an imperial pint that I refill four times, and which gets re-purposed for a good IPA at the end of the workday.

Think I skipped over something?  Add your suggestions in the comments.

5 Ways to Style dl

June 17, 2009

Tags: , , ,

Recently I lamented the rare usage of the supremely useful directory list, dl. The directory list is a pretty common data structure: one heading, followed by one or more related subsidiary data. It’s appropriate for more situations than it’s used for, probably because so many developers fixate on markup’s visual design rather than its information design. Browser defaults for dl obscure its versatility:

Firefox default for dl

Firefox default for dl

But there are so many occasions for which dl is the obvious data structure, once groomed by applicable CSS styling. As end users adopt standards-compliant browsers with better support for CSS 2+, styling dl into recognizable data structures becomes nearly fun, and will tempt you to try the ridiculous.

For instance, dl adapts readily to become the container for a recipe:

dl as recipe

dl as recipe

The CSS for achieving this assumes that you’re using one of those newfangled browsers with excellent support for CSS 2+:


dd {
display: inline;
margin: 0 .25em 0 0;
}
dd:before { content: " First, "; }
dd:after { content: ".  "; }
dd+dd:before { content: "Then, "; }
dd+dd+dd:before { content: "Finally, "; }

There’s a similar mechanism for forming dl into a citation:

dl as citation

dl as citation

CSS:


dt { font-weight: 700; }
dt:after { content: ":"; }
dt, dt:after, dd { display: inline; }
dd { margin: 0; }
dd:after { content: ","; padding-right: .25em; }
dl dd:last-child:after { content: "."; }

dl is, semantically, a good choice for an accordion menu, with a CSS :hover or JavaScript event attached to dt:

accordion, collapsed

accordion, collapsed

accordion, active

accordion, active

CSS:


dt {
font-weight: 700;
}
dt:after { content: "\203A"; padding-left: .25em;}
dd { margin-left: 0; visibility: hidden;}

dl:hover dt:after { content: "\2026"; }

dl:hover dd { visibility: visible; }

And then are ways to style dl which, yes, test the capabilities of CSS, but are just plain dumb. If, for instance, you feel compelled to style dl as a table or as a bulleted list, you should question why you’re using this particular markup, and not table or ul:

dl as table

dl as table

Picture 2

dl as bulleted list

The CSS for these stunts:


dl { display: table; }
dt {
display: table-caption;
font-weight: 700;
margin: 0;
text-align: center;
}

dd {
border: 1px solid #eee;
display:table-cell;
margin: 0;
padding: .25em;
}

dd {
display: list-item;
list-style: disc;
}

Versatility, it’s a burden.

Review: JavaScript Performance Rocks!

May 24, 2009

by Thomas Fuchs and Amy Hoy

by Thomas Fuchs and Amy Hoy

Title:  JavaScript Performance Rocks!
Authors: Thomas Fuchs and Amy Hoy


Pros:
  • Concise, easy-to-follow advice with good examples
  • Some overlap with other treatments of the same subject, such as posts on Ajaxian or the Steve Souders books, which reinforces the learning
  • Download includes the DOM Monster bookmarklet, which assesses a given page for conformance with the book’s recommended techniques
Cons:
  • Casual,  breezy tone in the prose which is hard to tolerate for very long
  • Idiosyncratic landscape format for page layout; difficult to read onscreen, terrible for printing out

JavaScript Performance Rocks! is yet another indicator of front-end development’s new status as something worth improving.  The authors examine where the scripting on a Web application interface frustrates or thwarts the user, and offer techniques either to speed up JavaScript rendering by various browsers, or to manage the user’s perception of that speed.  Some of the techniques will seem familiar if you have read much about JavaScript performance in the last two or three years–the greatest benefit this book gives you is having all that lore in one place, with justifications if you need to supply them when you use these on a project.

As of this writing, JavaScript Performance Rocks! is in beta.  When you purchase the download, you are assured of updates, which is necessary because some sections  remain incomplete.  I’m skeptical the final version will improve what I consider real problems with this book, which are in its prose and visual styling.   Both, I assume, are the results of the authors’ vision of delivering a technical book which would be fresh, hip, and not too serious.  Unfortunately, the youthful lingo wears–imagine having a hipster, like, totally, goin’ on about, you know, JavaScript? and you might experience the same impatience too many pages of this will give you.

More problematic is the book’s visual design.  I’ve looked several times at the landscape-oriented pages, trying to understand why they aren’t given the conventional portrait format.  I think the intention is that each page’s content falls “above the fold,” and the reader won’t need to scroll down to read it entirely.  However, on my monitor, this perfect layout only arrives when I reduce the page size in Acrobat Reader to 75%, which also reduces the fonts below my preferred level.   In any case, thinking of alternate presentations for this material is a needless distraction from it.

Included in your download of the beta is the marvelous DOM Monster utility.  If your questions about JavaScript performance concern an application you have already built, the DOM Monster gives you an easily comprehended diagnosis: where do you have too much whitespace?  Where are there empty nodes?  Do you have too many links to scripts and stylesheets?  I won’t be surprised to see this bookmarklet sold as its own product, given its immediate usefulness, but I’d be dismayed if developers used it without reading the accompanying text.  For, whatever its flaws, JavaScript Performance Rocks! comes highly recommended.  Like, all, hella recommended.  By me.

Older Posts »

Powered by WordPress