Deadly Gui Prototypes

I used to think it was a good idea to explore requirements by mocking up a GUI, using those quick and easy GUI tools. But then I realized that however many times you tell the user that it's only a prototype, it is difficult to realize that there is so much work to do behind the scenes. Thus showing a mock GUI gives a FalseSenseOfProgress, which usually leads to disaster.

So if you need to prototype a GUI, don't do it with a tool, just sketch it on paper.

-- MartinFowler

Sorry to disagree, oh great scribe. Automation and tools are my friend. HTML and JavaScript fall into that category. When I want to put together a quick demo of appearance I can use a laptop and a browser to make do. What proposition are you disagreeing with, that it's hard to make high-quality demo screens or that high-quality demo screens create a FalseSenseOfProgress?

--

Don't do it with GUI tool - use something that produces equivalents of paper sketches, e.g. MockupScreens. It's far more productive anyway.

The FalseSenseOfProgress results in a very deleterious pattern which I call WizardsAreLazy. The problem is not with the GUI Prototypes, which are great, it is with the fact that managers are often ignorant of the underlying technology and interpret the prototype as a nearly finished application that was developed in almost no time at all. This clearly means that programmers are much more productive than they let on - and then the only explanation for the fact that projects are late is that the Wizards Are Lazy.

I have seen this pattern time and time again. It is especially a problem with young programmers who think that they will impress the boss by doing a really good GUI Prototype - all they usually achieve is the conviction on the part of the boss that they are really more capable than they are and this produces unreasonable schedule demands. -- RaySchneider

An antidote for this might be that common Managerial Misconception - that we programmers have deliberately added delay loops to our code to slow things down, and when the poor performance is complained about, we delete the delay loops to get a quick and easy 50% performance improvement. In the case of a Prototype GUI, do exactly that - put delays in it at every interface (DB, disk, server, etc). Make it sort in the (obviously) wrong order. Have it reverse the bytes in data from other systems. Have funny, non-professional error messages. In short, do everything to make sure that nobody will want to run the prototype as a product, but do it in ways that can be easily removed in the finished product. -- PeteHardie

IMO, that's quite a dangerous suggestion. In my experience, that kind of silly hackery is just the kind of thing that gets forgotten about and turns into the real thing at some point. Just like the way every "This product has expired" time-bomb I've ever come across has bitten the developers at some point. -- AnAspirant

I second that. I have heard about some nasty stories of "toy" error messages and button labels slipping through.

It allows you to make certain that the prototype is not mistaken for the product - which is the problem. Toy error messages are a different problem, which occur even in regular programs (usually when the real error text is to be provided later) --PeteHardie

Another antidote is make your prototype with the real stuff that will be used for the final product. Then you don't get any FalseSenseOfProgress, just a real feel for how much work you have left and how long it will take. -- ScottJohnston

I have been kicking around similar ideas. I ask the question, "Why can't I just incrementally improve my prototype rather than start from scratch? I don't see any law of nature which forces one to have to start from scratch. The solution may be to make the GUI be meta-data instead of tied to one particular language. That way, the best GUI RAD tools can be best of breed instead of say "those that Sun Microsystems gives you with the language". (see TooMuchGuiCode and DataDictionary)

That's why I try to work in Delphi / Kylix where possible, I have never understood these teams that do a prototype in VB then rewrite it in VC++ for the release version

A guy once told me he puts a "crash feature" into every prototype, like a "known bad" value for a text field that leads to a spectacular crash. Key is that he knows where these are, so the prototype only crashes if and when he wants it to, not at inconvenient moments.

It's called "Install Windows".

TryLikePages

CategoryGui