I has been a long time since I last posted on this blog. Life has been complicated for me over the past year, but hopefully, with the new year, I can make a new start posting to my very neglected blog. I am not entirely sure the direction I am going to take with this new beginning, but hopefully, I will have things to say once again. So look for more posts coming over the next few days.
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.
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 
.