Chris Johnston

I have got to get me one of these when they come out. Imagine having all of your programs starting up from scratch with the same speed as if you had maximized them. The ioXtreme is 80GB of high-performance, non-volatile storage in the form of a PCI Express card.

There are only two problems with it, one, it isn’t available yet and two, when it is available it will be $895USD.

Here is an interesting article on the need to design imperfection into websites in order to make them more human and more accessible.

Elegant Web experiences walk a fine line separating simplicity (yawn) from chaos (huh?). And the rules that govern the quality of the attempt are derived from considerations of natural organization. This can still be elegant — as long as the chaos is modulated within a stable container, constrained by a well-designed illusion of natural order.

Great Web sites have feel — what Leonard Koren had called “heartfelt intelligence.”…Feel only comes about when you tear away the illusion of perfection.

Words are merely the leavings of our intellect, strung together into a story. The same goes for designed artifacts. The more imperfect the artifact, the more they tell of the passage of time, and the more human they become.

So a postulate I’d like to put forth is that when the proper amount of imperfection is present in a designed Web experience, it feels more human. A Web site that is more human becomes more useful, right? Here, we have to be careful. A web site is only more useful if it is elegant in its imperfection.

I don’t usually include this many quotes, but with this article, a precis does a much better job then I ever could.

Dave Shea has decided to move away from implementing websites using xHTML and is using HTML 4.01. His main reason:

I made the switch more because of overall trends. Six years ago, many of us thought XHTML would be the future of the web and we’d be living in an XML world by now. But in the intervening time it’s become fairly apparent to myself and others that XHTML2 really isn’t going anywhere, at least not in the realm that we care about. For me, a guy who builds web sites and applications for clients that have to work in today’s browsers, XHTML2 is a non-issue. No browser support, no use to today’s web authors. End of story.

This is something I have not really thought about much over the last few years. I made the switch from HTML to xHTML and haven’t really looked back. Now, I am going to have to look into this. I don’t really see anything that xHTML offers over HTML 4.01. I do like the fact that xHTML is easier to parse using an XML parser, but this is a small point given libraries like Hpricot and Nokogiri.

What do others think? Is there any reason to use xHTML over HTML 4.01?

A width of 960 pixels has become the de facto standard for creating fixed-width web sites. Cameron Moll is asking if it is time to move beyond this width, and if so, what do we move to? I personally really like 960 as a width. It makes for easy to read lines of text and helps to ensure that they don’t get too long.

He proposes widths of 1020, 1040, and 1080. I am not sure the extra 60 to 120 pixels will really make that big of a difference.

With most computer monitors now displaying 1280 or larger horizontal resolutions, it is definitely something to think about.

I have been trying to set up a Capistrano script for deploying to a staging and production server. I found this very well written tutorial showing how to set up the various cap scripts to work with mod_rails (Passenger).

One note, Capistrano does not copy over the database.yml file. You need to put this in yourself. This tripped me up for a while since I was assuming that it would somehow magically take the database.yml.template file I had and turn it into a database.yml file that I would then have to configure. The Ruby magic doesn’t extend that far .

When using layouts in Rails, I strongly suggest keeping as much of the container elements in the layout and using content_for to create sections in which content can be placed.

I am working on a site right now that has used the YUI Grids to layout the site (something I highly recommend for anyone designing a site from scratch). Most of the site uses a two column layout. The application.html.erb file looks like this:

<body>
  <div id="doc" class="yui-t6">
    <div id="hd" role="banner">
      <%= render_partial "shared/header" %>
    </div>

    <div id="bd" role="main">
      <%= yield :content %>
    </div>

    <div id="ft" role="contentinfo">
      <%= render_partial "shared/footer" %>
    </div>
  </div>
</body>

What is missing is the part that divides the page into your content area and your, in this case, right-hand side area. This part was placed in the rest of the view files. Not only does this mean that it is repeated everywhere and a huge pain to change, it also means that it is much harder for coders, who may not know YUI CSS Grids, to properly lay out pages. In the case of the app that I am modifying, it has also meant that parts of the CSS layout are strewn careless between regular pages and partials.

Instead, this is how the layout page should look:

<body>
  <div id="doc" class="yui-t6">
    <div id="hd" role="banner">
      <%= render_partial "shared/header" %>
    </div>

    <div id="bd" role="main">
      <div id="yui-main">
        <div class="yui-b">
          <div class="yui-g">
            <%= yield :content %>
          </div>
        </div>
      </div>
      <div class="yui-b">
        <%= yield :side_content %>
      </div>
    </div>

    <div id="ft" role="contentinfo">
      <%= render_partial "shared/footer" %>
    </div>
  </div>
</body>

This keeps everything clean and makes for view pages that look like the following.

<% content_for :content do %>
  put content here
<% end %>

<% content_for :side_content do %>
  put side content here
<% end %>

I think that makes it much easier to see what is happening within view pages. It also keeps all the layout code in one place.

I have spent the last few days working with the CSS in an existing web application. It isn’t pretty. My biggest pet peeve with it is all the special cases that exist. If you find yourself doing a lot of the following you are in for a world of hurt when it comes time to redesign your site.

.homepage h3 {
  some style
}
.about h3 {
}
div.box h3 {
}

My advice is to create a style guide and stick to it throughout the entire site. That way, when you use h3 you will know exactly what it is going to look like and it will stay consistent throughout the entire web site.

Another side benefit of doing this is your CSS file will be greatly reduced in size and will be understandable. This will also save on download times for those visiting your site.