We feel very strongly about this subject. We developed all our Flex/RIA solutions so far using a "front to back" approach. Effectively we do what we call a Model & Design phase where we develop out the entire UI in Flex. In the past we would call this "wire framing" and would use static images to represent the UI. Witht he productivity of Flex we now just do it right in Flex. We work hand in hand with the domain experts to layout and develop every screen in the application. Once that is done, in the next phase we bind static data to the UI, implement validations and flow and actions. Finally using the domain knowldge we got from the M&D the back-ends are developed and finally integrated into the UI.
This approach has tons of advantages but the biggest being this. JAD sessions are *boring*. Business domain experts get very bored very quickly looking at data models, object models, functional specs etc. Well as they get bored, they stop caring. So when you ask "Can we just skip field X here" they just go "Yup". Now you do the back-end, the API's build out the UI without field X. Wanna guess what happens? Yep, they tell you X is missing and the app is flawed because of it. Now you have to layer fixes into three to four layers of the application. Add the field to the data store, add it to the persistance layer, add it to the API, add it to the UI, etc. Domain users are *a lot* more likely to stay engaged in the user experience. Then you use those lessons learned to drive back at the enterprise tier. We've coined this approach as LookFirst(tm) and use it pretty much religously. There are other side benefits like the app is demonstrable before its finished, blah blah. We actually sell an offering to our clients for the M&D itself. Includes all the screens, data model, project plan, test plan, etc. Its been very successful. I would vote for a LookFirst like front to back approach. -- Dave Wolf Cynergy Systems, Inc. Macromedia Flex Alliance Partner http://www.cynergysystems.com Email: [EMAIL PROTECTED] Office: 866-CYNERGY --- In [email protected], "JesterXL" <[EMAIL PROTECTED]> wrote: > > Jesse Warden does A, Darron Schall does B (I would think). > > I like to build stuff quickly, ironing out the weird, diffucult things, and just continually kneed the mofo like dough, improving, and releaseing working builds to prove progress. Sometimes, you realize a re-write is best, and you can re-use some functions and assets, but not much (which is why I call it a re-write). Since Flash & Flex make that sooo fast, you do that about 3 times. > > I've done B, but that sucks. I hate UML, as long as you have an awesome Information Architect, who cares; take the wireframes, and go; then iterate when you can show a build, and double-check your assumptions about both the wireframes & the implementation. > > To me, B works in better in a team, and I've had success working with others, but the pressure at the forefront to "plan it perfectly" seems like I'm being setup to fail, and when the transition from prototype to production comes; it feels cheap because the code itself wasn't really a prototype; it was a planned production piece from the get go. > > Obviously, I'm leaving out all of the important factors that affect the above such as investment, leeway, deadlines, # team members, accountability, aptitude, experience, etc. but bottom line, I dig A. The only really big thing about A is deadline; you're emotional attachment to building re-usable code should be inversely proportional to the amount of time you have left. So, if you have a week, don't care about it. If you have a month, definately. Obviously, I'm implying scope here, but you get the gist. > > > ----- Original Message ----- > From: superabe superabe > To: [email protected] > Sent: Friday, November 04, 2005 5:19 AM > Subject: [flexcoders] Flex prototype - production approach > > > Just curious about what folks here on the list think / have experienced about the prototype based approach to RIA developemnt with Flex. > > Am evaluting a potential project that needs to be prototyped first and eventually built using Flex, and trying to decide what to use for prototyping and how much of the prototype can be re-used in the final app. > > The two options I see, are : > > A. do a quick prototype in Flex or Flash for the purposes of feature gathering / usbility. The start the production app from scratch in Flex. > > B. Do a more planned out / better architected prototype in Flex , that can be re-used substantially towards the production app. > > Am interested to know what pros' and cons people have faced with both approaches. > TIA > > - superabe > > > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > > > > SPONSORED LINKS Web site design development Software design and development Macromedia flex > Software development best practice > > > -------------------------------------------------------------------------------- > YAHOO! GROUPS LINKS > > a.. Visit your group "flexcoders" on the web. > > b.. To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > -------------------------------------------------------------------------------- > ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM --------------------------------------------------------------------~-> -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
