Thanks for all the replies.
So the majority seem to favour approach A and iterative development.
Question though, doesnt iterative mean you are building towards a production app?
Meaning the prototype would constantly get refactored and eventually become the production app.
As opposed to a protoype that is done real fast and then the production app is started from scratch (i.e none of the code is re-used , but you gain all the UI design, usability and input from domain experts experience from the prototype design phase)
Also, having just been through an iterative process for a Flex project, some questions :
How do you manage constant change in iterative development ?
Especially when you start without signed off comps/wireframes ?
Also, what about where you have very custom designs (using skins , transitions etc, custom display mechanisms), does that not add extra dev time trying to do it in Flex at the prototype stage (as opposed to a quick mockup in Flash say for
e.g or a Photoshop comp)
And in the process that Dave calls LookFirst, do you ever run into issues, where once the UI is done and decided on, the nature of the data in the data store (as decided by the business logicl) proves inefficient for display process. (might have been fine using static dummy data, but when the real-life data comes along...things prove too convoluted)
Once again thanks for all the comments.
Very useful. Just trying to get a better handle on how to plan out larger Flex projects.
- superabe
On 11/4/05, Dave Wolf <[EMAIL PROTECTED]> wrote:
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/
--
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
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
