Survey the software you use for yourself, both browser- and desktop-based. Think about which applications provide the most invisible, effortless interfaces. I doubt it will be the ones that hide commands in complex menus and dropdown systems.

For some negative examples, let's look at Firefox and its more social cousin, Flock. Each app offers an advanced bookmark management mechanism, but the usability of that mechanism suffers in each due to over-reliance on cryptic menus.

Here's Firefox:

Can you guess which bookmark management options are going to appear under each menu? Where, for example, would the command for adding a separator live? What about sorting your bookmarks? Can't figure it out? Welcome to the world of evil icons.

For comparison, here's Flock, the social browser derived from Firefox:

Clearly, Flock provides friendlier menus; at least they've got text labels. With enough trial-and-error training, you'll probably be able to teach yourself which command lives under which menu.

Here's another example, this time from the webapp world: Confluence, the popular enterprise wiki package. Older versions of Confluence offered the by-now-familiar star icon. Click it, and a page would be added to your favorites. More recent versions, however, hide the "add favorite" option in one of several dropdown menus. Can you guess which?

If you guessed the "Add" menu, for "add to favorites," you're wrong. It's under the "Tools" menu. Welcome to the world of evil menus.

So where does that leave us? Must every single command available in an interface exist as an always-visible text link within the browser viewport? Of course not. But there are some best practices in choosing how to build our menus:

• Icons are great, but they should either be universally recognizable (such as a star or trash can) or paired with a text label.
• Menu groupings should be intuitive. Use care in choosing the top-level labels and don't group disparate items under the same menu.
• For frequently accessed functionality, consider leaving it as a dedicated clickable item on the page. There's nothing wrong with a mixture of icons and menus, the former for the most popular features and the latter for everything else.

Code organization

If I'm filling a front-end role on a Rails project, most of the files I need are in /app/views and /public. I dig that. Likewise, I appreciate the underscore naming conventions for partials. However, I wish /layouts weren't just another subdirectory of /app/views. Layouts are inherently different from standard view templates. A better hierarchy within /app/views would help drive this home. Likewise, I wish partials and full templates each had their own directory within a specific controller's view folder. That would help keep directories manageable on big projects. The /public directory, on the other hand, offers just the right amount of organization.

Markup and styles

Scaffolds are awesome for rapid prototyping, but the markup and styles they spit out reflect a standard of front-end coding that's several years out of date. Plenty of plugins tackle this very problem, but I'm disappointed to find so little attention to view-layer code from the core version of such a respected application platform.

In an ideal world, a platform famed for its convention-over-configuration approach would ship with a decent reset.css and a solid baseline stylesheet with reusable utility styles that rely on class rather than id attributes to work their magic. I'm not talking about layout so much as simple problems that have long been solved in the web standards world: pure CSS pipe-delimited lists, table-free form layouts and the like.

So much Rails development is about tweaking the defaults just enough to achieve the results you need. That means lots of crappy auto-generated markup ends up in production. Rails can't be all things to all people, but it would be cool if it didn't pump out antiquated UI code by default.

Macros and view-logic encapsulation

Tab-based templating systems make it easy to separate view logic from application logic. Whether you're using JSTL or a custom tag library, JSP 2.0 offers a specific syntax for templating that's different from the syntax used for model and controller logic. Sure, JSP tags compile down to Java, but they look different from regular Java. And sure, you can use scriptlets in JSP, but you don't have to.

In Rails, however, ERB looks like plain old Ruby code. It's hard to tell at a glance whether the Ruby contained in a template is doing view stuff or jumping the shark to tackle controller and model stuff. This makes it very difficult for either humans or automated tools to do sniff tests on Rails code for separation of concerns at the view layer.

Helpers exacerbate the problem. In JSP, if you need to create a view-layer macro, you do it as a tag. In Rails, you do it as a helper. But those helpers live in the same place as other, unrelated helpers from the controller. The result is a mixture of view code and controller code within the same directories and even the same files.

If experience has taught me anything, it's that controller logic and even model logic like to leak into the view. Without strong conventions to prevent this, it's too easy to compromise your MVC architecture and hinder the maintainability of your application. JSP offers better encapsulation of the view layer - a clear advantage.

JavaScript

I've posted before about my experiences dropping jQuery into Rails and making it work. I'm not a huge fan of the tight coupling between a specific JavaScript framework and the core server-side framework. Nor do I love the lack of built-in progressive enhancement on many of the Rails Ajax helpers. I get why it's attractive to people without dedicated front-end resources. But for anybody who wants to do a really sophisticated behavior layer, Rails Ajax helpers are more of a hindrance than a help. jRails and other projects offer a way to drop jQuery into a project and still access the Rails Ajax helpers, but I'd love to see a different approach to sophisticated Rails Ajax, one that doesn't create apps that break when JavaScript is unavailable.

Conclusions

Of course, I'm still a Rails noob and have probably missed all sorts of best practices that could help ameliorate the bad and accentuate the good. Let me know in the comments!

Lots of big-name, highly successful sites eventually reach a state of paralysis in which they're too scared of alienating their customers to examine their interaction design and information architecture from a fresh perspective.

The cautionary tale of Amazon.com

Look at Amazon: The online retailer adopted DHTML navigation just last year - at least 5 years after most other big sites - because its tab interface had grown so comically large. Nevertheless, huge chunks of the Amazon user experience are still massively broken:

• Once you've started down the checkout process, the site tries to keep you from getting back to your shopping cart to add or remove additional items. If you use your back button to do so, you've got to start the checkout process all over again.
• Wish lists offer perhaps the most confusing, error-prone user interface I've ever had the displeasure to experience.
• Link targets on a wide variety of UI controls are tiny and persnickety enough to elicit involuntary profanity.

Why does Amazon let its design blunders live on in perpetuity? It's simple: Redesigns confuse users, and confused users don't spend money. Your current customers have invested so much effort in learning to work around your site's shortcomings that a new interface stops them in their tracks. Even the most humane and usable UI refresh takes acclimation - and that may cost your site conversions and revenue in the meantime.

The agony and the ecstasy of the redesign

I learned this lesson the hard way during my days at Reflect.com and Orbitz, where A/B testing constantly shocked us by revealing that change, any change, causes key metrics to dip, at least temporarily. Redesign an unusable feature and test the old and new versions with your current customer base on the live site. Chances are, the old version will win in the short term. That's why it takes guts to even consider a top-to-tails redesign. If small changes can have a negative impact, big changes could be deadly.

To me, however, it seems as if the bigger danger lies in allowing your site's information architecture to become ossified. Eventually, new UI paradigms will offer your younger competitors an avenue for feature differentiation. I was at Orbitz when Kayak.com launched, and I was sick with envy that a site could push the user experience of online travel into such new and compelling directions. I knew a company as large as mine could never rock the boat by switching to such an off-the-wall UI.

Sure, budget aggregator Kayak wasn't a direct competitor to an online travel agent like Orbitz. But if somebody had launched a full-service OTA with an interface as fresh as Kayak's, then Expedia, Orbitz and Travelocity would have been forced to play catch-up. After all, it was UI differentiation that had originally allowed Orbitz to woo customers from other, more established competitors: Its matrix-based results pages provided a compelling new way to find cheap seats. Eventually, though, other sites copied that feature. Now, all the big OTAs match each other feature for feature.

Beta sites: Hope for the future

That's what's so impressive about today's crop of Web 2.0 upstarts. A young service such as FriendFeed can offer an entirely separate, opt-in beta site and tinker away at it without annoying current users. Then, once the geekier end of the user base has helped work out the kinks, the service can flip the switch and roll out its new features to everyone. That's exactly what Facebook did with its new interface, but at far greater risk than FriendFeed. Facebook may be obscenely overvalued, but it does function as a business. A redesign is far less scary for the relatively unmonetized FriendFeed.

