LoveCycle?

[HyperVista]

I was wondering if it was customary for every experienced developer here, to begin their work in LCD in utter fits of rage, frustration, and despair at the sheer and utter stupidity of LiveCycle Designer.  Do you ever manage to control these feelings with time?

I didn't think I'd ever see this.  Indeed, this is one of those rare instances where -- while idiots always blame the system -- LiveCycle Designer is a system  that truly deserves blame. Software like this, coming out of a company the size of Adobe -- especially in this day and age -- is absolutely shocking.  It's a shocking documentary on the state of American business, and probably education, in a high-tech field no less, that truly makes me concerned.  And it also makes me concerned that the U.S. government is relying on this stuff.

Since I have not abandoned logic, though LiveCycle should try to convince me otherwise, I can only deduce that Adobe is another word for Chaos.  It's a rare display.  ADBE market insiders might jot a note here.

Evidently, abandoned first, is good management that prevents garbage from floating up to the top, let alone be disseminated. There indeed appears to be no management, no business process, no metrics, no quality assurance, no market research, and no backbone.  Certainly no connection to reality.  Is anyone educated?  Hint: if you make good products, you tend to make money.

LiveCycle is badly architected to a surprising degree.  I can almost sympathize with Microsoft's GPF blue screens compared to this.

1) Knowledge of the forms process, by default, is completely lacking at the highest level.  Validation is not even a bad joke.  It just isn't. Who could ever develop such a laissez-faire approach without fear of being fired or laughed out of the room.  Fields should be corrected at time of entry if at all possible. Not just to encourage Submit and then the user gets a bad surprise.  You already have all this information, why not build a *separate* automatic built-in validation process button, field-flow-management, a top or side panel of errant/todo fields with commentary that could let the user focus on the fields they have the information for, representing "forms as a work in progress", including save draft.  Also, are you kidding, using PIC formats that pre-date COBOL, instead of regular expressions or just plain algorithms with powerful add-on functions. 

2) FormCalc should never have been developed and has resulted in yet another bloated Adobe product.  Javascript with object models is fine.  Make your own prototype.js if you have to.  The event model is lacking also.  Make a general state machine, where fields can source and sink their own events to keep logic simpler.  Make a proper object model.  Make it state-persistable as XML.  Know what needs to be done.

3) The Java platform has not matured from pcode to machine code due to ideologues/zealots;  the performance penalty is unacceptable.

4) The underlying XML looks pretty terrible.  Do you obfuscate for a profession?  A simpler format would be easier to interface with, and provide transparency for other programs and be less error prone.

5) There's a zillion other problems, not half of them will be documented in these forums.

To Adobe:  I do not appreciate the time and money you have wasted on the part of developers working for companies and organizations -- small and large -- around the world, including our federal government, due to such abysmal design.  Shame on you.  Get to work.  Clean house.

[Former Community Member]

It appears you've posted this right after getting frustrated by the program.

I do agree with the essence of what you write concerning documentation and the overall "working" of the program which from time to time really makes one want to smash things. On the other hand, this still is the only suite that provides the ability to design pdfs and generate them using only a few simple steps.

On the other hand you're overreacting bigtime

[RobMcDougall]

Hyperbole aside, from the points you raise it's clear you're a developer who is looking at Designer through a programmer's lens.  Designer was created to try and make the simple stuff simple and the hard stuff possible.  It is intended to be used by two types of users - developers (for the hard stuff) and form authors (for the simple stuff).  It also tries to shift as much as it can from the "hard stuff" basket into the "easy stuff" basket.  No matter how easy you try to make it though, some stuff  just remains hard.  That's just reality.

The stuff you primarily complain about (PIC formats, FormCalc, etc.) are targeted at form authors.  If Designer used them, then there would be form authors on here griping about the cryptic nature of regular expressions as well as pining for something easier and less verbose than JavaScript.

Try taking your programmer hat off and pretending you’re a form author.  Imagine someone capable of creating MS-Office macros but with no formal training in programming.  To them, PIC format and FormCalc are an attractive and simpler option.

Another gripe you have is that “Fields should be corrected at time of entry if at all possible.”.  This is something I agree with however technically it’s not Designer’s fault, it’s Reader’s fault.  Designer just specifies the validation rule, it’s up to the fill engine to apply those rules.  Ideally, the fill engine would warn the user when they attempt to leave a field that is invalid however it would be wrong for the fill engine to prevent the user from leaving the field since, in order to correct the problem a user might need to adjust the value of another field besides the one they’re actually leaving.

“why not build a *separate* automatic built-in validation process button, field-flow-management, a top or side panel of errant/todo fields with commentary that could let the user focus on the fields they have the information for, representing "forms as a work in progress", including save draft.”  Once again, you’re complaining about a Reader problem, not Designer.  Personally, I think this would be a great idea, however it would also require a major overhaul to the Reader UI with a lot of form specific code.  I don’t get the feeling that forms are important enough to the Reader team to make that kind of investment.

“The Java platform has not matured from pcode to machine code due to ideologues/zealots;  the performance penalty is unacceptable”.  You seem to be in the minority here.   Even MS is moving to pcode, or “managed code” in MS-speak.  If you look into it, I believe you’ll find that with modern JIT compilers – pcode is almost as fast (and sometimes faster) than compiled code.  I don’t believe there’s much of a performance penalty today.

