Author: Brian Dillard

Chicago JavaScript Meetup Group draws a big audience with varied skill levels

Brian Dillard, Monday, January 26, 2009 @ 12:17 pm

The Chicago JavaScript Meetup Group spurred more than 50 of its members to brave harsh weather Thursday night for the group's fourth free get-together since its founding last October.

Organizer Vlad Didenko led the charge with an in-depth look at Firebug, while assistant organizer Justin Meyer contributed a discussion of Ajax fundamentals.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

jQuery 1.3: Good stuff, but the API browser’s the real news

Brian Dillard, Friday, January 16, 2009 @ 12:51 pm

I'm as geeked about jQuery's 1.3 release as the next developer. But I'm even more excited about the new API browser developed by Remy Sharp and available here.

For as long as I've been a jQuery user - going on 18 months now - I've been frustrated by the slow speed and sometimes intermittent availability of the jQuery documentation site. Now we've got a blazing-fast API browser that presents jQuery Core and jQuery UI side by side in the same cool interface. Better yet, it's available as an Adobe AIR app for offline viewing. Sweet!

I could quibble about the lack of bookmarkable URLs and the occasionally sparse documentation of corner cases. Instead, I'll just remain upbeat about this huge step in the right direction. No matter how intuitive jQuery's API, it's a powerful library whose roster of methods continues to grow. Nothing speeds up development faster than quick, persistent access to quality API documentation.

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

jQuery 1.3: Plugins continue to migrate to the core

Brian Dillard, Friday, January 16, 2009 @ 12:51 pm

jQuery celebrated its third birthday Wednesday with the release of the brand-new 1.3 version. This latest release includes a bunch of cool new stuff which has already been discussed to death elsewhere. To me, however, the most interesting aspect of jQuery 1.3 is the movement of former plugin functionality to the core library.