Regardless of whether you're a social networking giant or a microblogging upstart, this kind of usability and design lab has become de rigueur. By acclimating your users to frequent change early on, you can help ensure that future refreshes don't send them packing. Amazon may be in a design coma, but your site shouldn't have to be. Have the courage to redesign early and often.

First up we have Flickr, whose homepage redesign emphasizes the social networking aspects of the service. A Recent Activity feed, modeled on Facebook's iconic News Feed, showcases favorites and comments from your contacts. The default view for each item displays its age. When the user hovers, though, the same real estate becomes home to two icons. One allows you to add your own comment; the other "mutes" activity related to that photo and removes it from your feed. Neither option is represented by an industry-standard icon, and no tooltip is provided. Even the status bar shows only an inscrutable URL: a hash sign.

Next up we have Twitter, whose new homepage provides a similar user experience to that of Flickr, with two important differences: Rather than re-use existing real estate for its clickable context commands, Twitter re-purposes existing whitespace. And instead of cute, mysterious pictograms, Twitter uses industry-standard icons: a trash can and a star. For users schooled in the conventions of Web 2.0, it's obvious that the two icons, when clicked, will either assign "favorite" status to the item or delete the item altogether. For users without such a background, however, there are still no tooltips.

Finally we have Facebook, whose own News Feed now offers mouseover context commands. Unlike Twitter and Flickr, however, the social networking giant rolls all context options up into a single Options menu which is represented by text AND an icon. Users who click on the word or image see links such as "More about Brian, "Less about Brian, "More Status Stories" or "Fewer Status Stories."

Based on all of these examples, I'd say only Twitter hits the Web 2.0 sweet spot where simple, clear icons communicate everything you need to know about a feature. Even then, it would be nice if tooltips provided even further context. Facebook's approach goes further than Twitter's in guaranteeing that users always know what's going to happen when they click. But it's too fussy. Hover to see that there's a menu, click on the menu header, then finally see the available commands and click on one of them. When there are many options, that makes sense. But when there are two (a paired set of more/less links) it seems like overkill.

Flickr provides the least usable variation on this design pattern. The absence of both recognizable icons and tooltips turns context commands into a guessing game.

In terms of usability, however, there's another design pattern that trumps all of these options for clarity and usability: FriendFeed, which takes a very different approach to context commands. Items in FriendFeed now offer a very Web 1.0 grocery list of actions, all spelled out plainly in text and all visible regardless of hover state. Newbies and experts alike have instant access to popular commands such as "Comment," "Like" and "Hide." There are no wordless icons and no hover states. The only menu option that involves hide/show is the "More" submenu at the end of the list of options. Here, a down-arrow clearly indicates that this is dropdown. As expected, it contains additional, less popular commands for linking or resharing entries.

So I'm watching the big Apple notebook event and getting totally excited about the impressive new graphics capabilities. Finally I'll be able to get decent visuals on World of Warcraft on a Mac laptop. Then we get to the part about the new trackpads and my excitement wanes. Once again, Apple is opting for ultra-minimalist hardware and then using software to compensate (poorly) for that design choice.

Here's Steve Jobs:

We've got a new trackpad for notebooks. It's a gorgeous, large, multitouch glass trackpad for notebooks. It's 39 percent larger tracking area than before, it's multi-touch for gestures, it's glass for silky-smooth travel. And we've optimized the coefficient of friction on the glass, so it's really beautiful. And the entire trackpad is the button. It gives you more area on the trackpad and keeps you from hunting for that button. You can get multi-button support from software. And we've added some new four-finger gestures that are really nice.

Four-finger gestures may be really nice, but I'd opt for two hardware buttons any day. Whether you're playing video games or simply using productivity and development apps, you should be able to summon context menus without having to resort to arcane gestures. Apple's obsession with scaling hardware down to its essence may result in beautiful products, but usability almost always suffers. Need some more examples?

• iPod volume controls: Ever since the original model came out in 2001, users have had to cope with the iPod's irritating lack of a physical volume control. If your music library's like mine, the volume levels change drastically between tracks - even when you tell iTunes to level things. It's pretty annoying when the track changes from a quiet one to a painfully loud one while you're busy navigating some random menu. You've either got to rip your earphones out of your ears or painstakingly navigate back to "Now Playing" so you can once again adjust the volume. Then there's the single button that toggles between volume control, fast-forward, star ratings and media info. There's nothing more annoying than trying to fast-forward through a track using the slider control only to accidentally crank the volume all the way up and deafen yourself.

• Mighty Mouse: Worst mouse I've ever purchased - and also the most overpriced. The promos claimed that the single giant "button" would create a right-click or a left-click depending on how I pressed it. In reality, no matter how carefully I tried to attune my muscle memory, half of my right-clicks ended up as left-clicks instead. In the end, I disabled right- and left- click capabilities and went back to using the stupid option key. Then I really wised up, threw the Mighty Mouse in the garbage and bought an extremely ugly but extremely functional Microsoft notebook mouse.

• iPhone phone interface: The iPhone works great as an Internet device, but it's a lousy phone - and not just because of AT&T's immature 3G network. No, the real problem with the iPhone-as-phone is that its menu system is such a minimalist trainwreck. I can summon my "Favorites" list with a double-tap of the phone's single hardware button. But to get to any of the other sub-menus within the Phone application, I must launch the app, get my bearings - because the app retains whatever sub-menu I was using last time around - and then click an icon to get to Recents, or Voicemail, or Keypad. Actions that required a single click on a dedicated hardware button on my crappy old Motorola phone take three clicks and a lot of decision-making on the iPhone. Then there's the menu system once you're actually in the middle of a phone call - you know, the one that requires you to choose "Keypad" from a list of options before you can even respond to a standard touch-tone interface.

My point - and I do have one - is that minimalism should be a means to an end; the end itself should be usability. Simplifying a device's hardware does no good if it means forcing the user to think about how the software interface works. I'll almost certainly purchase one of these notebooks - possibly several. But as with so many Apple products, I'll curse softly nearly every time I use it. Apple's products are the best thing going in the notebook market, but they could still be so much better.

I'm excited to announce the arrival of Blackbird, an open-source JavaScript logging and profiling utility written by G. Scott Olson, a former colleague from my days at Orbitz Worldwide.

A previous iteration of Blackbird provided no-nonsense, cross-browser logging on a variety of projects within Orbitz. Since that iteration, known as jsLogger, Scott has re-written the code from the ground up; provided tons of useful new features, including custom namespacing and a spiffy new graphical interface; and released it under an MIT license.

Why, you might ask, in the age of Firebug, would anybody need a JavaScript logging utility? Simple:

