Summary

Creating Prototypes get easier with the evolvement of visual programming environments. But instead of showing that the product is really implementable they are only an empty hull, proofing nothing. This is because one can now create a nice user interface without implementing, or even knowing how to implement, the code behind the user interface.

Best Things

Customers often think just because the user interface is ready and good looking there is no or only little effort left for the code behind the scenes that can't be seen. The author extends this misunderstanding to designers and developers, that something is not working only because the prototype is.

Since the author is directly attacking the statements of Rudd, Stern and Isensee it is very fair to include their response in the article.

Improvements

The joke goes that "a program should be hard to use, because it was hard to write it." It seems like that Berghel want to extend this to "the user interface should be hard to write, because the business logic is." Since good user interfaces take up large portions of the code one should be happy that there are generators that can help. Also, good interface designers are not always good coders and may not always be able to express their good ideas in old-fashioned programming environments.

Berghel seems to say that "vacuous" prototyping is something bad and should be avoided. But a prototype is good if it serves it's purpose, and if the purpose is to show how the user interface looks like than it is good. But the developers should keep in mind that this prototype is just for showing the user interface and for nothing else. It is just like as if you start arguing about the user interface of a prototype that's single purpose is to show the data transfer performance, and nothing else.

Question to Author

How would you design a user interface when a full blown prototype is not feasible?

Article Questions

1. Why and when are vacuous protoypes dangerous?

2. What is the difference between visual programming environments and visual programming languages?

My Opinion

The article is easily understandable. But Berghel seems to make the same mistake as the author he attacks [1]. He seems to be a developer that fears that someone else, knowledgeable in user interface design but not coding, will take over this part of his job, or put him into troubles by creating something that is hard to implement.

If the final product is build upon the prototype, taking over the code of good interface designers but not coders is a pain, but the final product may be worth it.