development archives
CSS is the weakest link in the web developers toolbox. The problem goes deeper than CSS’s lack of variables. Unlike the “function” in programming, CSS has no fundamental building block.”
Chris Eppstein, the author of Compass writes up a solid argument for the need of abstraction in stylesheets. I’ve been toying around with Compass and the Sass language over the past few weeks and things look very promising.

posted by john on Monday, Sep 21, 2009 · 5 comments

Review: Balsamiq Mockups

In an unrelated post, Jamis Charles asked, “I know this is totally unrelated, but you mentioned some time ago you started using Balsamiq Mockups. I’d like to pitch it to my UI Team. How has it been working for you? How do you incorporate it into your workflow? Has it increased productivity? A post about this would be greatly appreciated. Thanks.”

I’ll let others speak to their own experience, but here’s a quick post on how it worked for me. I was looking for something easy that would help my team focus less on pixels and colors during the planning stage, and just focus on concepts and framework. Balsamiq worked admirably for that purpose. In fact, within weeks of using Balsamiq for our weekly high-level design meetings, team members were themselves articulating the reason to use Balsamiq: “We don’t get bogged down in the details anymore!”

The workflow was something like this:

  1. I would review high level requirements, talk with the customer and mock something up quickly in Balsamiq, with sketchy notes in the margins. As promised, the tool is drop-dead simple for most things it supports. Don’t expect a freeform drawing tool, but for dragging and dropping basic UI elements, it’s very easy.
  2. Team would meet to discuss.
  3. I would take notes directly in Balsamiq, sometimes updating the mockup, but often just leaving a note in the margins for later. Because of the low fidelity of the prototype, the team was able to get past nitpicking the details and focus on the functional requirements and workflow.
  4. Once we moved out of planning into iterative development, I would refer to the mockups and the notes recorded there to create higher fidelity prototypes, using Fireworks images or HTML prototypes, depending on the need. I tried to get a cycle or two ahead of the dev team, and was generally successful.
  5. As the high fidelity design progressed, we referenced the low fidelity mockups less and less. By the last cycle or two, we were hardly using them at all anymore. I probably haven’t opened the tool in 3 months.

So in terms of productivity, our planning discussions were more productive because we were not bogged down at the pixel level. But in terms of turning the Balsamiq Mockups into production code—that was not really our intent, nor does the tool really support that.

Anybody else have a perspective to share on this or other rapid prototyping tools?

posted by ted on Thursday, Jul 02, 2009 · 1 comment

“This feature provides the customer with a considerable length of hanging rope and foot-loving ammo.”
Team member, summarizing decisions in a meeting where a potentially dangerous feature request was discussed

posted by ted on Friday, Nov 30, 2007

“One of the great things about agile is that it seems to get developers “hooked” on having impact on people, as opposed to being hooked on writing “cool” and fun to write code.”
Alain Desilets, via the “Agile-Usability” group on Yahoo

posted by ted on Monday, Feb 19, 2007

Spool on Five Usability Challenges of Web-Based Applications . The case study (Facebook.com) is as interesting as the challenges Spool identifies, which are Scalability, Visual Design, Comprehension, Interactivity, and Change Management.

posted by ted on Tuesday, Nov 07, 2006