Chris Johnston

One of the things that I am passionate about is the need for applications to be both usable and aesthetically pleasing for the people using them. If your application does not meet these two requirements then, in my opinion, you have failed. This means that every development team needs UX people. Or as Michael Feathers’ puts it, “To put it more boldly: it’s not that development teams need UX people, it’s more like UX teams need developers.”

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.

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

I am not sure if anyone else has had this problem, but one thing I have never liked about using Yahoo! UI Grids library is that I could never get a background colour applied to <body> to fill the entire background. It would only go to the bottom of the #doc div. So if that happened to be half way up your browser window you were left with half a window of white.

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;
}

The subject line basically says it all; what web design application are people using for Ruby on Rails projects on OS X? My first guess is TextMate. Are there any apps out there that support Rails layouts and ERB?

I am currently taking a look at Panic’s Coda and am really impressed with what I am seeing. Anyone have any other suggestions?