• Blackbird works in a wide variety of modern browsers. Write one style of log statement for every browser.
• Blackbird can be deployed to production. By stubbing out its public API with empty functions, you can leave your log statements in production code. (I'm not endorsing this approach to code maintenance, just pointing out that Blackbird makes it easy.)
• Blackbird does one thing and does it well. It's not a debugger, it's just a logger and profiler.
• Blackbird doesn't interfere with Firebug's console.log utility, but it does improve on its interface. You can hide or show the Blackbird modal with a single, customizable keystroke. You can also choose from four levels of logging (debug, info, warning and error) and atomically toggle their visibility within the console.

The Blackbird project now lives at Google Code, where you can download it and learn about how to contribute.

The Ajax Experience last week in Boston yielded lots of exciting developments on the Ajax history management front:

• My talk itself drew a crowd of 110 people or so despite its 8.10 a.m. start time. I received good questions from the audience and didn't notice too many people heading for the doors when they realized how deep into the nitty-gritty technical details I was getting. Instead of using Keynote or Powerpoint for my slides, I built a basic DHTML application. That way, one artifact could serve as both my content and a demo of Really Simply History, the Ajax history and back-button library I maintain. You can view the application - and the slides - at Pathfinder Labs.

• I did not meet my goal of releasing an alpha of Really Simple History 0.8 in conjunction with the conference. But I did accomplish a ton of work on the library during the build-up to my talk. I'm now hard at work finalizing the alpha and preparing updates to the project's Google Code-hosted homepage.

• The most exciting Ajax history development was the face time I enjoyed with Nathan Hammond, creator of JavaScript State Manager (JSSM), and Brad Neuberg, original creator of Really Simple History. After my talk we enjoyed an impromptu Ajax back-button summit and hammered out a shared agenda for the future of both my library and the topic in general. I'm pleased to announce that Nathan will be coming on as an RSH co-maintainer with the goal of merging RSH 0.8 and JSSM into a single, stable 1.0 library. I'm also excited that Brad, Nathan and I - plus other authors of Ajax history libraries who wish to participate - will be issuing a position paper on the current history implementation in the HTML 5 spec. Ajax history experts, please contact me via Pathfinder if you want to weigh in.

• As for the conference itself, it was my first time attending The Ajax Experience and I really enjoyed it. The topics were many, varied and well-presented. My favorites included Douglas Crockford's discussion of JavaScript's good parts, which could have been a simple book promo but turned out to be far more; the panel discussion between the leaders of YUI, Dojo, jQuery and Prototype moderated by the inimitable PPK; and my colleage Dietrich's un-sexy but vital look at how to resurface J2EE apps for Ajax using the Google Web Toolkit.

  I have to say, the crowd here felt like my tribe. The guys running around with the word "JavaScript" shaved into their hair put a smile on my face. Ajax developers are often third-class citizens at other conferences. They're either jammed together with designers and user experience folks, or thrown into the midst of Java and Ruby developers. That wasn't the case here, and I dug it highly.

  My least favorite aspect of the conference had nothing to do with the crowd or the content; it was the depressing lack of vegan food. One meal was 90% vegan, but most were 0%. Given the conference center's distance from civilization, it would have been nice if attendees' diverse dietary needs had been taken into consideration. On the plus side, I think I lost five pounds.

Many thanks to the folks from Tech Target for the awesome speaker support. My name, so amusingly misspelled on the monitor outside the ballroom where I spoke, had been corrected by the time I took the podium.

And special thanks to Ben, Dion and everyone at Ajaxian for throwing such a jam-packed event, letting me speak at it, and doing so much for the Ajax community over the years.

I'm posting today from Boston, where my colleague Dietrich Kappe and I are proud to be presenting at The Ajax Experience 2008.

At 5.10 p.m. tomorrow (Tuesday 30 September), Dietrich will present "Saving Your Investment: Transforming J2EE Applications into Web 2.0 Using GWT." This 90-minute session will introduce noobs to the Google Web Toolkit; school experienced GWT developers in the security implications of leaky client-side business logic; and delight business folks and bean-counters alike with the money-savings possibilities of retrofitting a legacy webapp instead of building a new one from scratch.

At 8.10 a.m. the following day (Wednesday 1 October), I will present "Making Friends with the Browser: Ajax, Back Buttons and Bookmarks." In it, I'll look at the state of Ajax history management, from new libraries such as the JavaScript State Manager and dsHistory to my own project, Really Simple History. I'll discuss the problems and tradeoffs inherent in any browser history manager. I'll also examine the impact of new browsers such as Google Chrome and Microsoft Internet Explorer 8 on this small, rapidly evolving corner of the Ajax world.

We look forward to seeing some of you there and reporting back about the rest of the conference.

CSS 2.1 is more like a Swiss Army knife than a fully stocked toolbox. We can accomplish a lot, but we have to get creative with the standard attachments. Floats, relative positioning, the box model - each tool must performs double or triple duty because they're the only ones we've got.

When we do discover a clever way to accomplish a common task using these limited tools, we're likely to employ that technique over and over. I'm not talking about CSS frameworks here; those help out more at the macro level. I'm talking about repeatable techniques that can be applied at the micro level. When done right, these simple techniques can feel like entirely new Swiss Army attachments rather than intelligent application of existing blades.

Whenever I start out on a new client project, I start off with the following plug-and-play components:

1. A reset stylesheet: Sometimes I plug Eric Meyer's latest reset in wholesale, while sometimes I pick and choose which parts make sense for my project. Regardless, it's absolutely essential to erase default styling and provide a common, cross-browser foundation on which to build.

2. Semantic, cross-browser float-clearing: I posted about this topic a year ago, generating plenty of debate. Whether you're using my Orbitz-inspired grocery-list-of-selectors approach or a generic clearfix class, you've got to tackle this problem if you employ float-based layout - until, that is, some future CSS spec implements a float-clear property.

3. Standard-issue pipe-delimited lists: If you're representing lists as paragraphs full of text punctuated by hard-coded pipe characters (|), you're probably not paying much attention to web standards. A set of CSS rules like the following makes it dead simple accomplish the same effect semantically with borders. True, Internet Explorer 6/7's lack of support for the first-child pseudo-class means you'll have to create an actual class called first-child and apply it to your initial list element. Still, once you adjust border colors and spacing to fit your site design, this solution works anywhere. Variations can even allow for pipe-delimited definition lists.

   /*
   	standard pipe-delimited list: add a class
   	of "first-child" to the first element
   	for IE either via script or in the markup
   */
   
   /*
   	- the 0 margin and padding are unnecessary if
   	  you're using a standard reset stylesheet
   	- you'll need to clear floats inside of ul.piped
   	  using whatever your preferred method is
   */
   ul.piped {
   	margin: 0;
   	padding: 0;
   }
   ul.piped li {
   	float: left;
   	margin-left: 8px;
   	padding-left: 8px;
   	border-left: 1px solid #000;
   	list-style: none;
   }
   ul.piped li:first-child,
   ul.piped li.first-child{
   	margin-left: 0;
   	padding-left: 0;
   	border-left: 0;
   }
   

4. Simple hide/show utility classes: Unless you're using an effects library to create visual transitions, it's easier to toggle classes on hide/show elements than to manipulate their style properties directly. The only problem is differentiating between block and inline elements when you're ready to show them again. That's where the block, inline, noneBlock and noneInline classes come in. Your JavaScript code just needs to know that elements with a class of block get toggled to noneBlock and vice-versa; same for elements with a class of inline and noneInline.

   /* classes to hide and show elements programmatically*/
   
   .inline {
   	display: inline;
   }
   .block {
   	display: block;
   }
   .noneInline,
   .noneBlock {
   	display: none;
   }
   

5. A style-as-link class for JavaScript actions: It's easier - not to mention more semantic - to trigger JavaScript code from click events on divs, spans or other non-anchor elements. That way, you don't have to deal with a dummy href value or cancel out the link's default action. Besides, the <a href=""></a> tag is for taking you to new pages, not performing an action within the existing page.

   Some JavaScript coders ignore these advantages because they want the built-in styling shortcut of the a tag: cursors and hover states. As the code below demonstrates, however, it's dead simple to achieve the same visual effects with some simple CSS. Modern browsers can apply the hover pseudo-class to most any element. Ditto custom cursors.

   a,
   .styleAsLink{
   	color: #08c;
   	text-decoration: none;
   }
   a:hover,
   .styleAsLink:hover{
   	color: #444;
   	text-decoration: underline;
   	cursor: pointer;
   }
   

   Once you've created a styleAsLink class, you can replace this type of code:

   <a href="#"
   onclick="alert('Isn't it annoying to have to return
   false every time?'); return false;">
   	this is an actual link
   </a>
   

   ... with this:

   <div class="styleAsLink"
   onclick="alert('In the real world the click event
   should be applied unobtrusively!');">
   	this is a pseudo-link
   </div>
   

   One caveat: This technique is useful for links that serve no other function than to trigger JavaScript code. Don't employ it in the case of a progressively enhanced link that triggers a script when JavaScript is available but takes you to a new page when it's not. A simple rule of thumb: If the link exists in your actual markup, it should remain a link. If it's inserted into the DOM wholesale by JavaScipt, it should be a pseudo-link.

Enough about my own personal Swiss Army attachments. How do you get all MacGyver with your CSS? Let us know in the comments.

1. lack of documentation
2. lack of time

The essential functionality of RSH works well in most supported browsers, but there are several special cases that have to be coded around in your actual application. Even basic usage, however, is documented mostly through example, not through tutorial-style, narrative prose. This has resulted in lots of noise in the issue tracker from folks seeking guidance on how to use the library. For all the folks whose questions and bug reports have gone unanswered, I offer a sincere and heartfelt apology. And to the more experienced users who stepped up to answer questions and help out, I offer heartfelt thanks.

The launch of Safari 3 caused some serious problems because code created to work around Safari 2's deficiencies caused things to break in Safari 3. I should have accepted suggested patches from some gallant RSH users and pushed out a new version months ago. But to be honest, I was so swamped with paid client work for Pathfinder that I couldn't find the time. I've learned my lesson about brittle, browser-specific workarounds. The next version of the library will fail far more gracefully.

Speaking of the next release: RSH 0.8 is nearing completion. I expect to publish an alpha version to coincide with my presentation October 1 at The Ajax Experience. My talk covers lots of interesting developments in Ajax history management, and I figured I should, you know, deliver the goods to my users before getting up on that stage.

I'll post soon with some information about the new technical direction RSH has taken, but here's a taste of what's to come. RSH 0.8 will offer the following:

• a smaller footprint
• a new API
• easier configurability
• less complexity for mainstream use cases
• explicit support for IE8, Safari 3, Firefox 3, Flock and Chrome
• more modularity and pluggability thanks to functional programming patterns espoused by Douglas Crockford
• easier integration with popular Ajax toolkits
• bug fixes

My vision for 1.0 centers around a full test suite, configurable downloads, expansive documentation and better mobilization of the RSH community. By the time we get to 1.0, I want to make sure there's no longer a single bottleneck for continuing development. I look forward to getting on with it starting at The Ajax Experience.

During a recent GTD weekly review, I suddenly realized how many distractions had worked their way into my daily office routine: personal email, personal instant messaging, entertainment feeds, Facebook. I suspect such time-wasters pose a bigger danger to web developers than to other professionals, if only because the programs they run in are so central to our work. I run Firefox for web development, Adium for instant messaging, and NetNewsWire for industry news all day out of necessity. If I allow my personal distractions to jump out at me from those programs, my productivity plummets.

This weekend, I worked hard to de-tangle my professional and personal lives. My tools? Flock, the Mozilla-based "social browser," and Meebo, the browser-based IM aggregation service. My goal was to separate all personal bookmarks and RSS feeds from NetNewsWire and Firefox into Flock, then move all my personal IM accounts from Adium to Meebo. The end result was a self-imposed firewall between productive time and fun time. (Thanks to many a Lifehacker article for the basic idea, if not the implementation.)

Getting started with Flock

Flock represents a noble attempt to shoehorn social networks and other web utilities into the chassis of a Mozilla-based browser. Sure, many of its features could be achieved in a standard Firefox install. But I didn't want to have to run two copies of Firefox, one for work and one for play, and manage separate user profiles for each. Besides, my goal was to create a hub for my online social activities, so why not use a browser specifically designed for that purpose?

I also could have moved my social stuff to Safari, but that would have required adjusting to the quirks of a browser I'd previously employed only for cross-browser development. Flock 2 beta is essentially a tricked-out Firefox 3, so it offers a pretty seamless transition for this Mozilla. It even runs my essential Firefox 3 extensions, such as Foxmarks and Tab Mix Plus. With those in place, Flock looks like a souped-up sedan version of Firefox - slower, sure, but with more bells and whistles and a pretty coat of paint.

One feature that especially interested me was Flock's RSS integration. Sure, Firefox does this, too, but Flock's interface is nicer. You can interact with your feeds in a familiar two-pane interface rather than simply viewing headlines from a Live Bookmark. Flock's UI doesn't yet match the convenience of the keyboard-friendly NetNewsWire, but that's fine. I can live without power-user features when I'm just perusing The Consumerist or Whedonesque.

After a few days of using Flock to browse Facebook, scan FriendFeed, check Gmail, update Twitter and attend to my online banking, I'm sold. I don't really use the widgets on the My World splash page very much, but the integrated toolbar for interacting with Web 2.0 destinations works seamlessly. It's nice to be able to check for unread mail without firing up the entire Gmail interface. And I'm certain I'll use some of the blogging tools pretty frequently. One downside, though: You can't adjust fonts in the People Sidebar and other Flock-specific XUL widgets. My poor, aching eyes will forgive this misstep for now.

Getting started with Meebo

Instant messaging wastes as much time as it saves. Commingling of friends and coworkers on the same buddy list has always been dangerous. But even if you're careful, you'll get bleedthrough. Today's valued colleague often becomes tomorrow's high-maintenance friend once somebody switches jobs. Unless you want to give everybody you've ever known equal power to interrupt your work, you need a strategy for separating IM accounts. Creating a new account each time you start a job isn't enough. Hence my decision to segregate my accounts into two separate programs.

Cross-platform IM clients continue to proliferate, but web-based Meebo offers an interesting take on the concept. With its clean interface, soothing palette and lightning-fast Ajax interface, Meebo applies tried-and-true Web 2.0 design techniques to dowdy old chat. I used to have five IM accounts in my local Adium instance, but now I've moved four of them into Meebo. When I want to chat with friends, I can fire up Flock and open a Meebo tab. But when I need to focus on work, I can just shut it down and leave Adium open for agile team interactions at Pathfinder.

As with Flock, there's nothing about this setup that I couldn't have accomplished without Meebo. I could manually log off my non-business IM accounts whenever I want to focus on work. But I'm sufficiently prone to procrastination that such measures don't work. I need to trick myself psychologically, creating a completely different context for work chat and personal chat. Warm, inviting Meebo generates some much-needed contrast with cold, functional Adium.

Now the hard part: Sticking to the rules

Of course, prying apart the personal and the professional does no good if you're constantly firing up your fun apps alongside the work ones. Now that I've segregated all my time-wasting feeds, distracting chatter and enticing games, I've got to stick to the single rule that makes everything work: Only run Flock-plus-Meebo at specific intervals. I'm giving myself 15 minutes during morning coffee, 30 minutes at lunch, and unlimited time once I'm home at night.

It may seem counter-intuitive to get down to work with the help of two applications designed primarily for fun. But the work/play firewall helps me stay disciplined.

I've been an iPhone 3G owner for about six weeks now - six weeks of love, loathing, cool apps and connectivity problems. Rather than complain about poor network coverage, though, I'd like to delve into some of the vexing usability problems that hamper the phone's user experience.

No ability to disable autocorrect completely

Like pretty much every autocorrect feature ever built, the iPhone's does more harm than good. It always thinks it knows best. If you don't watch it like a hawk, it will render everything you type completely nonsensical. Proper nouns, abbreviations, profanity - all get turned into gibberish by this well-meaning but deeply flawed function. And god forbid you try to use the classic email e.e. cummings mode in which uppercase letters don't exist. The iPhone literally will not let you output the word "iPhone" without throwing in that capital "P." It's maddening.

If the purpose of autocorrect is to allow you to type quickly without having to monitor your output, it fails miserably. On the iPhone, if you want what you type to show up verbatim on the screen, you have to pause at the end of each word to ensure that the OS is not about to substitute its own wisdom for your actual intent. I would honestly rather type on a 1999-era StarTAC numeric keypad.

None of this would be as galling if there were a setting to turn this feature off. But there isn't. Elaborate, unwieldy workarounds have been suggested - all because Apple users know that the folks in Cupertino often paternalistically ignore their users. Microsoft's OS and apps may suck, but you can usually customize the hell out of them. Not so Apple's.

No saved password feature

Everybody and their brother has complained about the iPhone's virtual keyboard. Aside from the autocorrect feature, I think it's actually pretty good for composing email or SMS messages. But for passwords, it blows.

If you've got a strong password, chances are it's a combination of upper- and lowercase letters, numbers and special characters. That means you've got to switch back and forth between screen modes constantly. (And don't get me started on the way the iPhone automatically switches from numeric to alpha mode when you hit certain special characters.) Sure, it's nice that the phone shows you the most recently typed character in any password field so you can verify it's correct. But it's still such a painful, error-prone experience that once I've typed a password into my iPhone once, I want the phone to remember it forever.