“The underlying XML looks pretty terrible.  … A simpler format would be easier to interface with, and provide transparency for other programs and be less error prone.”  This is like saying, “Relativity is very complicated.  A simpler model would be easier to understand”.  Unfortunately, you cannot build a simple model of a complicated thing.  In real life applications, forms are much more complicated than one would think.    I was actually involved in the design of the XML format (XFA) so I can say that one of our prime goals was to make XFA as simple as possible (but no simpler J).  If you know the format, you can hand code a form.  The format is as simple as it can be without losing functionality that the LiveCycle products require in real-life situations.  It’s unfortunate that it’s difficult for a novice to pick up however that’s not for lack of trying.  The simple fact is that real-life forms are complicated, and the format sometimes reflects this.

It’s unfortunate that the product has left you with a bad taste in your mouth, but I don’t believe it’s because the product is as bad as you believe.  I just think you may not be seeing the bigger picture.

Regards,

Rob

[Former Community Member]

First, disclosure: I'm ex-Adobe, and ex-JetForm. There are parts of me in LiveCycle Designer and in the underlying markup language. On that basis, feel free to entirely discount my comments entirely if you wish. But understand that, like you, I now use LiveCycle Designer and experience it from a user's perspective daily, as part of how I make my livelihood.

Designer is not a single-purpose tool, and given the range of functionality it needs to cover, from the simple one-page form to a complex dynamic form that interacts with other data-sources, it works hard at trying to serve both simple and complex objectives. But, like all software dealing with a complex domain, it is an exercise in trade-offs and compromise.

Designer was not created in a vacuum. It evolved out of many generations of products before it, going back into the realm of 1990, and it incorporates knowledge from real-world experience with those products. On the LiveCycle Designer family tree are ancestors that include products from companies like JetForm and Delrina, as well as the Acrobat forms heritage.

That aside, I have a couple of thoughts on some of some of your specific points:

1. Validation

Not forcing users to fix a field before they can navigate to another field is very much an feature designed into the current product, and not dissimilar from the way common HTML forms work.

Consider this scenario... Years ago I had to regularly use an Acrobat (pre-LiveCycle) form that required me to enter as many line-items as I wanted, the only requirement was that each line item needed to include a percentage weighting, and all the line-items needed to add up to 100% -- it was a quarterly goals form where you choose what percentage weight a particular goal should have.

The Acrobat form enforced validation on a per-field basis. So, I'd enter a few goal line-items, and they'd add up to 100%. Cool. Then I'd think of another goal I'd want to add to the form, but I've already entered goals that add up to 100%. So, I'd go an add another line-item, type in the description of the goal, and maybe give it a weight of 20%, intending to go and adjust one of the other goals down by 20%.

But, would this form allow me to type in my new goal with a 20% weight? No, because that would cause the weights to sum up to 120%, and the validation error wouldn't let me out of the percentage field until I had satisfied the 100% rule in the form. Major frustration. Good software gets out of your way and lets you do your work, and these form validations were doing the opposite, presumably to protect me, from me. So, I would work around the validation by putting in 0% weight, go and adjust another goal down by 20%, and then go back and replace the new goal's bogus 0% weight with the 20% I wanted to type in all along. It is silly having to play "fool the form", but that's what I needed to do. Thank heavens the form didn't also have a validation preventing me from leaving a 0% weight in a field, or I would have needed to trash the whole form and start again.

Believe me, I've been exposed to years of users frustrated by form products with "we're keeping you in this field for your own good" validation strategies, and I'm happy that LiveCycle forms don't take this approach.

Your suggestions about helping the user understand their validation errors as they move through the form is very interesting, and it sounds helpful, but doesn't discount the core value of not *forcing* the user to fix intermediate validation errors until they are ready to finish the form.

You've suggested that PIC style formats are old-fashioned and regular expressions are better. They are simply different. Yes, there is a thread of history back to COBOL. Nonetheless, PIC style formatting remains available in spreadsheet products, and it is a simple and expressive way of describing common patterns without having to be versed in regular expressions. Regex is more powerful, no question. But, despite my comfort with regex, I'm happy to use PIC style formatting.

2. FormCalc

I understand that you don't see the value of FormCalc. Thankfully nobody is forcing you to use FormCalc, and Adobe has provided JavaScript as a scripting langauge alternative.

FormCalc or JavaScript? I use both. FormCalc is incredibly expressive for a particular class of tasks. Very often one or two FormCalc expressions can replace many lines of JavaScript code for common tasks such as summing up a series of fields.

Spreadsheets have both formula languages, and scripting languages.  When I use a spreadsheet, do I immediately jump into VBScript to do calculations? No. I use formulas, and then I use a full-blown scripting language when I want to add more advanced automation to the spreadsheet.

LiveCycle forms follow the same approach, providing both a spreadsheet-like formula language, and a scripting language.

3. Java

What would you suggest as an alternative?

There is an entire industry built around Java, because it is mature, cross-platform, and simply does the job better than an un-managed language would.

Some LiveCycle products are Java-based, some are not. LiveCycle Designer is not a Java application, but the Eclipse-based Workbench is. By and large the LiveCycle server products are Java-based because it makes sense from a robustness, cross-platform, and integration point of view. 

In addition to Java, I enjoy working with dynamic languages like Python and Ruby, but their potential advantages over Java isn't performance focused.

4. Markup

I'm betting the super high majority of Designer users never touch the markup, but I do semi-regularly.

For integrators that want to consume or produce the markup, it is documented in several open specifications that include examples.

File formats, and markup langauges, reflect the complexity of what they're trying to achieve, much like the LiveCycle Designer product itself.

I hope that your experience with LiveCycle Designer improves.