Robby on Rails: Tag design

Tip: Link to Unimplemented

Robby Russell — Thu, 27 Mar 2008 06:10:00 -0500

Throughout our design and development process, we’re working around areas of the site that are not yet implemented but we also want to be able to allow our clients to demo their application. In an effort to manage their expectations, we need to be careful about what we link to. If a page/widget isn’t ready to be demo’d yet, we should avoid providing pathways to get interact with or navigate there. However, when we’re implementing HTML/CSS for pages, it’s sometimes makes sense to not hide certain things on the screen.

For example, let’s suppose that you’re working on the primary navigation of an application. You know what the other sections are going to be, but you’ve only implemented a few of them so far. Your HTML/CSS person is working on the design for the navigation and wants to have them be proper links… even to pages that don’t yet exist.

One option, which is quite common, is to provide a link with href="#". This works to some extent, but when people click on things, they naturally expect something to happen in response.

This approach doesn’t mesh well with our team as we don’t really want to field any questions like, “the navigation links are all broken. Nothing happens!”

So, a pattern that we’ve been using for a while is to trigger a javascript alert for every link within an implemented area that is linking to something that isn’t yet implemented.

Let’s take a really basic javascript function like:


# public/javascripts/application.js
function unimplemented() {
  alert("NOTICE\n\nThis feature is not implemented yet. Please check back again soon!");
}

This allows us to do the following:


  <a href="javascript:unimplemented();">link text</a>

When someone clicks the link, they’ll see a typical javascript alert message. This informs our clients/beta testers that we’re paying attention to what works and what doesn’t.

Uploaded with plasq’s Skitch!

Let’s take it a step further and push this into a view helper.


# app/helpers/application_helper.rb
def link_to_unimplemented( link_text, *args )
  link_to_function( link_text, 'unimplemented()', *args)
end

Now, we’re able to use link_to_unimplemented and pass any arguments that you’d pass to the default link_to view helper.


<%= link_to_unimplemented( 'link text', { :class => 'link_class_name' } ) -%>

Now our web designers can go about their work and use this helper as necessary.

An nice benefit for doing this is that we have a pattern that we follow so that we can rely upon to make sure that we don’t forget anything. This is the equivalent of adding @TODO@s throughout our code base.

If we search through app/views for ‘link_to_unimplemented’ we should be able to prevent missing any broken links. In the next screenshot, I’m using grep with colorized matches.

Uploaded with plasq’s Skitch!

As you can see, we have something left to implement in that area of the application. :-)

This has been one of those lightweight patterns that we’ve been able to adopt and it’s definitely helped manage the expectations of our clients throughout our development process.

I’d love to hear your thoughts on this. How does your team handle things like this?

Review: FogBugz, part 1

Robby Russell — Tue, 01 Jan 2008 15:43:00 -0600

Today, I thought that I’d give FogBugz a quick trial. A few of our Rails consulting clients use it and I’m hearing that others are as well.

Along the way, I’m bringing one of my favorite tools so that I can share some things thoughts (visually) along the way.

Signing up for a free trial

My first impression of FogBugz was, “nice homepage design… but what is that screenshot of?”

Uploaded with Skitch!

I’m not a designer, but the interface in the screenshot isn’t jumping out to me as something that you’d expect to see in a modern web application. While I appreciate the default browser colors for links (this is really important)... I think they could have found a better way to distinguish which bug links you’ve previously viewed. It’s very likely that you’ll most bugs many times, so having the color be different might not make sense in the same way it would when reading content on a web site. Again, I’m not a designer and I’d be curious to hear from a designer on this. Just something that I initially thought.

Uploaded with Skitch!

Okay, this sign up form seems really easy to start with. I’m used to free trials being really simple to get going. So, I enter in my sub-domain selection and provide my email address on the following page so that they can confirm that I’m legit.

(several minutes later…)

Okay, this process required me to jump from my browser to my email to my browser back to my email and then back again to my browser. It’s really frustrating for an application to force me to go back and forth between my browser and email client. I think the initial email is something I can cope with, but I found it a bit silly to have to wait for another email to receive a link to login to my new account, especially considering I already knew the URL as that was the first thing that I provided. The application could have provided the link (or redirected me) to the following form, which I had a few things to comment on.

