Ben Scofield

Make everything as simple as possible, but no simpler.

That’s one of my favorite Einstein quotes. Unfortunately, it seems to be ignored more often than not in the world of web development – to the detriment of a great many applications.

There’s one realm in particular where I think we as developers (and designers) typically fail to apply this principle, and that is in the registration process. In my experience, application developers start from the assumption that they’ll have the typical user account, created by a registration process that (at a minimum) asks for an email address and a password. The problem with this is that many applications don’t actually need user accounts, much less one that requires a password.

In the Cucumber world, there’s a practice referred to as “popping the why stack.” This involves asking “why is this needed?” for any feature of the application – and repeating that question until you get to an answer that is directly tied to business value (maintaining or increasing revenue, or managing costs). If you can’t get to one of those values within five whys, your feature just isn’t that valuable, and should probably be put off for something that’s more closely tied to improving your business.

As it turns out, many applications fail the why stack test for authentication. That’s why a site like Instapaper could successfully launch with significant functionality not tied to a login (though they’ve since succumbed to the standard approach, alas). I’d love to see more applications question the necessity of registering before allowing access to the end user; at the very least, this approach gives users a better idea of what a site provides to them, and it’s likely that they’ll see greater conversions as a result (the attrition effect of each step in the registration process is well-studied).

Of course, some sites do legitimately need authenticated users – my argument isn’t that all sites should go account-free, but rather that we as developers (and user experience designers) should be mindful of the real requirements for each application we build. Let’s stop the cargo culting of user experience, just as we’ve tried to stop the cargo culting of development practices.

http://www.flickr.com/photos/betweenloveandlike/
CC BY-NC-ND 2.0

I’ve been to a lot of events over the past few years, and I’ve drawn a number of conclusions about various sorts of presentations. One of the most universal of these is that panels suck*.

If you’ve been lucky enough to avoid panels in the past, let me enlighten you: a panel consists of a group of people (generally 3-5) who sit up front and answer questions posed by a moderator. The panelists can be united by a number of traits – people who’ve worked in the same domain, dealt with similar situations, competed in the same competition**, etc. The idea behind the panel is that it allows the audience to hear multiple perspectives on that commonality; if your panelists all work in academia, for instance, they’ll be answering questions about the unique characteristics of that environment (“Are university politics different from private sector politics?”)

Embedded in that description is a set of problems that combine to make panels incredibly difficult to do well.

1. Multiple presenters are difficult to handle at the best of times – the flow of a presentation is very easy to disrupt if personal styles differ, and panels make that inevitable. The only way I’ve seen to manage multiple presenters is to have them practice together repeatedly, and that can’t happen with panels, which tend to be more conversational. People step on each others’ sentences, or withdraw entirely and look disinterested in their fellow panelists.
2. There’s no right way to address questions. The moderator could ask each panelist the same question (since the point is to get their different perspectives), but that becomes incredibly boring for the audience – and if you avoid that, then you’re missing the point of those different perspectives.
3. If the topic is broad, then you’re going to get an incomplete view from each panelist. In that case, it would be better if they each gave a full presentation of their own. I’ve never experienced the opposite scenario, where the topic is very narrow and each panelist says his or her piece on it entirely, but at that point the topic might be too narrow to be of any real interest.

So, how do we fix panels? Or do we even bother?

I think that, for the most part, we should strive to eliminate panels of the sort I’ve described from conferences. They’re usually massively unproductive, and contribute mightily to the hallway-trackers (people who say conferences suck and they only go for the hallway conversations). There may be one exception, however: a panel might work if the panelists are all telling the same story. An instance of this would be the founders of a company telling how they got started and grew – or a project team describing their process. This sort of case-study panel would be much more natural, as we’ve all experienced group storytelling (even if it’s just a couple describing their vacation), and so the panelists wouldn’t interfere with each other as much. This could be a multi-subject interview (with a relatively active moderator), though that could run into some of the same problems that the normal panel exposes; it might be better just to eliminate the moderator entirely and let the panelists just tell their story.

Whether that’s a better approach or not, one thing’s for sure: I’m definitely going to avoid your typical panels at events I attend in the future. What about you?

* I’ve been on a panel, and yes – it kind of sucked, too.

