Michael Feathers has written a blog post relating software development to cooking. In it, he asks the question, “Where are the high-end restaurants of software development?” His answer is that they are in the smaller boutique development shops popping up around the world. The shops that adhere to the ideas behind the Software Craftsmanship movement.

In this article, he also states that in this day and age, UX is the defining aspect of developing applications and those teams that do not understand that developing software is all about the customer are doomed. I can’t agree more with this idea. The only thing that matters to a customer of your software is how easy and pleasing is it to use. We as developers can no longer have the attitude that we will create software and, well, the users will just have to learn how to use it. Everything we do needs to be customer and user centered.

Michael also puts forth the idea that as developers we need to learn how to do UX and be able to use those tools when called on. We don’t need to be experts in design or layout, but we should have a shallow understanding of the principles and how to apply them when sitting with a customer.

I want to take this one step further by saying that I think UX also has a responsibility to share their knowledge with developers and have them present during every stage of the UI development process. Just as it is wrong to have developers who know nothing about usability, it is just as wrong to have UX people who do everything in secret and then simply hand developers a design expecting them to implement it.

We need to tear down this curtain that exists between developers and UX and work needs to be done on both sides. One of the best projects I ever worked on involved developers working with designers and UX people creating wireframes and doing lo-fi prototyping with the users throughout the entire development process. Everyone on the team owned the success and failure of the application and in the end we created one of the best apps I have ever worked on. We were able to create an application that the users were excited to start using.

I have also worked on teams were the UX team showed up to standups in the morning and then handed designs to the developers. There were no discussions on whether something was implementable and there was no insight into where the designs came from. For all I know they outsourced the photoshop work to penguins in Antarctica. How can the team own the entire application if one part of it is created in isolation?

If you are passionate about creating software applications that can actually be used by people and passionate about the quality of those application then go read Michael Feathers’ article.

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

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.

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?

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.

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 .

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.

.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.

I finally figured out how to solve this. Grids, or Reset, adds a background CSS attribute to the html element. To get rid of this, and have your background fill the entire browser simply use

html {
  background: none;
}

require 'rubygems'
require 'net/http'

contact_id = 12345
connection = Net::HTTP.new("your_account.highrisehq.com")
req = Net::HTTP::Post.new("/parties/#{contact_id}/tags")
req["content-type"] = "application/xml"
req.basic_auth("your_api_token", 'X')
req.set_form_data({"name" => "new_or_existing_tag"}, ";")
response = connection.request(req)
puts response

This will return a bunch of JavaScript that you can ignore.

For comparison, here is the same code using HTTParty. A very nice, easy to use library for interacting with ReST services.

require 'rubygems'
require 'httparty'

class Tag
  include HTTParty
  base_uri "your_site.highrisehq.com"
  basic_auth 'your_api_token', 'X'

  def add_tag_to_contact(tag, contact_id)
    self.class.post("/parties/#{contact_id}/tags", :query => { :name => tag })
  end
end

puts Tag.new.add_tag_to_contact("tag_as_string", "1")

The goal of all this is to create a Highrise API wrapper that includes the ability to manipulate tags. Highrise is great, but the lack of Tags in the API really reduces what you can do with the tool since there is no facility for creating or manipulating lists.