Scott Boms

Our June 2006 Back Catalogue

Revisiting Sliding Door Buttons

Back in early May I talked about what I dubbed ‘Sliding Door Buttons’. I’ve continued to evolve this technique to the point where it’s now behaving consistently across browsers and platforms.

Sliding Door buttons example
Sliding Door buttons example preview

The essence of the technique and the reasons behind its usefulness remain the same, but there are now some additional enhancements that I think add to the implementation and provide basic design features that might otherwise be difficult to achieve using other methods.

Code Structure

The HTML code required is slightly rearranged and helps work around some basic problems in the previous implementation. But before we talk about any specific changes to the CSS, let’s look at the basic structure of a sliding door button.


<div class="buttons">
  <a href="#" title="Add a new user" class="btn"><span>Add User</span></a>
</div>

<div class="buttons">
  <a href="#" title="Cancel" class="btn-disabled"><span>Cancel</span></a>
</div>

The surrounding div element with the class “buttons” is not necessary, it’s simply included as part of this illustration. The basic code is an anchor with a span element inside it. Simple? Yes. Clean. Yes. Do we have the hooks we need to style it? Yes.

The only real difference between this version and the previous one is that I’ve reversed the order of the span and anchor and which element has the button class applied to it.

The CSS

As mentioned in the first part, the basic idea behind these buttons builds on Doug Bowman’s Sliding Doors of CSS technique but rather than being focused on site navigation, we’re instead focusing on a common UI element, the button. The approach is essentially the same: use simple HTML elements, two images (one for the left side and another for the right) and allow the button to expand as necessary to accommodate longer text.


  * {margin: 0; padding: 0;}
  body {
    background: #fff;
    font-family: "Lucida Grande", Helvetica, Arial, sans-serif;
    font-size: 12px;
    line-height: 1.2;
    margin: 16px;
    text-align: left;
  }
  p {margin: 0.5em 0;}
  .buttons {
    background-color: #efefef;
    border-top: 1px solid #ccc;
    padding: 4px;
  }
  .btn, .btn-disabled {
    background-color: transparent;
    background-position: 0 0;
    background-repeat: no-repeat;
    font-size: 12px;
    font-weight: bold;
    padding: 5px 0 6px 8px;
  }
  .btn {background-image: url(images/btn_dark_left.gif);}
  .btn-disabled {background-image: url(images/btn_light_left.gif);}
  .btn span, .btn-disabled spam {
    background-color: transparent;
    background-position: top right;
    background-repeat: no-repeat;
    margin-left: -5px;
    margin-right: 8px;
    padding: 5px 12px 5px 8px;
  }
  .btn span {
    background-image: url(images/btn_dark_right.gif);
  }
  .btn-disabled span {
    background-image: url(images/btn_light_right.gif);
  }
  a.btn:link, a.btn:visited {
    color: #333;
    text-decoration: none;
  }
  a.btn:hover {color: #666; text-decoration: none;}
  a.btn:active {color: 001999; text-decoration: none;}
  .btn-disabled {color: #ccc; text-decoration: none;}
  a.btn, a.btn-disabled {
    display: table-cell;
    vertical-align: middle;
  }

The big change that helps resolve the consistency problem in the earlier implementation turned out to be very simple: use display: table-cell on the anchor element. For Windows IE, note that you’ll have to use display: inline-block since it’s the only browser to really support it (so far). You can do that simply with a conditional comment.

Following the example here, we could create as many variants as necessary with fairly minimal additions to the CSS code. To take it one step further, you could also add an inline image inside the space to add a simple icon to the button.

How To Create Disabled Buttons

The one real missing piece of the puzzle in terms of making the behaviour closer to a traditional input button is that we have no real way of disabling the button. It’s a link. It’ll always be a link. What we can do is use a bit of JavaScript magic to swap our sliding door button with a nulled button. In this case for the nulled button we remove the anchor and replace it with another span element (another inline element in HTML).

Here’s a quick example of this technique in action. I’m not demonstrating the JS swapping here. My suggestion there would be to look at Prototype for that sort of interactivity since it makes it very easy.

As before, I welcome your questions, comments and critiques. Simply drop a note in the comments.

My Beef With Firefox

Don’t get me wrong, Firefox is a great browser as are its numerous offspring, but like competitive browsers such as Safari and Internet Explorer, it has its own set of quirks and anomalies to frustrate web designers and developers.

Firefox scrollbars
Absolutely positioned scrollbars within Firefox

My current gripe is the way scrollbars are handled in relation to absolutely positioned elements. Simply: they’re not handled well.

The problem is that if you attempt to position an element (such as a DIV) above another element which has `overflow: auto` set and a lower z-index value, the scrollbar from the lower element pokes through the element with the higher z-index as you can see in the screenshot. Ugly.

Safari gets it right and there’s no show-through of the scrollbar since the z-index values seem to be honoured correctly. Heck, even IE6 gets it right.

I’ve scoured countless pages via Google looking to see if there’s an answer to this and haven’t found one. Even the latest build of Bon Echo, Firefox v2 still contains this bug/quirk.

The worst part is that I’m not even sure what the problem is other than its specific to Mozilla-based browsers. Is it an XUL problem? General CSS spec implementation problem? Something else…?

New Projects: remarkr

Even though I already have more than enough going on to keep me busy, the projects I’ve been handling lately have inspired me to get a little skunkworks project out of my mind and off the ground. So today marks the start of my what little free time I have project, remarkr.

remarkr Logo

remarkr will have nothing to do with blogs, or bookmark management, wine or web-based invoicing but will have everything to do with filling a huge hole in the graphics industry and will hopefully put the competition to shame by providing fewer features, a significantly user experience and more bang for your buck.

I’ll undoubtedly be talking to a few Rails folks at RailsConf in just over a week’s time about this to gauge interest and see if anyone else would like to come on board to lighten the load and share in the fun.

If you’re interested in participating, fire off an e-mail to whatis [at] remarkr [dot] com or sign up for the launch.

Dreamhost on Rails

In setting up the launching pad for what I suppose will be my second endeavour in the “Web 2.0” application market following the initial beta launch of FiveRuns which went live last week, I quickly transformed the static “coming soon” page for remarkr into a simple Rails application to handle beta/information signups.

Local development with Rails is simple using either the default Webrick server or mongrel, but moving the application to my web-host of choice, Dreamhost proved to be a bit frustrating. It all worked in the end, but was made tedious by some wonky documentation. In the hopes of saving someone else the same trouble I ran into, here’s some additional notes on getting your Rails app running at Dreamhost.

Assumptions

I’m assuming you’ll be running the application from the web-root, meaning the main page of your app would be displayed if the user went to www.yourdomainname.com, and not app.yourdomainname.com.

Baby Steps

Before you do anything, be sure to create a database instance to use for your domain. Make a note of the address, username and password as you’ll want that information for the database.yml configuration file which should go under production.

You’re ready to upload your app via FTP. Dreamhost apparently requires most of the directories for your Rails app to have 766 permissions for folders and 664 for most files, the exceptions being your public directory and the log directory which can be set to 755. If you are getting weird errors and things aren’t running as expected, this is something to check.

Configuration

In your config/environment.rb file, be sure to uncomment line 5 to set the ENV['RAILS_ENV'] variable to ensure your app runs in Production mode.

ENV['RAILS_ENV'] = 'production'

While you’re at it, you may also want to store sessions in the database, and if so, uncomment line 28.

If you are planning sending e-mail from your Rails app, you’ll need to set some defaults for ActionMailer as Dreamhost requires you to use smtp and to authenticate to the mail server in order to send mail. I recommend reading the mailers examples on the Rails Wiki.

Lastly, in order for URLs to be redirected properly, you may (this may be deprecated with Rails 1.1.2 and newer) need to add one last line to the end of the environment.rb configuration file. If so, it should look like this:


# Extra configuration to fix Dreamhost Routing problems
# Make sure to also uncomment the ENV variable (see line 5) above to set
ActionController::AbstractRequest.relative_url_root = "/appname"

Dreamhost Web Admin Configuration

Now you’re ready to make a small adjustment to the default domain setup. Essentially rather than leaving the Web Directory at “/”, we need to tell it to use the public directory for our app.

Dreamhost domain setup for Rails
Dreamhost domain setup for Rails applications

So, if your application was called addressbook, your Web Directory would be domain.com/addressbook/public. Simple right? While you’re at it, make sure you have the Fast-CGI checkbox checked.

Dispatch!

The last thing we need to adjust how the application is dispatched which means two more small adjustments.

Open up the .htaccess file in public and set the default redirect rule for dispatching Rails to use the fcgi script. Change line 28 to read:

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

The last is changing the shebang line in dispatch.fcgi which you can find in the public directory of your application. For Dreamhost, it should be set to:

#!/usr/bin/env ruby

This will locate ruby and should generally work even in your development environment.

That’s it. Assuming all went well you should have a Ruby on Rails application up and running on Dreamhost.

FiveRuns Systems Management In Beta

Since March, Wishingline Design Studio, Inc. has been working with Austin, Tx based FiveRuns and UI/interaction designer Theresa Neil to design the front-end interface for their premier hosted web application along with other components such as their public-facing website and marketing e-mails.

After countless hours of design, coding, squashing bugs and making general improvements we’re proud to announce that the FiveRuns application has been rolled out for the first round of beta testing, primarily focused on overall UI interaction and general usage.

There’s still plenty of room for improvement and feedback from users to ensure we release a solid application that stays true to the pragmatic approach while also pushing the boundaries of the systems management application market space.

A big tip of the JBM mug to the FiveRuns team and all who had a part in getting us this far!

« May 2006August 2006 »