2 posts tagged “programming”
I just now had a bit of a what I call a "user moment". It's one of those times where my refined, logical understanding of technology and design breaks down and I see things the way an ordinary, "unskilled", user would. It can be a bit unsettling.
Clicking through Digg I saw an article titled: Get Started with the Eclipse Platform . I have messed around with Eclipse a little in the past, but with a big piece of software like that it can be tough to know where to begin with it. I needed a straightforward "this is what the software is designed for, this is what it can do" sort of introduction. This article seemed like it could be just the thing I needed . I clicked the link to the article which lead me to an IBM developerWorks page.
It took me less than two seconds to mentally say ugh and close the tab. I stopped. That happened so quickly. I realized that without reading any of the content on the page I had completely dismissed it as a dry technical write-up with little informational value. I went back to the page. It is actually a very well written article that clearly defines the project and its features in a way that someone like me can grasp it. It was perfect.
So why did I dismiss it so quickly?
Looking at it, it displays many of the design principles that I am fond of: lots of whitespace, simple consistent navigation, no distracting elements. In fact, it's quite likely that I would have taken the same approach with a similar piece of content.
There is something missing from the page however. My initial reaction was something like Oh no, corporate technical documentation. Evade, evade, evade! The page looks and feels like process model documentation. I wanted to read something written by a person, not a company.
How do you communicate the human element?
It's becoming clear to me that if I only frequented sites that fit into my personal web design philosophies I wouldn't go to very many sites. Good content keeps me coming back, but I need a reason to check out the content in the first place. Usually, a snappy headline does the trick. Just take a look at Digg.com's front page and you'll see that that's a widespread phenomenon. Sometimes, though, when the need to view a specific piece of information is low, and the competition from other possible sites is high, it takes more than a clever title to make it stick.
Perhaps something as simple as putting the authors' pictures with the article would have helped. Or, they could structure their technical articles like a blog. I read many articles written by Microsoft employees that are technical in nature but because they are in blog format they feel much more personal. In any case, it is a subtle difference in the page's deign, not content, that makes the ultimate difference in my investment with the site.
Analyzing the situation like this really bugs me. As a web developer I hate the idea that a user will make a decision about whether or not they like my site in just a few seconds (if that) based solely on superfluous design elements. It's even worse to think that I myself do the same exact thing.
I have listened to .NET Podcasts on the topic, I've read the Wikipedia article, I've subscribed to testing blogs. I've even written actual NUnit testing code while following a tutorial. But still, I have no idea how to do Test Driven Design.
There hasn't been any other programming concept that has been as elusive to me as TDD. I feel like maybe I should be doing it. It is one of those things that programmers talk about in floaty idealized language, like Agile. The difference is, I get Agile. In fact, I use Agile (sort of) in my day to day work. When people talk about Agile they talk about it in terms of projects and deadlines and clients. Those are concrete terms that apply to my day to day work.
When people talk about TDD they tend to only talk about how great it is and how everyone should be doing it. Okay, you sold me. I'm a joiner, a sheeple, whatever. Now I need some tangibles to move from abstract concepts to actual production code.
An example like this:
http://www.agiledata.org/images/tddStates.jpg (source: http://www.agiledata.org/essays/tdd.html)
tells me very little about the nuts and bolts of TDD.
I'm willing to accept that it's a personal shortcoming that prevents me from moving from theory to application but it definitely isn't from lack of trying. Hopefully, I'll be able to just ride this fad out and get a jump start on the next big thing when it comes along. (Oh please let it be LOLCode!)
