Methods of Implementation
When looking for a way to implement a certain feature, sometimes your answer is in unfamiliar grounds. Most often, it works without a hiccup and is an excellent solution; sometimes it blows up in your face when you least expect it.
I’m thinking about one instance in particular: Engadget’s daily roundup feature that works from number of comments. I thought it worked really well because it showed posts which were particularly controversial or engaging to readers. It seemed they were more willing to comment if the post was particularly thought-provoking.
But it broke. I’m about 99.9% sure both the Engadget editorial crew and the designers of the site did not see this coming. It broke because they had to turn comments off due to unruly visiters. So now, someone’s fancy idea of using comments as a method of implementing this feature of the website has completely screwed them. A major feature. On a major website. Broken.
See all those floored purple dots? Those are supposed to be all along the vertical depending on the number of comments for the particular post.
So how could this have been avoided? Proper methods of course! Why base this major feature on comments if post views, trackbacks, and other activity are available?
In retrospect, they really should have seen this coming. I mean, they even had a similar issue back in 2008. That was before the major website overhaul, too.
Maybe I have this type of foresight because I’m an engineer. Or maybe they just have crappy designers at Engadget. Or maybe they knew about the potential problem and just didn’t care.
I don’t know about you, but I don’t like my designs to break. Think about how you’re implementing that new feature and determine if it’s hacky and going to break at the first sign of stress. It will probably make your customers much more happy with your work.
