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:
```javascript
# public/javascripts/application.js
function unimplemented() {
alert("NOTICE
This feature is not implemented yet. Please check back again soon!");
}
```ruby
This allows us to do the following:
```ruby
<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.
::: thumbnail
[](http://skitch.com/robbyrussell/ecx1/unimplemented)\
[Uploaded with [plasq](http://plasq.com/)'s
[Skitch](http://skitch.com)!]{style="font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080"}
:::
Let's take it a step further and push this into a view helper.
```javascript
```ruby
# 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.
```javascript
```ruby
<%= 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.
::: thumbnail
[](http://skitch.com/robbyrussell/ecxh/unimplemented-2)\
[Uploaded with [plasq](http://plasq.com/)'s
[Skitch](http://skitch.com)!]{style="font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080"}
:::
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
- [Designers, Developers, and the x\_
```text
Factor](http://www.robbyonrails.com/articles/2007/08/01/designers-developers-and-the-x_-factor)
```text
- [Spice up your Terminal with colored grep pattern
```text
results](http://www.robbyonrails.com/articles/2007/10/06/spice-up-your-terminal-with-colored-grep-pattern-results)