Uploaded with Skitch!

At first glance, this might not seem like much… but I’m becoming more and more disappointed by the choice of language that we’re using in applications. First of all, this is the first time that I’ve seen this page. I’m not changing my password… what you’re really asking me to do is, “Create (or set) a password.” There are other verbs that you could use here, but change really isn’t appropriate. Also, choose doesn’t work here either.


  chose; choos·ing.
  –verb (used with object)
  1.    to select from a number of possibilities; pick by preference:

What am I choosing from? Again, you’re asking me to create a new password.. not change one and definitely not choose one, unless you’re implying that I should choose one from a collection of ones that I already use.

One might argue that we can make an assumption about what they mean, but it’s simple problems like this that can seriously confuse people that use the software we design and develop. As people interact with minor problems like this, their perception of the software as being helpful and friendly… can quickly deteriorate.

Okay, so that was my first several minutes of getting into my new FogBugz account.

Coming soon… Robby will share his thoughts on managing bugs with FogBugz.

That Checkbox Needs a Label

Robby Russell — Sun, 02 Dec 2007 00:43:00 -0600

As a user of many web applications, I often find myself noticing little things that slow me down. One such thing is the use of checkboxes in web forms. It’s not the problem of checkboxes itself, it’s the face that checkboxes require the user to really focus their attention to a fairly small box on the page and perform a click inside. If you’re filling out a form really quickly, it’s almost guaranteed that you’ll take advantage of you your tab key to get through each field quickly. Sometimes there are select boxes, which require the user to make selections with their mouse. Checkboxes drive me crazy because it requires more time to position the cursor and move on.

So, when I see a form like this, I don’t see it being very quick to interact with.

While I’m not in love with the date selection interface here, my bigger pain has been the checkbox in the form. Why? Because they forgot to use the <label for=""> HTML tag.

What’s the problem? Well, I don’t have the convenience of clicking on the label text, which would toggle the corresponding checkbox.

I know, many of you know all about this… but I run into this problem everywhere. This is an accessibility issue for people and really just increases the chances for a frustrating user experience. When you use the label tag properly… it will provide a larger amount of the screen for people to click, which reduces the chance of not clicking in the right spot. The label tag was designed with this in mind so that people could click close enough to trigger the desired action.

Here is an example of where it becomes really useful.

So, the lesson? Please remember to use the label for tag. :-)


<input type="checkbox" id="remember_me" name="remember_me" value="true" />
<label for="remember_me">Remember info?</label>

This is an easy thing to forget when building web applications. We’ve forgot and I’m sure you have too. I just wanted to point it out though because I see this happen so much… even in new sites.

Perhaps you run into similar problems with web applications that can be fixed with just a little more HTML. Care to share your experiences?

For more information, read Labeling form elements from the Dive Into Accessibility site.

Saying Goodbye Was Never This Hard

Robby Russell — Sun, 02 Dec 2007 00:07:00 -0600

There was a post the other day on Signal vs Noise about the pain of opting out of mailing lists titled, Redonkulous unsubscribe delays, which I was reminded of after the following experience.

Earlier today, I got an email notification from my old Friendster account, which ended up being spam. I hadn’t logged into the account in ages and looked around at my profile and others. No meaningful interaction between my friends in a few years. It’s felt like a ghost town. So, I thought… “should I just delete my account?” I was thinking about doing the same thing with my Facebook account as well, because I’m getting tired of being invited to applications a few times a day due to a friend leaving my name checked when they sign up for a game. (this is getting old…)

So, I decided to kill the Friendster account, which I’ve had since February 2003. Oh… the good ole days of social-networking sites.

Upon filling out a form I got the following error with the notification, “Please list the other social networking site you switched to.”

Uploaded with Skitch!

The tone of this error message is very rude and helped support my decision to leave the site.

While I appreciate that they’re looking for feedback, they shouldn’t demand it out of me. As a result, my response was…