Live events are a new twist on the venerable, and indispensable, Live Query plugin, while the upgraded, more granular effects queues were previously tackled by add-on authors. IMHO, this kind of migration is A Good Thing, providing greater parity with other core JavaScript and effects libraries (such as Scriptaculous's FX queue) while offering compelling feature differentiation (event binding throughout the full lifecycle of an Ajax page).

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

Ask the readers: How do you keep DRY when exposing your Rails apps to iGoogle?

Brian Dillard, Monday, January 12, 2009 @ 1:47 pm

My most recent Pathfinder project calls for a pretty typical Ruby on Rails web application with two interesting additional components: a Facebook application and an iGoogle gadget. Though a Rails Facebook plugin was easy to find, Rails development tools for iGoogle weren't as thick on the ground.

First, a bit of background: iGoogle, Google's personalized-homepage service, offers developers two methods of application development:

• build a native gadget by wrapping custom HTML, CSS and JavaScript in an XML wrapper.
• build a sandboxed gadget by wrapping an externally hosted web application in an iframe.

Because of cross-domain security issues, gadgets that require authentication must be built using the iframe sandbox method. As it turns out, this method's a lot easier. Instead of building a whole new interface, you can just tart up your existing app with an iGoogle-optimized user interface. Why replicate your existing view logic with a bunch of iGoogle-specific JavaScript when you can just reskin and call it a day?

As it turns out, though, reskinning a Rails app for iGoogle isn't as simple as it might seem at first glance. I can think of three options. All have drawbacks:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

How to serve static websites and Passenger Rails projects from the same Mac OS X Apache instance

Brian Dillard, Monday, January 5, 2009 @ 2:22 pm

When your http://localhost/~username/ sites go haywire, it's time to dig into your Apache config files

As Rails pros know, Phusion Passenger allows you to serve multiple Rails apps on the same Apache webserver instance with few configuration or deployment headaches. When you install it in your local Mac dev environment, you can easily work on a bunch of Rails projects simultaneously without having to manually start and stop individual server instances all the time. The OS X Passenger preference pane makes deployment even easier. Just add a project, give it a custom local URL, and point it at a directory. You're good to go.

But what happens if you're already using OS X's built-in Apache webserver to dish up local content such as PHP applications or static HTML? When I first got Passenger up and running, all of my local sites in /Users/<username>/Sites/ stopped working. It took a bunch of digging, but I eventually realized that something in my Apache configuration had gotten messed up during the Passenger installation process. I was missing the configuration file for my OS X user account. OS X generates this file the first time you enable web sharing for any individual user. It's responsible for mapping your /Sites subdirectory to localhost URLs, so that http://localhost/~<username>/myapplication/ points to /Sites/myapplication/index.html.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Category and UI changes on Pathfinder blogs

Brian Dillard, Monday, December 29, 2008 @ 10:50 am

If you read one or more of the Pathfinder blogs in our web interface, you may have noticed some tweaks to our navigation and top-level categories. Our goal in making these changes was to help different audiences drill down to the specific content that interests them. Instead of just a few top-level categories, we now boast around 20, though many posts appear in multiple categories. To subscribe via RSS to any specific category - or to our entire feed - just visit our Feeds page.

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Receive 10% off Web Form Design: Filling in the Blanks by Luke Wroblewski

Brian Dillard, Monday, December 29, 2008 @ 10:41 am

Rosenfeld Media contacted me after I published my review of Luke Wroblewski's "Web Form Design: Filling in the Blanks." They offered Agile Ajax readers 10% off "Web Form Design" or any other purchase at rosenfeldmedia.com. To redeem, simply enter the code PATHFINDER at checkout.

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Book recommendation: Web Form Design: Filling in the Blanks by Wroblewski

Brian Dillard, Monday, December 22, 2008 @ 4:15 pm

Usability and design guru Luke Wroblewski knows that web forms suck. More importantly, he knows why - and how to make them suck less.

For the past few years, the Yahoo! product design exec has been presenting his ongoing research into the humble HTML form at conferences and on his blog, Functioning Form. I attended Wroblewski's presentation at An Event Apart Chicago 2007 and came away super-impressed. His persuasive mixture of case studies, existing research and newly commissioned usability studies helped shed light on the patterns and anti-patterns that determine whether users successfully complete your forms or give up in disgust.

All of Wroblewski's preparation came to fruition earlier this year when he published "Web Form Design: Filling in the Blanks" (Rosenfeld Media). After finally taking the time to read the book cover to cover, I'm mad at myself for waiting so long.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

Software Development

Ask a UI Guy: How should I structure my stylesheets?

Brian Dillard, Monday, December 15, 2008 @ 4:52 pm

Welcome to "Ask a UI Guy," an occasional new feature in which we tackle JavaScript, markup and CSS questions for an audience of server-side developers. Today's topic: strategies for organizing your style rules into reusable components.

CSS doesn't impose much structure on its practitioners. Individual developers must build their own structure if they wish to escape the trap of poorly organized, inefficient code.

If a project kicks off without a clear shape to its stylesheets, subsequent developers are likely to plop additional styles down wherever is convenient. It's hard to build reusable components if every style is a one-off tied to an element id. Stylesheets with a strong skeleton and frequent signposts encourage conscientious code that's easier to maintain.

And let's face it: CSS tools hasn't come as far as JavaScript ones. Sure, Firebug can help you track down why element X looks the way it does. But without a clear picture of a project's overall CSS architecture, it's hard to alter that element's style properties with confidence.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (8)

Software Development

Ask a UI Guy: What’s so bad about inline styles?

Brian Dillard, Monday, December 8, 2008 @ 2:41 pm

Welcome to "Ask a UI Guy," an occasional new feature in which we tackle JavaScript, markup and CSS questions for an audience of server-side developers. Today's topic: the deceptive allure and subtle peril of inline styles.

When you're first cobbling together a new feature or content page, inline styles can seem like a great idea. You're already editing an ERB, JSP, PHP or ASP template, so why not just write your CSS code in the same file? Throw a few style attributes into your HTML tags, populate them, and voila: instant look-and-feel.

What seems good in theory, however, quickly falls apart in practice. Many seasoned CSS developers employ external stylesheets for even the most roughshod of skunkworks. They do so with a fervor approaching that of TDD adherents carefully writing tests before even thinking about tackling actual code. People have been arguing against the use of inline styles in production code for close to a decade now, but I argue against their use at any stage of a project. Here are some of the reasons why:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

Pimp my jQuery: Five plugins to replace the features Prototype and Scriptaculous users expect

Brian Dillard, Monday, December 1, 2008 @ 4:53 pm

Ajax pros, especially in the Rails world, often know the Prototype and Scriptaculous JavaScript libraries inside and out. When faced with the prospect of writing on top of the competing jQuery framework, they may quickly stumble upon seemingly missing features.

The culprit? jQuery's less-is-more approach, in which advanced or specialized features come via plugins instead of the core library. The greater reliance on single-purpose plugins gives jQuery a lean footprint and a vibrant ecosystem, but they come at a cost. You often must rope in several plugins to accomplish things Prototype and Scriptaculous can do out of the box.

If you want to encourage your team to step out of the Prototaculous mindset, it helps to have a readymade list of plugins that approximate those libraries' core features. At this point jQuery and Prototype approach feature parity, but once Scriptaculous is in the mix, jQuery relies on multiple plugins to keep up with the Joneses. Here's a quick stab at how to trick out jQuery:

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (7)

Software Development

Ask the readers: How do I fire native browser events in Prototype.js?

Brian Dillard, Monday, November 24, 2008 @ 5:39 pm

I've been pairing with my colleague Noel Rappin on a cool Rails project lately, which has helped me turn a bunch of conceptual knowledge into real-world experience. I'm writing Ruby code, doing things the Rails way, and hewing faithfully to test-driven development.

I'm also returning to Prototype for my JavaScript needs after almost 15 months of daily jQuery use. The framework has matured nicely while I've been away. One surprise popped up today, however: Prototype 1.6 lacks the ability to simulate native browser events. jQuery offers this in the form of jQuery.trigger, which can simulate both native and custom events. But Prototype's Element#fire supports only namespaced custom events. (Read this mailing-list thread for more analysis.)

I did a couple hours of digging around today - including a trip to Scripteka - and haven't really found a canned, cross-browser solution to this issue. I'm looking for something that offers jQuery's native event firing in a tidy little Prototype extension. Anyone know of such a tool?

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Icons are evil; so are menus – unless you do them right

Brian Dillard, Tuesday, November 18, 2008 @ 5:37 pm

Menus and dropdowns seem like attractive design choices because they conserve screen real estate while providing users access to a potentially large number of commands. But if you resist the easy out of menus and dropdowns, you may find that your applications become far more usable.

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.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

Software Development

From JSP to Ruby on Rails: First thoughts on front-end coding conventions

Brian Dillard, Monday, November 10, 2008 @ 4:00 pm

Now that I've got a few Ruby on Rails projects under my belt, I finally feel qualified to comment on Rails front-end coding conventions. As a UI specialist coming to Rails from the JSP world, I find a lot of room for improvement in the RoR approach to view-layer code. I love working on the non-view aspects of RoR projects, but I find I've got to do tons of cleanup at the ERB layer. Expect to see some open-source components from Pathfinder to help ease this pain. In the meantime, let me articulate my pain points:

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.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

Software Development

The courage to redesign

Brian Dillard, Monday, November 3, 2008 @ 5:12 pm

People are still griping about the recent redesigns of Facebook and iGoogle, but I think we should cheer on any company brave enough to disregard user feedback and embrace change.

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.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development