No dice.

Mobile Safari has no built-in password manager. Sure, you could install an app like 1Password to get this functionality, but that means paying $29.95 for a feature that should be baked into any web browser - especially one that makes typing strong passwords such a maddening experience. Lots of iPhone users are downgrading to simple alphabetical passwords just so they can make this process less painful. That's a real blow to web security - especially the security of Apple accounts, whose passwords you've got to type over and over and over again on the iPhone just to perform such simple tasks as updating free applications.

No love for existing mobile stylesheets

I get it: Mobile Safari isn't like the other mobile browsers. It's got all the features of a real browser and can display web pages as they were originally designed.

But should it?

Pan-and-scan browsing makes for an incredibly frustrating user experience. Visual hierarchies that work wonderfully in an 800x600 or 1024x768 desktop viewport completely fail when they're reduced to the size of a deck of playing cards. Zooming in on little sections of the screen doesn't alleviate the problem. Mobile Safari's scaling abilities are impressive, but they're no substitute for a properly optimized interface.

Sure, you can serve up custom styles for Mobile Safari's viewport, you've got to use an extremely specific media queries. Normal mobile stylesheets are ignored:

<link href="mobile.css" rel="stylesheet" type="text/css" media="handheld" />

Instead, you've got to go the extra mile:

<link media="only screen and (max-device-width: 480px)" href="iPhone.css" type="text/css" rel="stylesheet" />