Uploaded with Skitch!

Wait a minute. You’re demanding that I list the sites that I’m switching to… in 20 characters or less? Thanks for giving me the opportunity to LOLBUG you. Sigh. Who makes these interaction decisions there?

If they really wanted to get some useful feedback, perhaps they could have asked me nicer.

So, I decided to head over to Facebook and compare their process.

At first glance, this looks very much like the form that I was presented with on Friendster. Except that I can only select one reason why I am leaving and I can think of a few. However, when I made a selection… something surprised me.

Okay, so maybe I’ll leave my Facebook account around for the time being. Perhaps there is a Facebook application out there that will be get my attention.. but to date, this has yet to happen.

This post is dedicated to the memory of Robby Russell’s Friendster Profile. Feb. 2003 – Dec. 2007. R.I.P.

Skitch... my favorite desktop application of 2007?

Robby Russell — Tue, 20 Nov 2007 13:04:00 -0600

It just occurred to me that my first Skitch was on July 7th, 2007. 7/7/7. I’ve been meaning to post an article about how Skitch has changed the way our team approaches reporting bugs and communicating ideas visually.

First of all, the Skitch web site advertises it (see video) as a fun tool for playing with photos and sharing stuff with friends/family. While this is true, I think their bigger market could be those of us who work in the web design and development community. It took a less than a week for Skitch to become a tool that I rely on the most during my day to day work and since it keeps surprising me that people aren’t using it and/or haven’t heard about it… I thought that I’d share how we’re using it at Planet Argon.

Introducing “LOLBUGZ”

Our team is currently using Lighthouse for managing bugs/tickets for internal and client projects. If there is one way to slow down bug fixing cycle.. .it’s the ticket submission process. It takes a lot of time and commitment to try and communicate some problems that you’ll find in a web application. This is why screenshots can be so useful to helping speed up the process. Skitch allows us to not only provide a screenshot really quickly, but it gives us the ability to focus our attention with shapes and text, which provides more context when viewing an image.

For example, here are a few real-world Skitches that I’ve used to report some problems.

What happened to this drop down?

This pagination needs some CSS-Love!

Oh no! Tags are getting grouped together…

Styling has gone crazy…

I mastered an unordered list! (hooray!!)

This list isn’t scaling anymore…

Side note: LOL BUGZ was a term coined by Rick Olson at Active Reload to describe the tickets that I post for Lighthouse. ;-)

Trying out 15 during the initial releases for the iPhone… bug report sent via twitter to Erik Kastner.

As you can see, using Skitch helps communicate some very specific things without needing to type a huge description. Of course, we do try our best to add more context with our tickets. For example, here is a real-world example of a ticket that I posted on Lighthouse. As you’ll see, there are a few skitches embedded in the tickets, which works much better than attaching screenshots to tickets.

One of the best features of Skitch is it’s work-flow. Within a few seconds, I can do the following tasks.

Take a screenshot of a specific region of my screen
Add some arrows and text
Click on Webpost, which will upload directly to myskitch.com
Click on Share to navigate to the new upload
Click on the embed textfield and it uses JS to copy the embed html into my paste buffer
Paste the html snippet directly into the ticket that I’m reporting
Submit my LOL BUG

Side note: it also allows you to upload to Flickr, a ftp account, etc.

Over the past four months, Skitch has become one of my favorite OS X tools. The interface is lightweight and the workflow is almost perfect (feature request: providing the embed code in my paste buffer without needing to go to myskitch would be A+++)

I’ve also used Jing, which works on Windows and OS X and does video. I’ve not found it to be as intuitive for working in this manner. In fact, the work-flow leaves a lot to be desired. However! It does do video and this has come in handy a few times for showing people some “live” interaction-type bugs that can’t be communicated as easily through text/images.

If you’re not using Skitch yet and are on OS X… I highly recommend that you try it out for a few weeks during a bug fixing sprint. We’ve gotten our clients and almost everybody on the team using it in this fashion. The productivity increases haven’t gone unnoticed.

That’s not to say that it’s not fun for point out things that aren’t related to your project bugs. ;-)

