As we prepare to overhaul Pathfinder’s corporate website, my colleague Dietrich and I have been giving Radiant CMS a spin. An open-source, Rails-based content-management system, Radiant offers up the slogan "content management simplified." Although Dietrich has been doing most of the heavy lifting, thus far Radiant seems to live up to its tagline.
Read more »I wasted eight hours trying to set up a high-end universal remote control last week. In the process, I was reminded that usability matters as much in the world of physical gadgets and desktop software as it does in the web-browser ghetto.
My new Logitech Harmony 670 Universal Remote was supposed to replace the dusty old universal remote I’ve been using for the past eight years. The old remote – a Home Theater Master SL-8000 – was state-of-the-art for its time, but I could never get it to replicate the functionality of my Tivo Series 2 DVR remote, perhaps the most ergonomic and usable remote control ever designed. I was happy enough with my two-remote setup till I saw the Logitech, a programmable universal remote especially designed for the DVR aficionado. It was shaped like a Tivo remote, so I figured it would combine the simplicity and elegance of my Tivo remote with the universality of my Home Theater Master.
Fat chance. Thanks to terrible software and abysmal hardware design, the Logitech sent me scurrying back to the comfort of my two existing remotes. Here are the five reasons why:
Read more »My index finger is about to explode.
Some clients cling to the ‘us versus them’ mentality of old school
development. You know:
Them: “It says here in your very own document that when I click <Massage> the back panel of my chair would start vibrating, and it doesn’t! Fix it!”
Us: “But the master document clearly states you need to install a Yamahoochi 45697 Vibrating Chair Back for this to operation correctly”
Them: “Where?”
Us: “Master Document 123, Section 56, Hardware Requirements, Sub 876, Chair Backs, sentence two.”
Them: “What page was that again?”
Hoisted by his own petard indeed.
I was reminded of this recently when I asked a client why
his team was doing the fourth review of a specification about which we
just ended an hour long conversation. Her comment was, the
specification didn’t accurately represent field which
they wanted set to read only. Originally they wanted to be able to change it.
My fault. The specification was written 9 weeks before, the client never reviewed it (nor did the development team). The changes were minor and the conversation had nothing to do with the field.
So the client initiated another full blown review of the specification, four days before we’re supposed to start prototyping it.
I missed two areas I should have changed. The other four, I changed.
I am reminded getting everyone on the same team with the same dedication to assisting
everyone else appears to be an never ending
goal.
In a former life, I was a Senior Technical Writer on the Cause Team for a chemical gases company that had some fabulous tools for determining root causes.
Very good idea.
Very kewl explosions.
It turns out that checking to see if an LP cylinder is empty with your cigarette lighter is not a really smart thing to do.
And it’s a really bad idea to lay blame and be done with it.
On an Agile Team, when fault occurs, no one’s happy. The better idea is to ignore the person and deal with the fault.
1. Find the fault (what happened?)
2. Figure out the cause (why did it happen?)
3. Repair the fault (repair how it happened)
4. Make sure the fault cannot occur again.
My Six Sigma Green Belt is pulsating contentedly. Not so strange. The idea behind Six Sigma was Motorola’s desire to reduce manufacturing faults to three per one million units produced. The mathematician/Speakers of Greek tell me that’s what Six Sigma means. I just took a seminar, filled out a 34 page application and took a test- I dread the thought of getting a Black Belt.
When a team is developing something brand new, we’re in a creative thinking space, Much of the time, some of the holes of the new pieces don’t match up on the machine. Or the client remembers or sees something else that absolutely positively has to be included. Or we can make the end user’s job easier and make them more productive in user testing .
So the Development Team rarely points fingers. In fact, most of the time I’ve seen the developer whose work is brought into question turn bright red and pressures him or herself to get a fix as quickly as possible. Everyone on the team looks for answers. And everybody learns as well. That’s one of the reasons Agile Methodology for medium and small projects works best with highly motivated and senior level folks.
Which means I’m gonna keep my mouth shut, fix the specification and get back to the other stuff I have to do.
You’ll have to excuse me for a little while, though.
I’m gonna go find an Ace bandage, soak it with water and apply it to my index finger so it doesn’t explode.
Technorati Tags: fault finding six sigma team
Powered by ScribeFire.
Many large ecommerce sites work beautifully as long as users do what they’re supposed to. The minute users make mistakes, however, the UxD falls apart completely. Case in point: Amtrak‘s online checkout process, in which poor choices about error handling can make it a real hassle to check out successfully.
Amtrak’s first mistake was to create an email address verification field. Plenty of usability experts have decried this silly device for encouraging error-free user input. The annoyance would be minor, however, if Amtrak at least autofilled the email verification field for returning visitors. It doesn’t. When you log into an existing Amtrak account and try to purchase, your address is autofilled in the main email field, but it’s not autofilled in the verification field. Because there’s only one field in the entire "Contact Information" section of the page that doesn’t get autofilled, it’s easy to breeze past and not realize that input is required. You go on to enter your credit card information and click "purchase," only to end up with an error. Until recently, that error wasn’t caught by any client-side validation, so you had to wait for a round trip to the server before being notified. Recently, though, the interface has been updated so that you get a 1999-era JavaScript popup telling you to fill in all required fields. It’s nice that Amtrak at least reduced the annoyance of this bug, but why not just fix the root problem by either getting rid of the email verification field altogether or autofilling it for returning customers?
In keeping with my new year’s resolution to laud as many good Ajax apps as I trash bad ones, please allow me to celebrate the simplicity, beauty and utility of Ninjawords. An online dictionary developed by Phil Crosby, Ninjawords offers a fast, minimal Ajax interface built on the Ruby on Rails and Mootools frameworks.
When you visit the Ninjawords homepage for the first time, you see nothing but a Google-esque single-field search form and two buttons. When you type a word into the text field and click the "look up" button, a single definition for that word appears almost instantly. Most definitions come from the open-source Wiktionary; these definitions are linked to their respective Wiktionary pages and may also include a list of synonyms. For words not covered by Wiktionary, Ninjawords defaults to the Princeton Wordnet dictionary, which doesn’t offer synonyms or linkable pages.
I had a read of some of the Echo3 developer docs this weekend. In particular, the docs on how to create a custom component were very interesting. If you’ve read the custom component docs for Echo2, you know how messy that was. This time around it looks a little cleaner. There are basically three different object hierarchies:
EchoApp.Component.EchoRender.ComponentSync, which deal with manipulating the DOM hierarchy.nextapp.echo.webcontainer.AbstractComponentSync, which handles synchronization between the client-side and server-side component.
The docs aren’t quite done yet, but already it looks as if component writers can leverage the framework much more than in Echo2. It’s good to see that event handler hygiene is encouraged in the docs.
Powered by ScribeFire.
A few months ago, I started writing down some thoughts on the purpose of meetings, spurred on by The Laptop Herring. I went back and re-read my initial comments and realized that I must have just walked out of a particularly unsatisfying meeting when I wrote them down. My words started out like this:
The purpose of any meeting involving three or more participants falls into
one of two categories:
1. The dissemination of nuanced information
2. The agreement on a given course of action
[...]
I then go on to describe what I mean by ‘nuanced information’. I’ll spare you the original brain dump, but I think I was on to something here. Let’s tackle that first category, ‘the dissemination of nuanced information’, as category #2 is really implied in #1 (after all, if you are not all in agreement over something, that should become apparent right away).
Put simply, meetings are not the place to recite facts that can be referenced elsewhere. They are also not the place to expect attendees to collectively remember things in the hope that something great will eventually come out of it. They are also not good brainstorming sessions(*). Instead, meetings should be used as a place to describe things whose usefulness depends entirely on nuance.
nu-ance |ˈn(y)oō,äns|
noun
a subtle difference in or shade of meaning, expression, or sound : the nuances of facial expression and body language.ORIGIN late 18th cent.: from French, ‘shade, subtlety,’ from nuer ‘to shade,’ based on Latin nubes ‘cloud.’
For example, I always take it as a bad sign when the last words spoken after a presentation are some variant of "can you put this up on the wiki for those who weren’t here?" This tells me that the pertinent information, in electronic format, can be fully understood without the group being present– and therefore that 90% of the meeting was not necessary in the first place. It would have been better to write up the reference portion directly on the wiki before the meeting, and meet to cover only the more nuanced parts of the material in question.
Take stand up meetings as another example. There are a few reasons why I work to keep these as short as possible in any team I am part of, but the most important reason is to help discipline ourselves when it comes to valuing other people’s time. Productive meetings don’t just happen when you want them to happen. Timing them is an art, and knowing what bits of information are worth discussing in front of the entire team, and what can be pushed off or condensed down to three words or less requires a few different skills. A daily ten minute stand up meeting eventually brings that out of you, and if you do the math, you will choose your words carefully in a five person team when you have only two minutes of everyone else’s time to say them.
A well-run stand up provides some additional benefits. A few team members (particularly the ones who learned to hate all meetings early on in life) start wondering how to make other meetings as short and concise as those daily stand up meetings– good things can come out of this too.
(*) Everything I wrote above applies to what I call large meetings (i.e., more than three participants). I’m much more flexible when it comes to smaller groups, mostly because I feel that there is less likelihood of wasting time in a group of 2-3 people, and greater "shared responsibility" to keep things on track. This is why brainstorming sessions or design sessions are best in smaller groups.
So, while most of you were off celebrating the holidays, Dietrich was off killing a duck, or at least Duck Typing. Personally, I always thought that the goose was the traditional holiday bird.. shows what I know.
Deitrich’s argument is that Duck Typing does not allow “Dead Duck Typing”, being able to restrict access to part of an object’s state or functionality. The classic case here is keeping a display layer from getting at the persistence layer. (Maybe we can call this Stephen Colbert Typing, since you’re declaring part of the object as “dead to me”…)
Dietrich closed his post with:
Some will argue this is a Java-ism creeping into Ruby. I say this is just plain old-fashioned good OO design.
Which I think is my cue.
I understand the theoretical argument for having strict (or stricter) access control in a system, and I certainly understand why having small, high cohesion classes is a good thing. My problem is that it’s very rare for me to have a practical issue in a system because of loose access control or overly generous interfaces (granted, I’ve had a good run of working with smart people). On the other side, I commonly find that when I’m writing a program with access control I’d like to do something more flexible with an object, but I can’t, because the original writer of the class did not anticipate the usage.
Specifically on the Ruby side, it’s actually not hard at all to restrict access to an object. ActiveRecord objects can easily be made read only called before being passed to a view to protect from inadvertent changes.
In the more general case, it’s not hard to do something like this, which only allows certain methods of an object to be called:
class ArbitraryProxy
def initialize(object, *methods)
@object = object
@methods = methods
end
def method_missing(method, *args)
if @methods.include? method
return @object.send(method, *args)
end
super
end
end
x = ArbitraryProxy.new("abcd", :size, :gsub)
p x.size
p x.gsub("b", "---")
p x.upcase
This returns:
4 "a---cd" NoMethodError: undefined method ‘upcase’
The interesting thing is that, by and large, Rails developers don’t feel the need to do this. I don’t think I’ve ever seen an authoritative source suggest that it’s best practice to make ActiveRecord objects read only before passing them to the view.
There is a Rails plugin called Liquid that enforces the use of proxy objects before being passed to the view. It’s not very widely used (in part because creating the proxies is kind of a pain).
I don’t see that Ruby and Rails programmers see this issue as a practical problem facing them (it helps that Ruby tends to encourage small classes in other ways). That said, there are clearly cases where you need to be extra careful. Liquid is used as user-facing templating engine for a blog tool, which is clearly a case where you’d want to limit the damage that your template writers can do.
But I see that as the exception, not the rule. Long live the Duck!
Coming Soon: Professional Ruby on Rails — available in bookstores Mid-Februrary.
Technorati Tags:
ruby, OOAD, Duck Typing
The New York Times has an interesting campaign event flash-based interactive map (link from the image on the right) which works out to be easy on the eyes.
The animations are not that useful, but what I find most curious about this map is comparing the relative frequency of candidate visits to areas of the country. Knowing something about each candidate, and all politics aside, it tells you something about their election year strategies, or lack thereof.
Nicely done.
You can never know too much about something, right? Wrong, at least according to a December 30th article in the New York Times. As we become experts in a particular domain, our ability to innovate diminishes.
“Andrew S. Grove, the co-founder of Intel, put it well in 2005 when he told an interviewer from Fortune, “When everybody knows that something is so, it means that nobody knows nothin’.” In other words, it becomes nearly impossible to look beyond what you know and think outside the box you’ve built around yourself.”
Reading the article, I couldn’t help but think back to my own experiences with this same sort of issue. I blogged recently about two related ideas: how interface designers are sometimes guilty of thinking as designers–when they should be thinking as users, and about the mixed bag that is competitive research, which can limit the designers creative thinking by boxing them into predefined solutions.
Now I see that it’s part of a larger problem of expertise and creativity. The more expertise one exhibits in a particular field, the harder it is to think creatively–to so called think ‘outside the box’, and the harder it is to imagine not knowing what you do. The problem affects whole companies, as a certain way of thinking becomes entrenched, and it gets harder for it to adapt to a changing landscape. The article cites the example of Eveready, the flashlight maker, who’s powers-that-be couldn’t imagine that their product could be effectively marketed to anyone other than men shopping at hardware stores.
According to Cynthia Barton Rabe, author of “Innovation Killer: How What We Know Limits What We Can Imagine — and What Smart Companies Are Doing About It,” the solution for Eveready, as for any organization bogged down in its own expertise, is an infusion of outside thinking. Bringing the so called novices–the non expert users–into the discussion at the early stages of design, weather it be product or strategy design, opens the door for new ways of thinking that experts have long been insulated from.
Powered by ScribeFire.