Why ignore the hard work of sites that have bothered to develop a mobile stylesheet? Why not at least offer a setting that will enable these stylesheets on a site-by-site basis? Failing that, could we at least have the ability to disable CSS altogether for certain sites? For the minority of sites with a lovely iPhone interface, Mobile Safari offers a great user experience. For almost everything else, it blows.

No default keypad in phonecall mode

Almost every phone number in the world is hooked up to some sort of touch-tone interface. From giant corporate phone trees to individual voicemail accounts, we live in a world where the lingua franca consists of 0-9, # and *.

So why doesn't the iPhone expose a numeric keypad by default during phone calls? To type an extension or navigate a phone tree or hit "0" to skip a voicemail greeting, one must stare at a row of icons for such rarely used functions as three-way calling, press the icon for the numeric keypad, and only then see the desired digits to tap. Sure, it's only one extra click. But considering this is the mainstream use case for most phone calls, shouldn't it be easier? Couldn't Apple at least offer a preference to show the keyboard, rather than the special features, by default?

No memory of wi-fi network preferences

If I don't have a WEP password to my neighbor's wi-fi network, I'm never going to be able to connect to it. But the iPhone has no capacity to remember that choice. If I have "Ask to Join Networks" turned on in my settings, it will ask me to join every network it finds. If I say "no" to a specific network, it'll keep asking me every time I launch an Internet-aware application within range of that network. My only choice is to turn off "Ask to Join Networks" altogether ... which means I won't be notified when my phone finds a network with unrestricted access. All it would take is a simple "ignore the existence of this network forever" button to banish a constant annoyance.

Does this irritant rise to the level of usability blunder? No. But it sure gets my teeth grinding.

In last week's post, I introduced the linked multiselect widget I was asked to implement on a tight deadline for an unexpected project assignment. I showed some demo code in action and discussed the user experience issues that shaped my requirements. This week, I'll walk through the actual code - or at least my first pass at it.

Like a lot of developers who should know better, I sometimes shirk the technical design phase on quick projects, then regret it later. The code I handed off for this project got the job done, but it wasn't very DRY or elegant. Luckily, I've continued to refine it into something I'm not ashamed to blog about. Next week, I'll show off the final, refactored code and try to draw some conclusions about the entire experience. But first - the original, unrefactored code:

The good

Working with new jQuery plugins always makes a project more interesting. I decided now was the time to get started with Dan Webb's Low Pro for jQuery, a library that adds class-based inheritance and other syntactic conveniences to the jQuery object, including an attach method for linking DOM nodes to prepackaged behaviors. The best, most reusable code I wrote for my initial pass at this project was constructed using Low Pro.

One requirement for my project was the creation of a simple color fade effect to signal DOM updates to the user. Using Low Pro, I was able to abstract this single behavior into its own reusable class for deployment within my larger application. The code looks like this:

//a reusable class to add
//a classic Web 2.0 yellow fade
//to DOM elements that have changed
SignalChange = $.klass({
  defaults: {
    //length of the fadeout
    duration: 1250
    //baseline and highlight colors
    , defaultBorderColor: "#ccc"
    , defaultBackgroundColor: "#eee"
    , highlightBorderColor: "#000"
    , highlightBackgroundColor: "#ffa"
  }
  , initialize: function(options) {
    var opts = $.extend({}, this.defaults, options);
    $.extend(this, opts);//just copy over all the options
  }
  , onredraw: function() {
    var that = this;
    this.element
      //cancel previous events of this type
      .stop("onredraw")
      .css({
        backgroundColor: that.highlightBackgroundColor
        , borderColor: that.highlightBorderColor
      })
      .animate({
        backgroundColor: that.defaultBackgroundColor
        , borderColor: that.defaultBorderColor
      }, this.duration)
    ;
  }
});

$('.multiselect .scrollbox').attach(SignalChange);

jQuery pros will notice that the CSS magic in my onredraw method relies on jQuery Color Animations, a tiny little add-on by jQuery creator John Resig that extends the library's core FX mechanism to handle color transformations. In fact, I had to hack the plugin itself, since it handles borderBottomColor, borderLeftColor, borderRightColor and borderTopColor - but not borderColor. Strange, that, but I got over it. I wanted my color fade effect to support borders as well as backgrounds, and it seemed easier to add a single item to an array in the plugin than to handle each section of the border separately in my own behavior.

The syntax of Low Pro's klass method looks pretty similar to Prototype's Class mechanism, which makes sense. The original Low Pro is a library for making Prototype more like jQuery, while Low Pro for jQuery is designed to give Prototype-style support for large, complex and subclassable objects to jQuery.

Notice some of the elegance in Webb's syntax: Any method that conforms to the onwhatever naming convention is assumed to be an event listener - even if it's a custom event such as my own onredraw. Once I've pointed my SignalChange behavior at a DOM node using the attach method, I just need to fire that event to trigger my custom listener. The same is true for native events.

Given the simplicity of my behavior, it could easily have been constructed as a plain old jQuery plugin. But even for such a low-level behavior, Low Pro offers some advantages:

• If Live Query is running, then any calls to Low Pro's attach method are routed through Live Query so they'll be applied to all matching DOM nodes, even those constructed subsequently via DHTML or Ajax.
• I can also subclass my behavior more easily using Low Pro than jQuery's built-in plugin mechanism.

This inheritance becomes all the more important when your behaviors are more complex, with multiple linked event listeners. Because you can just subclass a Low Pro klass, you don't need to overload it with some insane options hash. You can just create a new subclass for each slightly different implementation. I'll take advantage of this mechanism in the refactored code I show off next week.

The not-so-good

In the meantime, I have to take responsibility for the other Low Pro klass I created in this initial version: Subscriptions, which you can view in full in the source code. Before I get into this code's deficiencies, let's look at what it does right:

