Tip: Link to Unimplemented 13
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.
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.
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 20
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 — 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.
- Use a instance variable, which would have a default value and you could override it in any controller action
- Use the
content_formethod 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 — <%= @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 : '— 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
"— #{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 10
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.
Spec Your Views 12
I meant to work on this post… oh about 7 months ago.
Way back in January (7 months ago), Jamis Buck posted an article titled, Testing your views, which gave a few tips on using Test::Unit to, as the title suggests, test your views.
While, I’m not going to rewrite everything that Jamis wrote, I’d like to show you how to test these views with RSpec. (you might take a moment to quickly read his post…)
In this example, I’m going to show you how we’re able to write specs for the following RHTML, which you’ll notice matches the code that he wrote tests for.
<% if @user.administrator? %>
Hi <%= @user.name %>! You appear to be an administrator.
<%= link_to "Click here", admin_url, :id => "admin_link" %>
to see the admin stuff!
<% end %>
Jamis writes, “The only really significant thing you ought to be testing here is that the admin link only shows up for administrators. “
So, let’s do just that, but with RSpec.
I’m not sure how Jamis is handling his view tests, but we’re going to approach our view specs, much like we approach our controller specs, with the use of mocks and stubs, because we really don’t need to spec any of our models at this level in the application.
Tip: Write specifications for your models… in your model specs not in your controller or view specs.
The first thing that we’re going to do is setup a custom spec helper, because for something like an mocked user, will probably get reused in other areas of the user interface. Spec helpers are essentially modules that you can include in your RSpec descriptions (the block that starts with describe) and reuse.
In this spec helper, I’m going to include two methods, to mock the User model and stub out any of the methods that are necessary for spec’n this view.
module MockUserHelper
def mock_normal_user
user = mock(User)
user.stub!(:administrator?).and_return(false) # <--- NOT an admin
user.stub!(:name).and_return('David Chelimsky')
return user
end
def mock_admin_user
user = mock(User)
user.stub!(:administrator?).and_return(true) # <--- IS an admin
user.stub!(:name).and_return('Aslak Hellesoy')
return user
end
end
In the mock_normal_user method, we’re constructing a mock object and stubbing out the methods that we see are being called in the RHTML code. In mock_admin_user, we’re basically doing the same thing, but just stubbing the administrator? method to return true for this mock user.
By stubbing these methods, we’ll be able to send a non-ActiveRecord object to the view and have it render without knowing the difference. For example, the if @user.administrator? condition will return true or false, depending on how we stubbed it.
For more information on mocks and stubs, read here.
Now that we have our spec helper, let’s go ahead and dive into a few specifications for the view.
describe "index page" do
include MockUserHelper
it "should render an admin link for an admin user" do
assigns[:user] = mock_admin_user
render 'index'
response.should have_tag('a#admin_link')
end
it "should not render an admin link for a normal, non-admin user" do
assigns[:user] = mock_normal_user
render 'index'
response.should_not have_tag('a#admin_link')
end
end
Please note: This code example is only longer than the one shown by Jamis because he didn’t include how he setup all his user sessions/objects. ;-)
When these specs are run, we can see the following results.
Pretty output courtesy of RSpec + TextMate bundle
Great, we’ve been able to write specifications for our Rails views without a lot of pain. Stay tuned for more posts on this topic as I continue writing about how Designers and Developers can work together, in harmony. (see my last post on this topic)
For more information on adopting RSpec, please visit the RSpec project homepage.