Happy Skitching!

UPDATE

Plasq liked the writeup and gave me 50 extra invites to pass out for Skitch. So, if you’re in need of one… ask me via email. Thanks Plasq team!

Zeldman on Web Design

Robby Russell — Tue, 20 Nov 2007 12:01:00 -0600

In a new article on A List Apart, Jeffrey Zeldman writes:

“Some who don’t understand web design nevertheless have the job of creating websites or supervising web designers and developers. Others who don’t understand web design are nevertheless professionally charged with evaluating it on behalf of the rest of us. Those who understand the least make the most noise. They are the ones leading charges, slamming doors, and throwing money—at all the wrong people and things.”

He goes on to describe Web Design as, “as the creation of digital environments that facilitate and encourage human activity; reflect or adapt to individual voices and content; and change gracefully over time while always retaining their identity.”

Read the rest of the article, Understanding Web Design on alistapart.com.

RubyURL: new design and code base

Robby Russell — Wed, 08 Aug 2007 08:58:00 -0500

Yesterday evening, I deployed the new version of RubyURL. This was a collaborative effort between Chris Griffin and I, which we’re happy to finally push live.

There are a few things that we’re going to push out in near future, such as an API and a new RubyGem.

Chris volunteered to work on the new design and I did most of the programming in Ruby on Rails. When we worked on this, we really wanted to keep the process as simple as possible, despite some of the problems that the site has been having.

In the end, we have a Rails application that is only 85 lines of code and has a 1:2.3 code-to-spec ratio. I wanted to keep it under 100 lines of code. This means that there is some breathing room for further development.

We also tried out a beta account that I was given for RoundHaus for Subversion hosting. We had a really good experience using their service and were impressed by the plethora of useful features that came with the repository, such as continuous integration, rcov/code coverage stats, and twitter integration!.

If you find a bug, be sure to submit a ticket on the RubyURL bug tracker.

On a side note, we deployed this on a brand new Rails Boxcar, our new hosting solution that will be launched in the very near future. ;-)

Designers, Developers, and the x_ Factor

Robby Russell — Wed, 01 Aug 2007 00:39:00 -0500

Our team is lucky enough to be in a position where we have both designers AND developers working on the same code base in parallel.

Since Ruby on Rails adopts the Model-View-Control pattern for separating business logic from the presentation layer, we’re able to give our designers a lot of breathing room to to design the interface, whether it’s for interaction or aesthetic reasons. However, sometimes this breathing room has resulted in small bugs slipping into the application interface. In general, nothing disastrous, but each bug that slips into the queue, slows down the project and we want to avoid as much of that as possible.

I’d like to share a few issues that we’ve seen occur on various occasions, and then show you what we’ve done to avoid them happening again.

Scenario #1: The case of the changed div id, (victim: designer)

Designer adds a few HTML elements to the page, defines an id on a <div> tag and styles it with CSS.
A few days later, a developer needs to make some changes, tests it in their favorite browser and commits.
Later, the designer doesn’t understand why the styling is all messed up. “It was working fine.”
...minutes, hours… go by where the designer tries to track down the issue. “Oh! Someone renamed the id in this <div> tag. Sigh.”
Developer apologies, but explains that he needed to do it because he needed to make it work with his new RJS code.

Scenario #2: The case of the changed div id, (victim: developer)

Developer is implementing this cool new Ajax feature into the web application
- The code relies on there being one or many HTML elements in the DOM with specific id values defined.

Example: <div id="notification_message">

A few days later, a designer is making some changes to the layout and needs to restyle some of the view that this <div> tag is defined. Designer decides to change the id to a different value for any variety of reasons. (or perhaps they changed it to use a class instead of styling it by the id). Often times, we don’t know who set the id or class… and many times the developers aren’t savvy enough with HTML and designers end up cleaning things up a bit.
Later, code is checked in and designer didn’t notice that the Ajax was now breaking as they weren’t focusing on just the layout.
Day or two later, developer sees bug, “Feature X isn’t working, throwing JavaScript error…”
Developer is confused, “Hey, that was working! What happened?”
Developer tracks down the problem, discusses with designer, they figure out a solution. Problem solved.

