Tip: Link to Unimplemented
13 comments Latest by Matt Krom Tue, 01 Apr 2008 20:26:26 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.
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
Enjoying the content? Be sure to subscribe to my RSS feed.
imo a better approach would be to use link_to_unimplemented(NORMAL_LINK_TO_SYNTAX_HERE) so everything can be wired up beforehand.
When it is finally ready, just replace link_to_unimplemented with link_to and your done.
PS: some unobstrusive sugar for you New Feature
$(‘a.unimplemented’).click(function(){alert(‘oh noes!!!’)}) (jquery)Not that I’ve tried this, but your post sparked an idea in my head… one could use named routes to go ahead and link to the appropriate place, but in the
routes.rbfile, point all the unimplemented things to the same page, e.g.map.with_options :controller => 'feature' do |m| m.feature 'feature/view', :action => 'unimplemented' endIn the
applicationcontroller, add a method called unimplemented with a friendly view (so it’s available in all controllers).Now, you have one file (
routes.rb) that lists all the unimplemented features, and you can change the action appropriately as features are implemented.You can link to features with the named routes without having to worry about going back and fixing all the links.
Of course, this doesn’t work so smoothly with fancy-pants REST routes and the like (which I don’t use).
Thoughts?
@grosser: yeah, that’s an interesting idea.
The helper would probably need to append a class to it that wouldn’t affect any CSS class definitions made.
Intersting idea. I like this approach much better than the old familiar anchor tags. Thanks for sharing Robby.
@grosser: I thought more about your idea and don’t think we could safely rely on that. If we haven’t implemented an area (yet)... your approach would require us to have routes pre-determined (and working)... or we’d need to hardcode paths, which doesn’t do us any favors.
I like the unobtrusive approach, but given that we’re linking to thinks that don’t exist or aren’t working, I’d prefer there to be less heavy lifting. Also, it allows our web designers to do their work before the developers go through and making things work. They don’t need to be bogged down by defining routes (especially if they don’t exist yet).
Still an interesting idea for when you do have that stuff figured out. :-)
I’ve been using my similar to_do_link helper on every project I’ve worked, so I suppose that’s a kind of natural pattern. As you said it’s tremendously useful, mainly in iterative development where users can explore applications under development.
What I do is usually put this in my routes:
And then grep for
not_implemented_path. Also, you could comment that line and see which view specs fail, too.Nice tip. I always do this by hand but a helper is… helpful :) And I guess it can be used with image links as well, using image_tag instead of the text.
I really don’t get the not_implemented_path thing… What Bad^H ^H ^HRobby is focusing on deals with user experience during the development. This is the goal, and his javascript thing is a pretty good idea.
Unobstrusive js is also unnecessary, unless Robby wants to keep features not implemented for months.
Last but not least, if you really want to redirect to some stupid and unnecessary controller (IMHO), add a HTTP 204 status then with :status => 204. (Naaaaa just don’t do it!)
The other thing to do before final deploy would be to rename the helper method (or make it throw an exception?) and make sure all tests pass; if any calls to it remain, you’re not done!
Seems like this would be nice with a modal window/facebox implementation.
Brilliant; thank you. After reading your post, I did the following, so that link_to works the same as usual, and the unimpl_url looks like any other URL helper. Less to change when you have the real path ready.
== in the view == <%= link_to 'compare', unimpl_url %> == application_helper.rb == def unimpl_url "javascript: alert('This feature is not implemented yet...'); return false;" endThanks again, Matt
Brilliant; thank you. After reading your post, I did the following, so that link_to works the same as usual, and the unimpl_url looks like any other URL helper. Less to change when you have the real path ready.
== in the view == <%= link_to 'compare', unimpl_url %> == application_helper.rb == def unimpl_url "javascript: alert('This feature is not implemented yet...'); return false;" endThanks again, Matt