• It makes great use of jQuery Templates to simplify the construction of DOM nodes. Templates such as the following keep me from having to concatenate strings to create my on-the-fly markup:

    this.tmplMemberView = $.template(
      '<div class="item">' +
        '${name}' +
        ' <span class="info">(' +
        '${groupCount:pluralize(group)})</span>' +
        '</div>'
    )
  

  I even added some useful helper methods to the template method so I could customize the formatting of my templates:

  //add some additional template helpers
  //for the template plugin;
  //use these to format our markup
  $.extend($.template.helpers, {
    addConditionalClass: function(value, trueClass, falseClass) {
      return value === true ? trueClass : falseClass;
    }
    , addIfTrue: function(value, conditionalText) {
      return value === true ? conditionalText : '';
    }
    , addIfFalse: function(value, conditionalText) {
      return value === false ? conditionalText : '';
    }
    //only works for standard plurals
    , pluralize: function(value, label) {
      return value + " " + label + (value != 1 ? "s" : "");
    }
    , count: function(value, label) {
      var r = value.length || 0;
      if (label) {
        r = $.template.helpers.pluralize.call(this, r, label);
      }
      return r;
    }
  });
  

• It leverages Live Query to attach permanent behaviors to DOM nodes that get destroyed and recreated many times over the application lifecycle.

• It does a good job of wiring up the complex interactions between two interdependent linked multiselects.

However, my code accomplishes most of these things in a most inelegant way. Looking back, I should have modeled a more complex object hierarchy with some sort of reusable LinkedMultiselect object. My Subscriptions object should have been responsible solely for wiring together two of these LinkedMultiselects and enforcing data dependencies between them.

By starting with one great big all-encompassing class, I ended up having to everything four times: once each for the "selected" and "unselected" states of each of the two linked multiselects. The result is code like this, in which I have to create a single method and then create four more methods to bind it to different circumstances:

, getSubGroup: function(coll, prop, state) {
  return $.grep(coll, function(n) {
    return n[prop] === state;
  });
}
, getSubscribedMembers: function() {
  return this.getSubGroup(this.members, "subscribedNow", true);
}
, getUnsubscribedMembers: function() {
  return this.getSubGroup(this.members, "subscribedNow", false);
}
, getEligibleGroups: function() {
  return this.getSubGroup(this.groups, "eligibleNow", true);
}
, getIneligibleGroups: function() {
  return this.getSubGroup(this.groups, "eligibleNow", false);
}

By now, we've all been exposed to enough proper object-oriented JavaScript to do better than this. I know I certainly have, but I fell into the trap of coding rather than designing first. I look forward to showing you the refactored version next week.

Last week I spent a couple of days lashing together a UI widget for a project that needed a little Ajax assistance. As always, I looked for an opportunity to learn something along the way, so I got signoff on using jQuery and some plugins I hadn't previously employed.

The result? A down-and-dirty mini-project that let me test drive Color Animations, jqModal and Low Pro for jQuery while employing tried-and-true solutions such as jQuery Templates and Live Query. What's more, the requirements for the widget itself left room for some careful consideration of user experience design.

In the end, I built a client-side demo in just a few days and handed it off to the project lead for integration with a complex back end. Now I'm free to refine my deadline-constrained code into something a little more OO and share the results.

This week, I'll talk about the project's complex usability requirements and Pathfinder's user-centered solution to those requirements. Next week, I'll walk you through our first pass at building custom code, roping in open-source libraries and making it all work together on a tight deadline. Finally, I'll walk you through the refactoring process so you can see the final, properly factored and reusable version.

Requirements

The requirements centered around a subscription management interface in which members could be subscribed to a product, but only if they belonged to an eligible subscription group. Each member could belong to multiple groups, but at least one of those groups had to be eligible for subscription before the member could be subscribed to the product.

The workflow for this particular screen was for the user to choose which customer groups were eligible for any given subscription, and which customers within those eligible groups should actually be subscribed. (Group memberships themselves were handled on a different page.) Upon hitting our page, the user should be able to do the following:

1. see eligible and ineligible groups at a glance
2. see unsubscribed and subscribed members at a glance
3. move groups from ineligible to eligible status
4. move eligible members from unsubscribed to subscribed status
5. see the results of any group eligibility change reflected immediately in the member subscription portion of the interface
6. see a visual indicator of any action's trickle-down effects
7. see all pending changes before submitting the form
8. see the number of members in any group - and a complete list of those members
9. see the number of groups to which each member belongs

Interface and interaction design

Multiselect vs. linked multiselect

The obvious design pattern here was a pair of multiselects, one for groups and one for members. Changes in the groups multiselect would propagate to the member multiselect. This sounded fine in theory, but we quickly learned that not all multiselects are created equal.

To differentiate between the selected and unselected items in a typical multiselect, you must employ a visual highlight. If you also want to call out changes that are pending in the current session, you must employ another visual highlight. Often, you end up with an eyesore: Either a visually chaotic collection of background colors (one each for initially selected, newly selected, initially unselected, and newly deselected) or an equally difficult-to-parse mixture of checkboxes and highlights (checkboxes for on/off, and a highlight to indicate pending changes).

Our solution to this problem was to use another time-honored design pattern: the linked multiselect. In this type of interface, each collection of selectable items is rendered as two physically distinct lists; the unselected items live in one list and the selected items in another. The user physically moves items between the two lists, either by clicking arrow icons or by dragging and dropping. (Due to time constraints, drag and drop isn't part of our current implementation.)

The advantages to this solution include the following:

• The user can see, at a glance, which items are selected and which aren't. Items in each state are physically separate rather than intermixed.
• With screen geography taking care of one type of differentiation (on or off), color can be used for the other type (added or removed). We chose green to indicate newly selected items and red to indicate deselected items.
• Thanks to the use of color and geography for the two visual differentiators, no checkboxes or other form fields need be employed. The entire component can be built as a widget and serialized into hidden form fields behind the scenes. Ordinarily, I would follow the principles of progressive enhancement and avoid this kind of JavaScript-dependent interface. But the specs for this project called for a JavaScript-capable modern browser, so I got away with it.

The design pattern for linked multiselects is pretty well understood, but our implementation needed to support an additional dependency between one linked multiselect (the groups interface) and another (the members interface). Moving items from selected to unselected within the groups interface would cause items within the member interface to appear or disappear. We therefore had to repopulate the member multiselects in response to events within the group multiselects. We decided to call out these trickle-down effects with a tried & true Web 2.0 color fade effect.

As a courtesy to users, we also decided to retain the previous subscription state of members whose group eligibility was removed. This would alleviate a lot of tedium for users who accidentally changed a group's eligibility and then had to change it back.

Our tertiary requirements added complexity to the project. Because members could belong to multiple groups, we had to display the number of groups next to each member's name. That way, if the user needed to make sure a given member would remain subscribed, he could check how many groups that user belonged to before marking any of those groups ineligible.

Because our linked multiselects divided the members of a group into two boxes, we had removed the ability to see a group's entire membership at a glance. We therefore had to provide an alternate way to achieve this requirement. Our solution was the use of a modal dialog, a link to which appeared next to each group name. These links added some visual complexity to the multiselect, but we mitigated the visual noise with font size and color.

See the code in action

You can see the results of our interaction design by playing with our demo code. As a case study, I loaded up a collection of characters from Marvel Comics's "X-Men" franchise. As any fans of the mutant superheroes knows, the X-writers are famous for introducing scads of new characters and trading them between teams like a professional sports league. Using the X-characters allowed me to correctly model the many-to-many relationship between groups and members as they existed in my requirements.

Next time, we'll take a look at the actual code. In the meantime, you can check out the code on your own by viewing source on the above demo.

Now that I'm the Ajax lead at a small, Agile software development firm, I'm no longer the only technical person in the room. But I'm still just as specialized. It's not that my JavaScript, CSS and JSP skills are any more important than somebody else's SQL, Java or Swing skills. It's just that I'm a team of one, so utilizing me effectively takes a little more planning. Everybody at Pathfinder wears multiple hats, but I was hired specifically to wear the same hat all the time.

Many projects at Pathfinder seek my input, but my attention can only be parceled up into so many chunks. I can't serve as an actual development resource on every project. Over time, I've realized that the following strategies help me deliver the value I need for my company:

1. Teach them how to fish

   This one's a gimme, but it takes discipline to stick with it. It's so easy to say "yes" when you're asked to do something you've done 100 times before and know how to do quickly. You'll make project managers and clients happy, but you're really shooting the organization in the foot. If you're a shared resource of one, you should do almost no solo development work. Every "yes" should be a "yes" to pair programming only.

2. Get involved in the process

   If web applications were cakes, Ajax wouldn't be the frosting, it would be the baking powder. You can't just layer it on at the end. In an Agile environment where few projects necessitate a dedicated front-end resource, it's easy to forget about UI concerns until late in the process. By then, prior decisions can make Ajax components far more difficult and time-consuming to implement. One-person UI teams should try to keep tabs on every project in the pipeline. Demand to be included in initial requirements-gathering sessions and check in during as many subsequent iteration kickoffs as possible. By making recommendations early and frequently, you'll save lots of time and money later.

3. Don't start coding without some sort of road map

   Iterative development is great, but it's harder on the front end. The user interface is the layer most likely to change dramatically based on client feedback. But UI code is also expensive to produce. Prototypes, wireframes and proper business analysis should all come before a single line of JavaScript gets written. Comps and interaction plans are easy to throw away. A thousand lines of Prototype classes and jQuery plugins, not so much.

4. Start simple, stupid

   Progressive enhancement can actually help with #3 above. On early iterations, build simple HTML controls rather than complex Ajax components. Make sure the application is well factored into individual screens and features before you enhance your first-pass markup into complicated widgets. If you're following the principles of progressive enhancement, your initial "dumb" markup will continue to serve users with screen readers, low-tech mobile browsers or draconian IT-department JavaScript restrictions. Nothing will get thrown away

5. Learn the entire stack

   User interface development has finally earned recognition as a discrete discipline of its own. Don't let that dissuade you from learning new technologies, especially ones far removed from the UI. Write a Rails app from scratch in your free time. Learn some hardcore PHP plumbing instead of just futzing with WordPress tags. Rewrite one of your custom JSP tags in pure Java instead of JSTL. Install MySQL and have a field day. In short, learn to be a more flexible, less specialized resource. The more places you can be plugged into a project team, the more likely your company will eventually hire additional front-end resources. Then you'll no longer be a shared resource of one.

How about you, front-end readers? How do you make sure you're getting used effectively in Agile environments? Let us know in the comments.

]]> http://www.pathf.com/blogs/2008/08/working-effectively-as-a-team-of-one-five-tips-for-front-end-developers-on-agile-teams/feed/ http://www.pathf.com/blogs/2008/08/more-on-crockfords-and-flanagans-approaches-to-javascript/ http://www.pathf.com/blogs/2008/08/more-on-crockfords-and-flanagans-approaches-to-javascript/#comments Tue, 05 Aug 2008 18:03:28 +0000 Brian Dillard http://www.pathf.com/blogs/?p=1082

