Prototyping

Ive been working on some new functionality the past couple weeks, which is nice, since it has been awhile since our project has seen any new functionality. We used to use a process called FLIP, that Hal helms and Jeff Peters worked up awhile back, but the people, including the customers who were involved in this are gone, so i ended up thinking hard about what parts of that process worked and what parts could be left out. A re-cap of that analysis follows.

What works

Front end development first. That's a fine principle to follow while building new functionality. What is the new stuff supposed to be doing? How should it do it, what should the interface look like, what kind of functionalily should be present. All these things help the customer to see things that they are trying to describe. Put something in front of them and let them see it in context of the system where it will be used. I even heard one of my customers say "now that i can see it in place" the other day, more on that in a moment.

Don't think implementation, at least not the database or model domain. Anther one of our developers at the presentation was asking questions about implementation. This was the initial design and presenation of the design, there should be ZERO talk of implmentation. We are focusing on what they client wants!

Keep it light - do not attach the prototype to any real datam, fake it. Hard code stuff in view pages, do not query or instantiate objects in any way in the prototype. When i could myself starting to think these things, i kicked myself. This payed off immediately, since some of what i was prototyping was not needed, at least at this point.
Get it in front of the client, expect multiple iterations before they say "thats it". Make sure that you get the people who are interested or who should have a say involved early. I need to do that now. One of my customers was not present at the meeting. I need to get his input sooner than later.

I am prototyping the new code in the actual application, which required me to do a bit more work, that if i used the prototype toolkit that we used to use. But its work it.

Elicit feedback. In our previous prototyping cycles, we used a toolkit that allowed users to login and leave comments on each view page. That was moderatetly useful. Some of the customers understood what we were trying to do, but others did not get it and it was alot of work and a hassle. The prototype toolkit would get in the way of what they were trying to do and confuse things. They would leave comments on the wrong pages or the login would fail or something would go wrong.

Now, i am putting the new code in the actual application on my localhost and showing it to the group. My next step will be to put the revised content on our test server and give another presentation. The feedback, which is so important will be handled via email via me asserting things back to them and them clarifying. This is not perfect either, but is the way i am approaching.

I am thinking some implementation. The new functionality is a calendar that is showing release dates of critical information in our application. Naturally, AJAX comes to mind, since i do not want to have to reload the application every time the user clicks a new month or year. We just want to drill down into the data and update the calendar without reloading the application. Im thinking this, but not implementing, since i am not doing any drilling into the domain at this point. My prototype is using some javascript to automatically update the calendar when a select box is changed or a pre / next link is clicked, but no real AJAX yet.

I want to be sure the customer says, "that's it for the initial release of the calendar functionality". Then we can freeze things and i can implement the AJAX and other domain code.