Constraints, friend or foe?

I’ve seen several places that sing the praises of building something under some kind of constraint, including this article at the always excellent Creaating Passionate Users blog. Checking out everyone’s projects in the “lab” session of my class reminded me of this.

The assignment was to build two version of a weather forecast reading tool for a hypothetical phone – one really basic, the other with some better automation features. One just had to be able to enter a zip code and click through seven days of weather. There weren’t many details given, and no requirement on the type of implementation (this is an engineering psychology class so there are lots of non-programmers).

I looked at the assignment and saw the requirement to type in a zip code and immediately discarded the idea of using powerpoint, reasoning that powerpoint faking of entering text via phone button pushes would require hundreds of slides. So I moved to flash; which was good practice, and I got to test out an open source framework in the process (ASAP Framework). The majority of the class turned in perfectly adequate workflow prototypes in powerpoint. How did they do that?

They embraced constraints.

Key constraint: entering an arbitrary zip code isn’t the point because we’re not really finding the weather. This simplifies things tremendously, and I can’t believe that didn’t occur to me. The power point projects only allowed one zip code to be entered (ie the “3” button was the only link active on one slide which would link to the next slide that would show a three entered) which was fine because the usability test task could be given as “find the weather for zipcode 12345”.

Embracing that constraint reduces the complexity tremendously and allowed people to concentrate on the work flow (and in some cases beauty) of their apps, while I was futzing around with flash. I’m able to (and indeed prefer) to prototype in tools more powerful than Powerpoint, so I immediately brought the big guns to bear, never having paused to think about the tradeoffs one might make at little cost to make it possible to do a reasonable fidelity prototype in powerpoint.

I do find building these prototypes in powerpoint incredibly tedious because of the drudgery involved in creating hyperlinks between all the frames as compared to writing some scripts. Good programmers are “lazy” in that they’d rather take time to automate something than do a task manually, but there’s obviously got to be a repetition threshold under which it would actually be faster to do the work manually than invest more time in building a more robust, automated solution. This project probably fell on the keep it manual side of that line.

At least my on screen cursor eased in and out of position. Can’t do that in powerpoint! (or can you?)