In my recent review of "JavaScript: The Good Parts," I compared this new Douglas Crockford treatise with David Flanagan's canonical "JavaScript: The Definitive Guide." I subsequently stumbled upon a perfect example of the authors' divergent approaches to my native programming language.

Here's Flanagan discussing the dreaded with statement:

Despite its occasional convenience, use of the with statement is frowned upon. JavaScript code that uses with is difficult to optimize and may therefore run more slowly than the equivalent code written without the with statement. Furthermore, function definitions and variable initializations within the body of a with statement can have surprising and counterintuitive behavior.* For these reasons, it is recommended that you avoid the with statement.

* This behavior, and the reasons behind it, are too complicated to explain here.

And here's Crockford:

JavaScript has a with statement that was intended to provide a shorthand when accessing the properties of an object. Unfortunately, its results can sometimes be unpredictable, so it should be avoided.

The statement:

with (obj) {
    a = b;
}

does the same thing as:

if (obj.a === undefined) {
    a = obj.b === undefined ? b : obj.b;
} else {
    obj.a = obj.b === undefined ? b : obj.b;
}

So, it is the same as one of these statements:

a = b;
a = obj.b;
obj.a = b;
obj.a = obj.b;

It is not possible to tell from reading the program which of those statements you will get. It can vary from one running of the program to the next. It can even vary while the program is running. If you can't read a program and understand what it is going to do, it is impossible to have confidence that it will correctly do what you want.

Simply by being in the language, the with statement significantly slows down JavaScript processors because it frustrates the lexical binding of variable names. It was well intentioned, but the language would be better if it didn't have it.

The difference between these approaches to the same topic can't help but remind me of a favorite episode of "Buffy the Vampire Slayer":

Oz: [to Faith] I'm wondering about your position on werewolves.

Willow: [proudly] Oz is a werewolf.

Buffy: It's a long story.

Oz: I got bit.

Buffy: Apparently not that long.

--BtVS S03E03: "Faith, Hope & Trick"

There's value in exhaustively documenting a language. But without concrete examples of why something's bad, programmers - obstinate autodidacts that they are - probably won't heed your advice. The Crockford book doesn't always provide such persuasive logic, but it usually does, making it ideal for JavaScript noobs who need to understand how to use the language safely and effectively.

]]> http://www.pathf.com/blogs/2008/08/more-on-crockfords-and-flanagans-approaches-to-javascript/feed/ http://www.pathf.com/blogs/2008/08/ajax-overhaul-part-4-retrofit-existing-sites-with-jquery-and-ajax-forms-now-live-at-ibm-developerworks/ http://www.pathf.com/blogs/2008/08/ajax-overhaul-part-4-retrofit-existing-sites-with-jquery-and-ajax-forms-now-live-at-ibm-developerworks/#comments Mon, 04 Aug 2008 18:16:21 +0000 Brian Dillard http://www.pathf.com/blogs/?p=1081

Last week, IBM developerWorks published the fourth installment in my jQuery/UxD tutorial series. Ajax overhaul, Part 4: Retrofit existing sites with jQuery and Ajax forms shows how to turn a multi-page checkout process into a single-screen interface using two jQuery plugins: jQuery Form and jQuery UI Tabs. As with previous installments, I tried to show not only how to use open-source JavaScript libraries, but why. Ajax integrates into existing webapps best when it's used to improve their user experience design rather than just thrown in for its own sake. In the example application I constructed for this series, Ajax was used to simplify the shopping process rather than complicate it needlessly. As always, I focused on progressive enhancement so that the overhauled interface didn't leave any users behind. This is the final installment of this series, at least for now. I hope to publish on additional topics at developerWorks soon.

]]> http://www.pathf.com/blogs/2008/08/ajax-overhaul-part-4-retrofit-existing-sites-with-jquery-and-ajax-forms-now-live-at-ibm-developerworks/feed/ http://www.pathf.com/blogs/2008/07/book-review-javascript-the-good-parts-by-crockford/ http://www.pathf.com/blogs/2008/07/book-review-javascript-the-good-parts-by-crockford/#comments Tue, 29 Jul 2008 18:04:28 +0000 Brian Dillard http://www.pathf.com/blogs/?p=1058 I heart David Flanagan. I'm making my way through "The Ruby Programming Language" this summer. Its exhaustiveness really satisfies. But a decade ago, my programming Bible was Flanagan's "JavaScript: The Definitive Guide". As I transitioned from a career in content to a career in code, "the Rhino book" taught me everything I needed to know about object-oriented JavaScript, DOM scripting and the other building blocks of today's Ajax landscape. I've bought a hard copy of each of the book's five editions. It remained, until recently, the only JavaScript book I'd recommend.



That all changed with the recent publication of "JavaScript: The Good Parts" by Yahoo's Douglas Crockford. Crockford probably needs no introduction. His incisive website and frequent blog posts have championed JavaScript's power and potential while calling out its drawbacks and frequent misuse. Now, with "JavaScript: The Good Parts," he has managed to provide a reference as useful for JavaScript pros as it is for novices. Part language primer, part apologia and part critique, Crockford's book draws from and extends many of his long-gestating themes about how to use JavaScript - and how not to use it.

The author's premise is so simple and intuitive that it sounds like rubbish until you suddenly realize that this is how all programming languages should be taught:

