Users know interfaces.

That's usually the depth of their knowledge about applications.

They don't care about an elegant OOP framework. beautifully clean CSS. or a really hacky-kludgy middleware tier to your ERP system. If it looks pretty and works as expected. they're happy.

I'm sure we're all pretty much in agreement that this is how things work. Of course. in the ideal world we could describe an application in text. everybody signs off on it. then we start implementing.

And then the first demo rolls around. Users get hung up on something like "but i wanted that button over *there*" instead of "when i put a lot of text in this textarea. it's truncated when saved". Useless feedback to the programmer. but apparently it means the world to John Q. User.

They never see the big picture. because their "big picture" only extends as far as the pixels on the screen.

So that being said. we should probably spend more time wireframing the layout and process flow in a "clickable" format than we usually do.

I'm trying this approach now with a project. So far. it's great. I'm using Mach-ii for the app implementation so to do the wireframe. all i'm doing is creating events and views. No data. no model. not a single bit of "real" work is being done.

My client gets a demo that they can click through and think about. I can change stuff REALLY fast. and in the end the app implementation phase is just creating the CFCs to do all the data handling throughout the application. We can talk about clickpaths and process flow together while actually doing it instead of negotiating a flowchart.

It feels almost too easy to be right. But at the same time. i've never had a framework that allowed me to do a clickable model that would require so few changes to use in the real implementation.

They're thrilled to have something they can touch so quickly. I'm happy because my time hasn't been wasted. Sounds like a good project to me!