I could outline a few other examples, but I really wanted to highlight these two types of situations, as our team has seen this happen on several occasions. Luckily, we’ve learned through these experiences and have taken some measures to try and avoid them in the future.

Moving forward (together)

Both of the examples above, were essentially the same problem, but resulted in problems for a different role in the design and development cycle. While, I’ve definitely been the victim of #2 several times myself, I know that I’ve also been the guilty of #1. So, what can we do as designers and developers to work with each other without causing these little problems from occurring? (remember: many little problems can add up to a lot of wasted time spent resolving them)

Several months ago, I had a meeting with Chris (User Interface Designer) and Graeme (Lead Architect/Developer) to discuss this very problem. At the time, we were implementing a lot of Ajax into an application and were occasionally running into Scenario #2. We discussed a few possible ways of communicating that, “yes, this div id should NOT be changed (without talking to a developer first)!”

Idea 1: Comment our “special” HTML elements

We discussed using ERb comments in our views to do something like the following.


  <% # no seriously, please don't change this id, it's needed for some Ajax stuff %>
  <div id="notification_message">
    ...

We all agreed that, while effective, it was going to clutter up our RHTML code more than any of us desired.

Team Response: Meh.

Idea 2: Reserve id’s for developers

Another idea that came up, was to ask that designers only use classes and ids wold be used by the developers when they needed it.


  <div id="developer_terriroty" class="designer_territory">
    ...

Chris pointed out that this wasn’t an ideal solution as there is a distinct case for when to use ids versus classes.. and he is very strict about adhering to the HTML/CSS standards.

Team Response: Not hot about it…

Idea 3: Naming convention for Ajax-dependent elements

The third idea that was discussed, was specifying a naming convention for any elements that were needed by our Ajax code. We played around on the whiteboard with some ideas and settled on the idea that we’d prefix our id’s with something easy to remember for both designers and developers.

We agreed on… x_ (x underscore), which would make an element id look something like this:


  <div id="x_notification_message">
    ...

x == ajax... get it?

While this adds the strain of typing two more characters to much of our RJS code, we don’t run into Scenario #2 very often anymore.


  render :update do |page|
    page[:x_notification_message] = 'Something exciting happened... and this is your notification!'
    page[:x_notification_message].visual_effect :highlight
  end

or in client-side JavaScript (where we also use this)...


  $('x_notification_message').do_something

I find that this helps our team keep a clear distinction between what can and shouldn’t be changed in the views by our designers. Sometimes they have a good reason to do so, but they know that if there is x_, then they should ask one of the developers on the team for assistance in renaming it without causing any problems in the application. It also allows our designers to add classes to these elements, or style the id that we’ve defined.

Team Response: Wow, was that all we needed to agree on? Hooray!

This leads me to some other problems that have/may come up, but I’ll discuss that in my next post on this topic, when I’ll show you how we can use RSpec to avoid these sorts of designer versus developer problems.

If you’re working in a similar environment, how are your designers and developers working, together, in perfect harmony?

Until next time, remember to hug your designer. ...and if you’re still having developer design your applications, consider hiring a designer. ;-)

UPDATE: changed examples after a few comments about using div_for as another solution. (see comments for details)

RubyURL 2.0 on the horizon

Robby Russell — Mon, 16 Jul 2007 22:23:00 -0500

RubyURL was a project that I built about 2 1/2 years ago as a late night attempt to see what I could build and deploy with Ruby on Rails in a night. It’s nearing 50,000 unique website links, has a Ruby gem that you can use with it, and rbot plugins.

I’ve rewritten it about three times in the past six months, to try out some new approaches, but haven’t deployed with a new version as I’ve been waiting for someone to help me with a new design. Chris has offered to help out and once we integrate his new design with it, we’ll be launching it.

