Absolutely right (Anatole has a very good enterprise development background and it shows). You cannot forget about good DB design and that design should happen in tandem with the UI wireframing and development. As I think I mentioned one of the outputs of a Model & Design in LookFirst is a complete data model (along with a project plan, test plan, functional spec, etc). This is one of the places where the dog wags the tail and the tail wags the dog. The UI can help to expose relationships between data elements and can help assure they are all present. The data model however has its own requirements in terms of normality, performance, and just general good design.
I also think you hit the nail on the head 100% with the realization that to build a good and serious Flex application you are going to want to partner with serious J2EE developers who know the enterprise and know what building a scalable distributed SBA is all about. This has been a very good thread driven by some very good very experienced folks. -- Dave Wolf Cynergy Systems, Inc. Macromedia Flex Alliance Partner http://www.cynergysystems.com Email: [EMAIL PROTECTED] Office: 866-CYNERGY --- In [email protected], superabe superabe <[EMAIL PROTECTED]> wrote: > > Thanks all for taking time to detail out the issues. > Lots of good info to digest, and research. > I especially get Anatole last point about remembering to focus on DB design > as well in the early stages. > I think that is as important to nail down initially as it is to get the > application look and feel, and in most cases affect how the application look > and feel can be achieved. > I think I need to get on a team that has some experienced Java Enterprise > Devs ! ! > - superabe > On 11/5/05, Anatole Tartakovsky <[EMAIL PROTECTED]> wrote: > > > > superabe, > > If I may, I would like to suggest the environment I like to use. Most of > > the applications I have been working with had to do very few things - > > database access ( read and update), navigation and reporting. There are fun > > parts here and there but I like to keep them to myself so it is not > > completely boring. > > How would you go about developing and maintaining ever evolving codebase > > with a lot of repetitve "utility" fuctionality driven by trial and error > > design process? You do not write application code till the very end. Instead > > you build or get automation tools that allow you to prototype data access, > > navigation and reporting - and use it in production later on. > > Let me illustrate. I need to be able to maintain customer info - let us > > say it is trivial "select * from customer where id=?". I can write regular > > Java code to do all retieve, update, insert and delete methods - all 500 > > lines of it actuall - by hand. I would also need to create value object to > > hold the data and maintain that as the DB expands. not to forget - need to > > create model objects coming in and out, bind, and work through the changes > > with code that would be able to figure out what user did and submit one of > > those methods. Do fine stuff (validation and formatting), debug protocol > > with server as some undefined/null value would blow it randomly, and have > > part of weekend free before the inevitable changes will start flowing in. > > Alernatively I can use Doclets to process some comments embedded in my > > java interface and generate the following : > > 1. All Java code > > 2. All synchronized value objects - java and AS > > 3. Forms and grids and master details screens along with > > Formatters/validators - can use to cut and paste those > > Add a set of high level objects like Foms and DataProviders that > > automatically keep state/track changes and have retrieve/update API > > embedded, transactions, progressmeters, and othe high-level objects you need > > in any app - and you can cut-and-paste your wireframes from those resources > > much easier then BAs can move Visio shapes. Best thing you can tell users > > "now I need to work on making it working" and take really nice vacation. > > Now the change comes - they added a field. Time to regen - that takes > > care of Java and VO, You will need to cut-and-paste new field in "prototype" > > - but hopefully, thats it. > > OK, they want something drastic - database driven comboboxes, expandable > > treeviews, you name it. Take a deep breath and look around. DO NOT MAKE > > APPLICATION SPECIFIC CODE. Chances are you might need database driven > > combobox somewhere else! Rather, create object that you can use across the > > screens, think hard about caching, read about problems with "prompt" and > > "value" properties, prepare yourself for those wireframe meetings. Make a > > management decision if you want to make that generic object upfront or you > > want to "hardcode" it during session and get the scope on functionality it > > has to support. > > It is true that "generalized" code takes 3 times longer to write. It is > > also true that on average you will be able in more then 3 occasions. The > > "next best" productivity method (some call it cut and paste) is guaranteed > > to turn the project in development nightmare even before it goes into > > maintenance. > > Here is the ultimate goal for the "perfect" maintainable application - > > it has to have very little code. It has to use as much as possible of > > pre-tested, reviewed consistent objects instead. > > During design/wireframe stages try to concentrate on database design, > > usability and identifying objects/supporting tools. > > HTH, > > Anatole Tartakovsky > > ----- Original Message ----- > > > > *From:* JesterXL <[EMAIL PROTECTED]> > > *To:* [email protected] > > *Sent:* Friday, November 04, 2005 9:27 PM > > *Subject:* Re: [flexcoders] Re: Flex prototype - production approach > > > > Absolutely! 9 out of 10 times I'm building, & re-factoring production > > code as I go. > > I think the important thing to note here is the purpose of milestones via > > iterations is to get a build done, working, and testable by a real user, not > > just a developer. This garners relevant feedback, the kind that promotes > > work to be focused on the 80% of the app that matters. Additionally, this > > gives you a chance to challenge the wireframes, the information architect's > > work, and/or the designers. You constantly have proof of improvement, > > recognizable & documentable milestones, and a sense of accomplishment that > > actually has meaning. Working towards meeting the users' needs, and making > > progress doing it is a lot more relevant to a project's success than working > > towards the developer feeling comfortable with his architecture and showing > > progress doing it. Just because I love my implementation of MVC in the app > > means jack of the app doesn't work for the user. > > Now you can see how my view of commenting code & using tools like ASDoc > > is slanted; I'm too busy improving & changing the design as I go to ever > > really get to the point where the app is so stale it needs to be documented. > > Why spend time on it if you are possibly going to change it? It's wasted > > effort. > > Change? Having View's that aren't tied to the Model and emit useful > > events. Having, as Steven has said in the passed, Commands (chunks of > > controller code) that actually map to user cases; they do something the user > > would do like "open a document", "save a record", etc. Doing your best to > > use MVC & frameworks like Cairngorm and ARP allow things to be extremely > > flexible. Most of my changes come from design, not from business process, so > > most of the time it's pretty easy, like moving some MXML around, or deleting > > it entirely and just using code. Other times, the actual logic changes, and > > I have to sometimes move code around, etc. Again, modularizing techniques > > keep this to a minimum; meaning you are most of the time creating & > > modifying vs. destroying what you created. > > The phrase "signed off" to me sounds like the contracting advice I see > > thrown around the lists. I admittingly do not understand their pain. I > > recognize that they are trying to protect themselves, as their stories of > > past problem jobs are telling, but I've never had that experience. > > Additionally, and more telling, I've never had a wireframe that was rock > > solid. While I do hate doing wireframe changes 6 weeks into a project, I'd > > rather be doing that then following a failed cause. > > So, to me, signing off on a wireframe sounds like a death warrant... but > > I never deal with those sides of the project; my managers, designers, or > > sales dudes do. > > Yes, skins add considerable time, but one must understand that a designer > > developing a rich app is creating, hopefully more often than not, something > > extremely brandable and compelling compared to the simplisitic nature of web > > page designs, which have to be created that way to fit into the HTML/CSS > > paradigm. Those boundaries to design do not exist in Flex since the sky's > > the limit, so it's actually time well spent; time you couldn't do at all in > > HTML development. On the flipside, I've seen web designers take weeks to get > > a design to work on a website... and one I wasn't really impressed with at > > all. Spending 6 hours on getting a margin to work seems a lot less valuable > > to me than spending 6 hours implementing a phat PSD into PNG parts for use > > in skinning Flex components. > > Flex, and Flash, both are still evolving. Although we've had years, and > > one can go on Google and find thousands of components that are free, there > > isn't a lot of cream in the crop. QA is a nightmare because some were > > written for Flash 4 before ActionScript existed, some are AS1, and the > > majority are tied to FLA's in some way. A lot of time in Flex is spend > > custom components for a specific job, yes. But, it's worth it; you build up > > an impressive reproitoire of components in the long run. > > JavaScript has definately got us on that front with the options of > > frameworks out there, both commercial and non. But... they are about AS1, > > and don't look as cool as ours! > > Remember; an app can look good and not work as well, but still sell > > better than one that does. > > ...data... hrm... tough. Usually, I've found the backend guys I've worked > > with follow this pattern: > > - in the beginning, they know everything, and spell out the data model to > > me, and involve me in business logic discussions to see what I can handle on > > the client; I in turn push as much as I can their way > > - in the middle, I work like mad, and get feedback on how I'm doing from > > them, and ask questions > > - I reach one of my later milestones, and am ready for real data; at this > > point, I start breaking the hell out of their back-end services. So, getting > > relevant data takes a few days > > - once I get the data, I recognize problems with it (usually associated > > with OpenAMF; .NET and real Flash Remoting installs I rarely have this > > problem) and either ask for changes that they usually consider extremely > > minor, or slightly massage to what my component wants (in a ViewHelper for > > example). > > - at that, point, I'm finishing business logic, wrapping things up, and in > > the end I'm waiting on the back-end guys to fix bugs so I can re-test my > > front-end for the 50th billion time. > > That's pretty much stayed true every project involing serious back-ends. > > I've always tried to utilize dummy data early on and get confirmation from > > the back-end guys on what I'm getting, so I havne't run into the problem you > > are describing. > > ----- Original Message ----- *From:* superabe superabe<[EMAIL PROTECTED]> > > *To:* [email protected] > > *Sent:* Friday, November 04, 2005 8:26 PM > > *Subject:* Re: [flexcoders] Re: Flex prototype - production approach > > > > 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. > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > 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<http://groups.yahoo.com/gads?t=ms&k=Web+site+design+development&w1=Web+site+design+development&w2=Software+design+and+development&w3=Macromedia+flex&w4=Software+development+best+practice&c=4&s=131&.sig=FkTWphZzV9mFulU7V3u7pQ> Software > > design and development<http://groups.yahoo.com/gads?t=ms&k=Software+design+and+development&w1=Web+site+design+development&w2=Software+design+and+development&w3=Macromedia+flex&w4=Software+development+best+practice&c=4&s=131&.sig=w0jnvy4gyxC04c4dhRnw6A> Macromedia > > flex<http://groups.yahoo.com/gads?t=ms&k=Macromedia+flex&w1=Web+site+design+development&w2=Software+design+and+development&w3=Macromedia+flex&w4=Software+development+best+practice&c=4&s=131&.sig=XXu7YeegB3Vi-5Qngf6oNQ> Software > > development best practice<http://groups.yahoo.com/gads?t=ms&k=Software+development+best+practice&w1=Web+site+design+development&w2=Software+design+and+development&w3=Macromedia+flex&w4=Software+development+best+practice&c=4&s=131&.sig=ZT_U6e_iPgXSriY_dI9nIg> > > ------------------------------ > > YAHOO! GROUPS LINKS > > > > > > - Visit your group "flexcoders<http://groups.yahoo.com/group/flexcoders>" > > on the web. > > - To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED]<[EMAIL PROTECTED]> > > - Your use of Yahoo! Groups is subject to the Yahoo! Terms of > > Service <http://docs.yahoo.com/info/terms/>. > > > > > > ------------------------------ > > > > > ------------------------ 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/
