Hi,
Does the idea of UI Driven Development make sense at all? Most of our clients like to convey their requirements in form of screens. For e.g. I want a screen to do THIS and THAT. Sometimes they even go as far as to dictate the layout of a screen by themselves (this may be because clients of today use software applications for most of their tasks already).
Also this method of requirement gathering seems to convey both the Data and Associated Behavior automatically.
What do you guys think?
I think what you are really talking about here are use cases - see this article for an intro.
Story Test Driven Development I think is quite a good idea as long as you take the automation part of it seriously. If you can't automate your tests then you're in trouble. Check out a paper on it here: http://www.industriallogic.com/papers/storytest.pdf It doesn't sound like your clients are giving you automated UI tests but I think that's the best way to go.
I find this is a reasonable way to gather requirements. I'd be careful actually building the screen and then developing functionality off that direct. You will find code reuse is low and you'll have a pretty looking app that's slow or doesn't work exactly right. It will work on some projects and not others depending on how complex the requirements and how good at foreseeing problems such as data bottlenecks, caching issues etc.
It sounds like it's similar to behaviour driven development, wireframing and user stories.
Actually it does make sense in this regard. Use cases differ here in that they cannot be used in the same way. Use cases will be usefull to extract and formalize requirements.
I was workinng in a UI lab a while back and we toyed with this concept, though we did not call it as such. Basic idea here is that we would use agile iterative approach to development where we would use usability tesing to help converge on a desired solution.
Typical cycle would be :
This method was perticularely usefull when the users would either not know exactly what they wanted or could not tell us. We would therefore have to devise tests that would gather objective data on the actuall usefulness of the software to the user and try to ajust the next iteration consequently. (many of our "customers" if I may call them so were heavily handicapped and could not talk so we had to be creative).
This way of working forced us to have a GUI available to the client very early in the software's development life and because it was the central point where we would direct testing one could say it was GUI driven desing since the driving force for convergence was the user interactions with the system.
Although we developped this technique mostly for very specific cases we did some testing with normal users on a normal software and got very positive results. The desing would converge very quickly towards the usre's needs. Also the fact that they participated in this desing approach had also very positive effects on the acceptance of the product in the target community.
Unfortunately internal strifes had the lab dismanteled before we could publish our results and expand this line of research, a shame really.
So UIDD (if you pardon the bad acronym) would be a member of the TDD family of approaches towards software development where the iterations hinges around user interactions.
Additionnal reading on the subject :
http://www.codinghorror.com/blog/archives/001091.html
http://cakebaker.42dh.com/2007/07/07/usability-driven-development/
http://www.springerlink.com/content/l413k76812896gnt/
http://www.agilemodeling.com/essays/agileUsability.htm
http://www.uxbooth.com/blog/how-test-driven-development-increases-overall-usability/
what kind of development are you doing? When i develop web apps (flex or php) I work with drawings (wireframes) so I can get the client to know the flow/look of the app without writing any code.
There is no "right way to develop" for everyone , you just need to find the way that works the best for you. cheers!