Everything is not great in RubyURL land though. It appears that it’s become an easy target for comment spammers to abuse the site to generate rubyurls and paste those links in their spam comments. Several pissed off bloggers, forum administrators, and system administrators have emailed me to complain that I’m spamming their site. Sadly, even with a basic disclaimer on the site, they still like to blame me for their spam. It’s gotten common enough, that I’ve written a template email that I respond with that explains how the site works and that I’m not accountable for people posting links to my URL redirect tool.

You can see that it’s popping up around the net via a google search.

So, I’ve been trying to think of ways to make it easier for people to flag URLs as being abusive of the site. I’ve not come up with any elegant solution that doesn’t force the good users of the site to have more steps in their process to create a basic RubyURL.

The ideal (and current) workflow:

User navigates to http://rubyurl.com
User pastes in long url into text box/area
User submits form
User is provided with new (shortened) rubyurl
User copies the rubyurl and does what they want with it (generally… pastes into IM, IRC, Email, etc.)

Some people have suggested using a user system to do this, but I really don’t like that as a solution.

Another idea, which I built… and later removed from my new version, involved having the original url load in a frame, and then provide a way for users to flag it as ‘spam’, ‘nsfw’, or ‘dead’. Then, we could provide the user with a warning that the following URL was flagged before, are you sure you want to continue? I didn’t like this as a solution in this way as it felt very obtrusive to have a rubyurl frame at the top of the browser window.

One person suggested a captcha to try and verify that the user is human, but there are problems with this.

I really dislike captchas. ;-)
This doesn’t prevent spammers from using the ShortURL gem, which does everything via an API.

In regards to the API, this could be enhanced by requiring that everyone register an email address to get an API key, but only solves the API abusers.

I’m starting to brainstorm some solutions that specifically help the requests made through the web. I haven’t checked the logs enough yet to verify it, but I have a strong suspicion that much of the abuse is happening through a web-based bot, not through ShortURL… because Ruby developers are nicer than that. (I hope…)

So, I am curious… dear readers of my blog. How might you solve this problem without disrupting the user experience? Or, should I just stick with what I’ve got going and find a better way to respond to pissed off bloggers who think I’m spamming them?

Discuss…

AT&T Online Support could use some QA

Robby Russell — Wed, 06 Jun 2007 01:15:00 -0500

So, I was trying to send AT&T wireless a support email through their online system and got stuck at the following screen.

Come on guys… you can design a better form than this… and I’m now going to have to try and sneak in a question under a sub-topic that doesn’t apply to my question… just so I can send you an email?

Getting help shouldn’t be so hard¹.

¹ At least I can Print this page and show all my friends…

Hug Your Designer Day, part 2

Robby Russell — Wed, 23 May 2007 17:04:00 -0500

In an effort to increase awareness of the importance of good Interaction and Interface Design in Web Development… I suggested that today be... Hug Your Designer Day.

Designers Versus Developers

Are you seeing a lot of this in your Design and Development teams?

Allison Beckwith, Experience Director and Graeme Nelson, Lead Architect

Happy Designers and Happy Developers

Well, maybe it’s time that your developers gave your designers a hug…

Alain Bloch, Web Developer and Chris Griffin, User Interface Designer

Also… to celebrate Hug Your Designer Day, Amy Hoy was kind enough to post her slides and some audio that I recorded of her talk at RailsConf 07.

Let’s all take a moment to thank the designers who put the experience of the users first. The success of our projects rely on everyone working together. Hug Your Designer! (they might hug back…)

Hug Your Designer Day

Robby Russell — Tue, 22 May 2007 17:18:00 -0500

Amy Hoy, of slash7 fame, gave a talk titled, Rubber, Meet Road: Getting Designers Running with Rails, which provided a good overview of some of the problems that designers and developers face when working together. This was one of my favorite talks, because she essentially explained several of the problems that our team has faced in the past and in many ways, still encounter from time to time. A few things that I was surprised to hear, was that several companies leave their developers to implement HTML/CSS in the Rails applications, rather than let their designers into the area. Some teams, provide a directory in public/ for their designers to write their HTML/CSS. Amy said that she preferred to work in the standard view directories (as a designer), which is exactly how our team works.

In fact, I agreed with Amy on several points.

