Liquid error: undefined method `source' for nil:NilClass Liquid error: undefined method `url' for nil:NilClass

Is this your first visit? You may want to subscribe to the feed.

Articles tagged with development

Using RedBox for modal dialogs

When I first saw Lightbox, my first thought (ok, second thought; my first was “This is awesome!”) was: “This would be a great technique for confirmation pages!” I never got around to using lightbox due to it’s emphasis on images, but eventually other solutions started showing up, like GreyBox and ThickBox, that allowed you to use other content.

A couple weeks ago, I came across Redbox, a rails plugin based on ThickBox. It is a great little plugin that simply consists of a few Rails helpers and some Javascript.

As I experimented with it, I decided that I really like the feel of using modal dialog boxes for confirmation messages. It is more consistent with the desktop experience, but not as constrained as popups on the desktop.

Redbox Delete

As I was using Redbox, I developed a pattern that works really well. Instead of limiting :destroy requests to POST, I modified them to return a delete confirmation page when called with a GET, then perform the modification when called with a POST.

def destroy
  @payment = Payment.find(params[:id])
  if request.get?
    respond_to do |wants|
      wants.html
      wants.js { render :layout => 'modal' }
    end
  else
    @payment.destroy
    flash[:notice] = "Payment for $#{@payment.amount} has been deleted."
    redirect_to :action => 'index'
  end
end

This creates a little extra code, but it also makes the modal windows degradable. If the client doesn’t support JavaScript, or it is disabled, then when they click a destroy link, they will be taken to a separate confirmation page. I’ve also created a ‘modal’ layout that can have some formating, or maybe a close link.

The code to create the redbox link looks like:

<%= link_to_remote_redbox 'delete',
    {:url => {:action => 'destroy', :id => payment}, :method => :get},
    :href => url_for(:action => 'destroy', :id => payment) %>

link_to_remote_redbox takes the same parameters as link_to_remote, minus the :update parameter that tells where to put the new content. Note the :method =&gt; :get. By default, Ajax requests use POST, but I don’t want to POST to the destroy action because that will perform the modification. I’m also setting :href, which makes this link degradable.

As I used Redbox more and more for confirmation pages, it occurred to me that this method would also work really well for simple forms. So, with barely any modification—adding respond_to in the action and replacing link_to with link_to_remote_redbox—I was able to change these small forms into modal dialogs. Currently, the forms submit a regular request, but I could refactor it a little more and use Ajax to submit the forms and update the page.

Redbox Enroll

Overall, I really like the feel of these modal dialogs. They make the app feel snappier and less daunting. Users don’t have to jump all over the app for simple modifications. They spend the majority of their time on one page, the most important page.

Code: development Sep 21, 2006 ● updated Jun 28, 2007 ● 11 comments

User Interface First

This morning I listened to the Web 2.0 Show podcast with Jason Fried from January 16, 2006. I’ve heard Jason Fried talk before and I think he has some great things to say. One interesting point that Jason makes is that 37signals always designs the user interface of applications first. This is a problem that we have struggled with at Collective Idea.

Jason points out that designing the user interface up front gives the customer the experience for 90% of the project, instead of just at the end. As Darrel Rhea talks about, products aren’t successful simply because they’re functional, but because they are meaningful. Functionality is part of that meaning, but unfortunately only a small part. Much more of that meaning is derived from the experience. This is something that Apple understands.

We recently finished the first iteration of a project and showed a functioning but un-styled back-end of an app to the client. The client didn’t say much during the demo. We then talked about what was going to happen in the second and third iteration. After mentioning that the design would come in during the third iteration, the client spoke up and said that he was glad there was going to be a design. This made me realize that even though we had a fully-functioning back-end, what we failed to provide was an experience. While the back-end is important, that’s not what clients pay for. The meaning for the clients is derived from the interface. The interface is what makes them want to take money out of their wallet and put it in your pocket.

We usually avoid doing the user interface design first, simply because we outsource most of our design. If the interface is designed up front, it’s almost guaranteed to change as our understanding of the product changes. Since we outsource the design, we saw this as a bad thing because we have to pay more for the design. But Jason makes a great point: by doing the interface first, it forces you to focus on the interface for the entire project, instead of having to force it in at the end.

“You can’t click a piece of paper.”
- Jason Fried

Programmers often look at systems from the lowest level up. We think about the data, and the relationships, and the system as a whole, and from that derive an interface. But this is exactly opposite of what we need to be doing. We need to look at the system from the clients perspective. And the best way to do that is to create an interface that both you and the client can interact with. It’s a lot easier to talk about features when you have something tangible. The interface then becomes the driving force for the back-end, instead of the other way around. This also allows you to focus on the epicenter of your product.

Jason also points out that by designing the interface first, your product will look like a version 2 or version 3 by the time the project finishes, simply because the interface will have already gone through several revisions. So what we have failed to realize at Collective Idea is that the extra design costs will pay off in the quality of the product and the satisfaction of the client with their experience.

Code: development Jun 26, 2006 ● updated Dec 12, 2006

Subscribe

Browse by Tag