** I suppose you could have a panel where there’s even less of a common thread among the panelists, but that’s the stuff of my nightmares.

Triangle-area friends! If you’re free this Thursday (September 24th), come on out to Bronto’s offices for Refresh the Triangle. I’m going to be giving a talk on The Future of Data – or, less impressively, the recent movements in the database landscape.

This’ll be an interesting presentation, since the Refresh audience is generally a mix between designers and developers. I imagine this particular meeting will be developer-heavy, but I’m working to make the talk as designer- and front-end-dev-friendly as possible. I’ll be focusing on two points: offline storage in HTML5 (applicable to everyone), and the emergence of non-relational databases (like document-oriented databases). Both topics should be fun, and there’s sure to be something to learn for everyone.

So, if you’re in the area, c’mon out and support your local Refresh! Or at least come out for the drinks afterwards…

Here’s a trick for creating modular templates in Rails 3: use the apply method

Say you like to use Rails templates, but you find them a little too inflexible – you want to use Cucumber, jQuery, and MongoDB, but not always together. You could create separate templates for each combination (and in fact, with Rails 2.3.x that’s what you have to do), but in Rails 3, things get a little easier. With 3, you can actually modularize your templates!

For instance, this gist removes the default Prototype JavaScript files from your app, and gives you a simple XHTML layout with Google’s hosted versions of jQuery all ready to go:

jQuery application template

This gist, on the other hand, requires the Cucumber and webrat gems and runs the Cucumber generator to set up the features directory, etc:

Cucumber application template

In current Rails, you’d either have to run these individually or put the code into a single file to get them to apply to a project; in Rails 3, however, you can create a separate template that applies both of them:

Aggregate template

In Rails 3, the directive to apply a template has been refactored into the apply command, which you can access inside a template, because they’re instance_eval‘d by the application generator. This opens up a whole new world of possibilities for remixing components, and should make starting new Rails applications even easier. One more reason to anticipate the arrival of 3!

So I’ve been using Cucumber somewhat heavily for a while now, on both personal and client projects, and I’m starting to settle into a comfortable rhythm with it. At first, though, I found integrating features into my workflow extremely disconcerting. It went something like this:

• I’d write a feature, run it, and watch it flag half the steps as ‘pending’.
• Then, I’d drop down into the step definitions and fill them out with the appropriate lower-level code (e.g., “Given a user named Sarah” became User.create(:name => 'Sarah')).
• When the steps seemed correct, I’d rerun the feature and see it fail on (usually) the first step.
• I’d then drop into the appropriate lower level – controllers or models, but usually the latter at this stage – and work through things in my normal, mostly TDDish way.
• Once I got the appropriate lower-level code tested and working for that step, I’d rerun the feature and repeat the cycle for each step that failed.

This process worked, but I wouldn’t say it worked well. I ended up bouncing almost constantly between running the feature (to see which step was failing) and the functional and unit tests, and all in all never quite felt confident that things were working at any given point.

After talking to a number of people about their workflows with Cucumber, however, I started working slightly differently. Now, things go more like this:

• I write a feature, run it, and watch it flag half the steps as ‘pending’.
• I then leave Cucumber and drop into the lower-level code, referring to the original feature only if I forget the overall vision of what I’m working on. At this point, my work feels pretty much the same as it did before I started using Cucumber.
• Once I’m satisfied with the tests and code at the lower level, I return to Cucumber, fill out the step definitions, and run the feature – at which point I’m either done (because the steps all pass), or realize I’ve forgotten something and drop down to the lower level again to fix it.

The key change here is that I stay out of Cucumber as much as possible; I only run features at the beginning (to see all the pendings) and at the end (to see the passes), and I really only touch the step definitions once. In effect, I’ve moved away from Cucumber as part of my test-driven development cycle, and instead use it as an overarching vision for the high-level functionality I’m working on… and yes, I know this sounds very close to the language of BDD, but it seems much closer to being story-driven than behavior-driven to me (behavior sounds more like the lower level, where I’m still clearly TDDing, thank you very much).

So that’s how I’m working with Cucumber now. What about you? Do you bounce back and forth frequently, and happily? Have you eliminated controller/functional testing in favor of Cucumber, thus reducing the levels to navigate? Done something completely different? Inquiring minds want to know!