Developers say, “We can’t do that” too often, when really… we mean, “We won’t/don’t want to) do that”
Template languages create extra barriers to training designers. Stick with RHTML… designers won’t be afraid of ERb syntax if you sit down with them and explain some of it. Move the ugly stuff to helpers… like you should be anyways!
Teach your designers how to use subversion… let them break it first and then help them… they’ll love you for it
When meeting clients with a designer and a developer… don’t let the developer speak too much about implementation when it hasn’t been designed yet. Interaction Design should dictate architecture not vice-versa.

“Stop, Collaborate, and Listen”—Vanilla Ice

I’d like to personally thank Amy for being a diplomatic designer and telling the hundreds of developers that showed up for her talk to remember that designers and developers… think differently… and that’s a good thing for the application and ultimately… the user experience.

Having said that, I’d like to request that tomorrow, May 23rd, be… Hug Your Designer Day.

Embracing Failure, part 1

Robby Russell — Tue, 10 Apr 2007 16:38:00 -0500

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

In what ways is your team embracing the failures of your development projects?
How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

Happy Birthday Allison

Robby Russell — Wed, 28 Mar 2007 20:53:00 -0500

This morning was delightful. I woke up to find that 37signals had referenced our website on Signal vs Noise this morning. In particular, they referenced the Rails hosting order form on the PLANET ARGON site. What’s interesting is that Allison created this design over a year and a half ago.. and we’re actually in the process of a complete site redesign, which Chris and Allison are planning to blog about in depth. :-)

There are some discussions within the comments on the blog post about the design decisions that were made, some of which we’ve already begun to address in our redesign process brainstorming (based on google analytic conversion data).

On top of that, today is our Experience Director, Allison Beckwith’s, birthday.

Thanks for the linkage, 37signals!

...and… Happy Birthday Allison!

Do Your Views in Ruby on Rails need a cleaning service?

Robby Russell — Tue, 27 Mar 2007 21:55:00 -0500

I’ve been working on a project with Graeme, and we’re spending some time cleaning up some RHTML views.

He posted an article earlier, titled, Dirty Views? Clean them up!, where he asks the following.

“I am also looking for more information on best practices with views in Rails. There doesn’t seem to be much information on the subject.”

We’re starting to re-evaluate how we approach our views and are curious what other teams are doing… especially if you have a team thats approx 1/2 designers… 1/2 developers per project. We’ll be reviewing some of the other options for the View layer over the coming week(s) and welcome any suggestions/insight to this area of Rails… head over to Graeme’s blog and share your thoughts. :-)

Matz on Considering Interface

Robby Russell — Mon, 25 Sep 2006 10:11:00 -0500

...back in Portland after being in London and New York City for the past two weeks. It’s nice to be home. :-)

I came across this interview with Matz earlier today. It was published almost three years ago (pre-Rails)... I’m quite intrigued by what he is advocating here…

Bill Venners: You also mentioned in your ten top tips: “Be nice to others. Consider interface first: man-to-man, man-to-machine, and machine-to-machine. And again remember the human factor is important.” What do you mean by, “consider interface first?”
Yukihiro Matsumoto: Interface is everything that we see as a user. If my computer is doing very complex things inside, but that complexity doesn’t show up on the surface, I don’t care. I don’t care if the computer works hard on the inside or not. I just want the right result presented in a good manner. So that means the interface is everything, for a plain computer user at least, when they are using a computer. That’s why we need to focus on interface.

Some software people—like weather forecasters, the number crunchers—feel that the inside matters most, but they are a very limited field of computer science. Most programmers need to focus on the surface, the interface, because that’s the most important thing.

Bill Venners: You also mentioned machine-to-machine interfaces, so are you just talking about interfaces for users or also for machines?

Yukihiro Matsumoto: It’s not just user interfaces. When machines are talking to each other via a protocol, they don’t care how the other is implemented on the inside. The important thing is the proper output getting passed correctly via the proper protocol. That’s what matters.
If you have a good interface on your system, and a budget of money and time, you can work on your system. If your system has bugs or is too slow, you can improve it. But if your system has a bad interface, you basically have nothing. It won’t matter if it is a work of the highest craftsmanship on the inside. If your system has a bad interface, no one will use it. So the interface or surface of the system, whether to users or other machines, is very important.

