Read my latest article: Six days to complete the Rails hosting survey (posted Thu, 24 Apr 2014 14:36:00 GMT)

A Mobile Site or Responsive Design?

Posted by Wed, 30 May 2012 19:45:00 GMT

Our team at Planet Argon just released a white paper on this topic. I’d like to invite you to check it out.

Planet Argon Podcast, Episode 2: The Letter Scotch

Posted by Fri, 30 Oct 2009 13:27:00 GMT

Earlier this week our new podcast was approved and is now available in the Apple iTunes Store. We’re also soliciting topic ideas for future episodes on brainstormr.

We posted Episode 2, The Letter Scotch, yesterday for your enjoyment. In this episode, we covered a handful of web browser tools that we use (and detest) to debug HTML, CSS, and JavaScript. This included Web Inspector, Firebug, DebugBar, and a handful of other tools. We all have slightly different preferences, depending on the tasks that we’re working on and the team had an open dialogue about the pros/cons of each of these tools.

You can learn more about and listen to our podcast at http://planetargon.com/podcast.

Thanks in advance for listening!

Flash Message Conductor

Posted by Fri, 29 Aug 2008 21:35:00 GMT

Do you find yourself copying and pasting the same code from Rails application-to-application as new projects start? Our team has a handful of projects in development right now and we notice that some of these reusable components tend to get out of sync when we bounce between projects. So, we’re making an effort to spot these and are creating a handful of plugins so that we can keep them updated between projects. (I’m sure that a lot of you do this as well)

In an effort to share some of our patterns, we’ll try to release them into the wild for others to use and perhaps if you have better patterns to offer, we’re always interested in improving our approach.

Introducing Flash Message Conductor

Over the years, our designers and developers have approached the management of flash messages several different ways. In Rails, the default way to add something to a flash message is to do something like this in your controller.

flash[:message] = "You have successfully signed in to your account."

What we began doing a while back is to create a few controller helper methods:

add_message( "You have successfully signed in to your account." )
add_notice( "You've Got Mail!" )
add_error( "Oops! Something got fucked up!" )

Really, nothing too crazy here, just a pattern that our developers have preferred to managing our application’s flash messages.

Okay, so now for the part of the puzzle that we aimed to make consistent across our projects. Rendering flash messages would usually result in several lines of conditionals in our application layout to check if the flash had any values assigned to it. As we worked with our HTML/CSS designers to define a consistent pattern, we moved our code into a helper for rendering flash messages.

With Flash Message Conductor, we just need to pop in the following into our application layout.

<%= render_flash_messages %>

If we had called add_message, it’d render the following:

<div id="flash_messages">
  <p class="message">You have successfully done XYZ...</p>
</div>

Or, should you have called add_error, it’d render the following:

<div id="flash_messages">
  <p class="error">Oops! Something went bonkers!</p>
</div>

What we’ve done here is defined a consistent pattern for our designers and developers to follow. We’ll always have a div container that will use a p tag to display the flash messages with a CSS class value that maps to the type of flash message that we’re displaying. This makes it easier for us to reuse the same flash message styling (and tweak if necessary), but we know that it’ll produce the same HTML across our applications.

Installing Flash Message Conductor

Like most modern Rails applications, you can install with:


script/plugin install git://github.com/planetargon/flash-message-conductor.git

Then all of our helper methods will be available to your application. We’ve also included an example CSS file, which you’ll find in the plugin directory.

Sample output:

flash message area
Uploaded with plasq’s Skitch!

Anyhow, we’ve posted the plugin up on GitHub for you all to use, if you’d like to adopt a similar approach. If you have any alternative patterns that has helped your team, do share and I’m looking forward to sharing some more of ours in the near future.

For more information, visit the Flash Message Conductor plugin on GitHub.

If anything, hopefully this will inspire those of you who find yourself copying/pasting artifacts from application-to-application to extract that code into it’s own reusable plugin. :-)

Tip: Link to Unimplemented

Posted by Thu, 27 Mar 2008 11:10:00 GMT

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.

unimplemented
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.

unimplemented 2
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?

Related Posts

Managing SEO-friendly HTML Titles with Rails

Posted by Wed, 26 Mar 2008 21:41:00 GMT

I’ve seen this come up a few times in the #rubyonrails IRC channel and figured that I’d post a quick entry for future reference.

Problem: HTML titles

You want to have a clean way to manage the titles on your HTML pages.


  <html>
    <head>
      <title>Robby on Rails &mdash; Article Title Goes Here</title>
    </head>
    <body>
      ...

Possible Solution(s):

Since the <title> tag is usually declared in your layout, you need to be able to dynamically update this information from almost every action in your application.

Here are a few ways that I’ve seen this handled.

  1. Use a instance variable, which would have a default value and you could override it in any controller action
  2. Use the content_for method to manage it.

Let’s take a few minutes to look at these two approaches.

Instance Variable

With the instance variable, you might end up with something like:


  # app/views/layouts/application.html.erb
  <title>Robby on Rails &mdash; <%= @html_title || 'Default text here...' -%></title>

Then in a controller action…


  # app/controllers/articles_controller.rb
  def show
    # ...
    @html_title = @article.title
  end

So, that’s one way to handle it and is probably a more common way.

The content_for helper method approach

This solution is very similar (and underneath uses an instance variable).

We’ll use the content_for and a little yield action.


  # app/views/layouts/application.html.erb
  <title>Robby on Rails <%= (html_title = yield :html_title) ? html_title : '&mdash; Default text here...' %></title>

Then we’ll create a helper method.


  # app/helpers/application_helper.rb
  def set_html_title(str="")
    unless str.blank?
      content_for :html_title do
       "&mdash; #{str} " 
      end
    end
  end  

Now, instead of defining the HTML <title> value in the controllers, we’ll just toss this into our html.erb files as necessary.


  <% set_html_title(@article.name) -%>
  ... rest of view

..and that’s pretty much it.

Which is the better solution?

This is where we’ll not find a lot of consensus amongst people. I’m a fan of the content_for-based approach and defining the title in views rather than in controller actions. I’m an advocate of skinny controllers and while I’m not a big fan of messy views, I believe that there is less overhead in managing this within the View-world.

I’d love to hear your thoughts on this. Perhaps you have a more eloquent for managing things like this? Do share. :-)

That Checkbox Needs a Label

Posted by Sun, 02 Dec 2007 06:43:00 GMT

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.

Older posts: 1 2