When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. ...

Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone. And some of those features were design errors. Sometimes language designers make mistakes.

Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?

Crockford has no problem applying this thesis to JavaScript - an exercise he already nailed once in his seminal essay "JavaScript: The World's Most Misunderstood Programming Language." He describes JavaScript as "Lisp in C's clothing" - a powerful dynamic language that was rushed to market and stuck with a gimmicky name but achieved almost instant ubiquity thanks to the success of the web browser. Crockford doesn't condemn those features, such as non-classical inheritance, that set JavaScript apart from other popular languages. In fact, he bemoans the concessions JavaScript made to the Java crowd - puzzling syntactic choices that obscure the language's true nature.

Once he's established his guiding principles, Crockford spends several chapters cataloging JavaScript's "good parts." And that's pretty much the entire book, save for some excellent appendices. (More on those later.)

So what are those good parts? Crockford seeks to showcase the power and expressiveness of JavaScript's prototypal inheritance, first-class functions, closures, dynamic objects, and object/array literal syntax. To get there, he first describes the language's low-level features: types and operators, statements and syntax. Here, as always, he weighs every sentence carefully, making sure it can introduce new concepts to the uninitiated while also bolstering the understanding of folks who've previously encountered said concepts.

Throughout, he employs the plain, concise and often wry style for which he's known. If you read this book aloud, it would sound like the lectures of a particularly smart, snarky college professor. Even throwaway code samples sparkle with personality; "Lost" junkies, for instance, will enjoy playing "spot the Oceanic 815 reference."

Where necessary, Crockford offers simple solutions, in code, to overcome some of the trickier aspects of the language's inheritance and reuse patterns. His persuasive explanation of how to untangle prototypal inheritance - rather than building classical inheritance structures atop it - mark him as a programmer who's thought deeply about his craft. So much software development boils down to repeating the same steps one has carried out countless times before. Crockford leads by example, showing how to rethink received wisdom and rewire one's own algorithms. Such introspection about the process of programming should inspire all but the most haphazard of developers.

I love how this book simply ignores so many small, low-value features of the language. Crockford basically ignores the existence of Function.call in favor Function.apply. He never explains why, but it's obvious: When seeking to bind a function to a new object context, most programmers have to stop and think to remember which of these methods binds arguments as an array rather than as a list of parameters. Why learn both when simple convention can allow one to suffice?

I've been writing JavaScript for a decade, and I'm still impressed with the meat-and-potato chapters of this book. In just 170 pages, Crockford shows developers how to use JavaScript the right way. Is the aforementioned Rhino book still a valuable and exhaustive resource? Yes. But for someone looking to dive into JavaScript for the first time, "JavaScript: The Good Parts" offers advice and perspective to go along with language documentation. Reading it, I felt like I was encountering the language for the first time - and understanding it better than ever.

That said, Crockford's appendices may provide the most value to longtime JavaScript coders. There, he documents both the "awful parts" and the simply "bad parts" of the language in some detail. These sections work best when Crockford provides concrete evidence to support his assessments, as when he explains the danger blockless statements pose:

An if or while or do or for statement can take a block or a single statement. The single statement form is another attractive nuisance. It offers the advantage of saving two characters, a dubious advantage. It obscures the program's structure so that subsequent manipulators of the code can easily insert bugs. For example:

if (ok)
    t = true;

can become:

if (ok)
    t = true;
    advance(  );

which looks like:

if (ok) {
    t = true;
    advance(  );
}

but which actually means:

if (ok) {
    t = true;
}
advance(  );

Programs that appear to do one thing but actually do another are much harder to get right. A disciplined and consistent use of blocks makes it easier to get it right.

He's far less persuasive when he decides to forego examples. Proclamations such as the following come off like cant:

The continue statement jumps to the top of the loop. I have never seen a piece of code that was not improved by refactoring it to remove the continue statement.

Despite this occasional lack of substantiation, Crockford has succeeded in writing the definitive book on a language for which a definitive book has long been available. That's no small achievement. If you care about the quality of your JavaScript code, zip over to Amazon or your Safari Bookshelf ASAP.

]]> http://www.pathf.com/blogs/2008/07/book-review-javascript-the-good-parts-by-crockford/feed/ http://www.pathf.com/blogs/2008/07/google-calendar-finally-a-search-box-that-makes-sense/ http://www.pathf.com/blogs/2008/07/google-calendar-finally-a-search-box-that-makes-sense/#comments Mon, 28 Jul 2008 21:31:11 +0000 Brian Dillard http://www.pathf.com/blogs/?p=1057 I've been complaining for months about a usability problem with Google Calendar's default search behavior, so I figure I should document that it's finally been fixed. Ever since gCal introduced the concept of public calendars, hitting "enter" in the global search box has kicked off a trawl through the public-calendar database. Instead of searching MY OWN calendar for, say, my Aunt Donna's birthday, gCal instead searches public calendars of, like, sports schedules and Kazakhstanian bank holidays. Smart.

Now, though, that behavior seems to have been flipped. "Search My Calendars" is now the default action, while "Search Public Calendars" has become the secondary action. Bravo!

]]> http://www.pathf.com/blogs/2008/07/google-calendar-finally-a-search-box-that-makes-sense/feed/ http://www.pathf.com/blogs/2008/07/five-jquery-plugins-that-are-a-joy-to-use/ http://www.pathf.com/blogs/2008/07/five-jquery-plugins-that-are-a-joy-to-use/#comments Tue, 22 Jul 2008 20:15:58 +0000 Brian Dillard http://www.pathf.com/blogs/?p=1050

Yesterday I discussed how to separate the jQuery plugin wheat from the chaff. Today, I offer a completely subjective and biased list of jQuery plugins to know and love.

1. Form

   This powerful library collects several useful utilities for manipulating forms - with or without Ajax. It adds eight separate methods to the jQuery namespace, but in some ways I prefer that to one overloaded method with complex invocation logic. The ajaxForm and ajaxSubmit methods offer, respectively, complex or simple asynchronous form manipulation. Both implicitly support progressive enhancement. Additional methods allow you to serialize forms or individual form fields, clear or reset forms and retrieve form values. These methods offer a more convenient interface and a higher level of abstraction than built-in jQuery methods.

2. Cycle

   It sometimes seems like half the jQuery plugins out there offer some mix-and-match combination of tabs, lightboxes and image slideshows. The cycle plugin does, too, but it's lightweight and well-factored. The core library is only 6k compressed. If you want fancy transitions, you can get those for another 6k. Easing and meta-data can be layered on, too. The API, too, is modular. The options bundle for the library's single, overloaded cycle method is a bit of a mishmash, but it lets you create endless slideshows, start-and-stop ones and everything in-between.

3. Live Query

   Live Query does one thing, and it does it well: It automatically binds and unbinds event handlers whether the associated content was in the native page, added via DHTML or loaded via Ajax. By offering a simple, intuitive wrapper to jQuery's own bind and unbind methods, Live Query rewires a core part of jQuery without jumbling the API or losing the feel of jQuery's syntax.

4. Templates

   A fork of Ext.js templates, this powerful plugin lets you build client-side templates that are as easy to work with as server-side ones. The default syntax leverages JSP-style variables, but you can rewire it with RegExes of your own. Either way, Templates lets you build on-the-fly DOM structures without concatenating strings by hand or building silly helper methods for tag construction. Build a template, throw a hash of data at it, and boom - instant DHTML.

5. TableSorter

   True Ajax data grids require careful handshaking between client- and server-side code. That makes pure JavaScript approaches to the problem a challenge. Oftentimes, though, you just want to add some progressively enhanced magic to client-side tables. Enter TableSorter, which adds simple or complex sorting to your tables without a lot of fuss. Several plugins offer solutions to this problem, but I haven't yet found one that does it as cleanly or elegantly as TableSorter.

]]> http://www.pathf.com/blogs/2008/07/five-jquery-plugins-that-are-a-joy-to-use/feed/