One of things that we’re really advocating with Dialogue-Driven Development is artifact generation. Wireframes and lightweight prototypes are great for generating constructive dialogue between clients, users, and our team. We should make sure that we understand why and how users will use an interface before we worry about the code that will drive it. Too often we fall into a pattern of thinking where we’re convinced that we can build an agnostic application that has various interfaces to a central repository of business logic and data. While we strive for this during development, it really should be focused on after some initial interaction design has been planned. Of course, this is my opinion.

So, I must ask you. When you’re working with on a new project, do you focus on interface or code implementation first?

Agile Interaction Design

Robby Russell — Wed, 30 Aug 2006 14:36:00 -0500

I would like to start some dialogue with all of you…

In a recent post, Jeremy Voorhis said the following about About Face 2.0 in his post announcing his Agile Book Club.

About Face 2.0 isn’t bad; it’s full of some great advice. My biggest gripes with it are the follows:

It declares that programmers are just unfit for interaction design.
It advocates for waterfall development.
Cooper has a defensive tone whenever discussing his beloved discipline of interaction design.
The web chapter is dated.
If you can get over all of those things, it is full of great ideas, specifically about working with personas, and data entry and retrieval.

I disagree with a few of these conclusions. In particular, that Cooper advocates waterfall development. I’ve been hearing a lot of developers throw the word, “waterfall” around… but why?

Take the following excerpt from this great conversation between Kent Beck, the father of XP, and Alan Cooper.

“During the design phase, the interaction designer works closely with the customers. During the detailed design phase, the interaction designer works closely with the programmers. There’s a crossover point in the beginning of the design phase where the programmers work for the designer. Then, at a certain point the leadership changes so that now the designers work for the implementers. You could call these “phases”—I don’t—but it’s working together.”[1]

I’m curious as to how anyone would consider this to resemble Waterfall, which might imply that Cooper’s approach to Interaction Design is incompatible with the principles behind the Agile Manifesto.

Dave Churchville posted an article last year titled, Agile Interaction Design?, which discussed how the role of an Interaction Designer (ID) can be compatible with Agile methodologies. “An ID team probably becomes the voice of the customer in Agile methods, and as such should be working closely with the development team as well as the users. In that sense, the ID role may be more of a liaison between customer and developer.”

So, do you think that Interaction Design as described by Alan Cooper… is compatible with the principles of the Agile Manifesto?

UPDATE It looks like this conversation was picked up on the Joel on Software discussion boards.

¹ http://www.fawcette.com/interviews/beck_cooper/page8.asp

Link: Rails for Designers

Robby Russell — Tue, 21 Mar 2006 17:02:00 -0600

Kevin Clark has just posted, Rails for Designers, a blog entry that gives designers a nice intro into Ruby on Rails.

I’m reminded of a post by DHH last year titled Why are designers so excited about Rails?

Teach a HTML/CSS designer RHTML or Liquid... and some SVN… and you’re in business!

Robby on Rails: Tag design

Tip: Link to Unimplemented

Related Posts

Review: FogBugz, part 1

Signing up for a free trial

That Checkbox Needs a Label

Saying Goodbye Was Never This Hard

Skitch... my favorite desktop application of 2007?

Introducing “LOLBUGZ”

Zeldman on Web Design

RubyURL: new design and code base

Designers, Developers, and the x_ Factor

Moving forward (together)

Idea 1: Comment our “special” HTML elements

Idea 2: Reserve id’s for developers

Idea 3: Naming convention for Ajax-dependent elements

RubyURL 2.0 on the horizon

AT&T Online Support could use some QA

Hug Your Designer Day, part 2

Designers Versus Developers

Happy Designers and Happy Developers

Hug Your Designer Day

Embracing Failure, part 1

Happy Birthday Allison

Do Your Views in Ruby on Rails need a cleaning service?

Matz on Considering Interface

Agile Interaction Design

Link: Rails for Designers