Author Archive: Steve Tibbett

Welcome Back

Posted on July 28, 2010 by Steve Tibbett | Comments (0)

I’m actually welcoming myself back – I haven’t posted here in almost a year.  Back when I did post, I was working on LiveCycle Designer.  We shipped LiveCycle Designer ES2, which included the awesome Actions feature, and I did a series of posts on it.

Since then, I’ve moved to another team, working on iStatements.

That link includes a video, which I just saw for the first time.  I don’t know how long it’s been there but it’s pretty good.  If you’re not familiar with eStatements (electronic statements) and iStatements (interactive statements), have a look.

The challenge of iStatements is to help companies provide a better statement experience than receiving statements in the mail (as paper), or receiving an email which contains a non-interactive PDF.  The reason companies want to provide this better experience is to help move customers off of paper statements.

I’ve moved every one of my own bills (the ones I can anyway) can over to paperless billing.  Every company I do business with does it differently.  Some email me plain HTML bills, some email me a link to a bill on the website, and some use a common aggregator service (ePost in my case, since I’m in Canada) and let the aggregator take care of notification.

Some experiences are better than others, but for me, they’re all preferable to paper.  But there’s still so much room for improvement.

Action Builder, Part 3: Results

Posted on August 10, 2009 by Steve Tibbett | Comments (0)

Now that we’ve covered the basics of Action Builder and Conditions, lets take a look at Results.

Once all the conditions of for an Action have been met, all the Results are processed, one after the other in the order they are specified. We’ve tried to add Result types that cover a lot of the script we see in forms, and a lot of the questions we see posted to places like the LiveCycle Designer ES forum.

Here is a list of the Results currently available:

200908251412

Many of these are self-explanatory, but a couple warrant a deeper look.

Set the Value of a Field



You can use this result to set a field to a particular value, or, for some types of fields, to special values. When you choose this result row type, you’re prompted to select an object. The options you get for the value you can assign are based on the type of object, and some of them are particularly useful.

When setting the value of a Numeric field, you can specify a numeric value, but you can also specify that you want the value set to the current page number, or the number of pages in the form. When setting a Date/Time field, you can specify a particular date, or you can specify that you want it set to today’s date.

For a Drop-Down List with values specified, you’re able to select the value from a list:

200908251420

Call a Script Object Function



This is a great way to extend what’s possible with Actions without having to write script. A developer can supply a script object that can be dropped into a form, and then called using the Call a Script Object result.

So let’s say I have a Script Object that translates English text into Pig Latin. I want to make it easy for any form designer to use this script. What do I do?

Make it a Script Fragment. A user can then drag that script fragment into the hierarchy to add it to the form, and reference it from an Action.

Here’s what the Result row looks like for a call into a function called fTranslate in a script object called MyUsefulScripts:

200908251442

The parameters you type in here are passed through to the function verbatim. The result can either be ignored, or assigned to a field. In this case we’re taking the result and assigning it to a text field.

The end result?

200908251439

Without the form designer having to write any script by hand, they can use the script in the Script Object to translate text into pig latin.

Note to self, find more compelling demo…

Action Builder, Part 2: Conditions

Posted on August 7, 2009 by Steve Tibbett | Comments (0)

As we discovered in Part 1, an Action is a list of Conditions, and a list of Results. Lets take a look at the Conditions. What choice are available in a particular condition row depends on the type of object you selected. A new, empty condition row just asks you to pick a node:

200908071315

Click on “(object)” and a dialog appears with a list of all the nodes in the form that support conditions:

200908071316

We saw previously that if you choose a button, you don’t get any further choices:

200908071317

But let’s choose the Decimal Field:

200908071319

Ah, more options. The condition and result rows are designed to read somewhat naturally, so although the spacing is a bit weird, it reads understandably.

Note that once you pick an object type for a condition row, the type is set – if you click on “DecimalField1″, the object picker window will only show you other decimal fields. If you want to start over with an empty row, hit the red minus button at the right of the row.

Here’s the complete list of conditions for a decimal field:

200908071321

Some of these are more obvious than others, and the mapping from Actions to the XFA scripting events that exists under the hood is intentionally blurred a bit. For example, “is initialized” is pretty obviously related to the “initialize” event for fields, but what event does “is not” map to? That’s where Actions starts to get interesting.

200908071324

This set of conditions will fire when the value entered into the field is >= 10 and <= 20. These two condition rows wind up generating a single line of script in a single event – DecimalField1′s change event. With Action Builder, you express your intentions and Action Builder figures out what code to write and where to put it.

200908071327

This time the two condition rows each reference a different object: TextField1 and TextField2. This results in script being generated in the exit event of both TextField1 and TextField2.

But some conditions can’t be checked with an “and” relationship. For example it doesn’t make any sense to say “When Button1 is clicked AND when Button2 is clicked”, because you can’t click two buttons at the exact same time. If you try to create an Action that we can’t generate script for, we will try to tell you why:

200908071331

Stephanie is going to talk more about trigger conditions and state conditions over on the LiveCycle Designer Exposed blog, so make sure you’re subscribed to that as well if you’re interested in this ongoing Action Builder saga. One last screenshot:

200908071334

Next time, we’ll talk about results.

Action Builder, Part 1

Posted on July 31, 2009 by Steve Tibbett | Comments (1)

What is Action Builder? Action Builder is a new feature coming in the next version of LiveCycle Designer, the LiveCycle form design tool. Action Builder is a tool for building interactivity into dynamic forms that doesn’t require you to write script.

Building interactive forms is nothing new, but it wasn’t an easy task. Most common forms of interactivity required that you write script either in FormCalc or JavaScript. Action Builder writes and maintains this script for you.

Let’s take a look at the UI.

Actionsdialogsimple-1



On the left side is a list of all the Actions defined in your form, and on the right is a list of the Conditions and Results that make up the selected Action. Each Action can have multiple conditions (which can be combined in various ways – more on this in a future post), and can have multiple results.

A new condition row starts out asking you to choose an object that the condition will be based on:

200907310717

Most objects have conditions available. Once you choose one, you’re given the conditions available for that object:

200907310718-1

I picked a button, which only has one condition (“is clicked”) so there aren’t any options to choose. The conditions for this Action will be met when the button is clicked, and when the conditions are met, all of the results defined for the Action execute, in the order they are listed.

When you create a new Result row, you’re prompted to choose the type of result you want this row to be:

200907310719

I’ll choose “Go to a Web Page”, and the row changes into the parameters for that result:

200907310720

The completed Action is given the automatically generated name “Button1.click”, which you can rename. This new action will launch a web page when I click a button on my form.

200907310721

Not exactly rocket science, but even this simple activity required writing script in earlier versions of Designer.

Action Builder is designed to be flexible enough that even if we didn’t specifically think of something you might want to do with it, there’s still a pretty good chance it’s possible. We’re looking forward to seeing what you build with it – and what you wish you could build with it, so we can extend it in future versions.

New Features in LiveCycle Designer

Posted on July 16, 2009 by Steve Tibbett | Comments (0)

Now that the next version of LiveCycle ES is in beta (some info here and you can join here), we can start talking about some of the new features that we’re planning to deliver in LiveCycle Designer, the form design tool that’s part of LiveCycle. We’ve been working on a lot of interesting things.

One of the themes of this version is form simplification. By simplification I don’t mean making simpler forms – I mean making it easier to make complex forms. Reducing the amount of script you have to write, for example, while giving you even richer ways to validate data and show validation problems, and build interaction into your forms.

Validations in particular can account for hundreds or even thousands of lines of JavaScript code in complex forms, but with the new Designer, much of this script is no longer necessary!

And let’s say you wanted a form that had an optional section, with a checkbox that would show or hide that section. In Designer 8.2, this required writing script. Now? A few clicks and you’re done. We’ve built a way for you to write script for the most common types of form interactions that we see in dynamic forms, without having to write script.

It’s called Actions, and there’s a sneak preview over at Mark Szulc’s blog.

Between now and when the new Designer is released, you’ll see some members of the team posting about new features. It’s great to be able to talk about them and I hope you find them useful.

LiveCycle Workbench ES Demo

Posted on August 23, 2007 by Steve Tibbett | Comments (0)

Over on the Adobe LiveCycle Developer Center, there’s a short video tutorial I recorded on what it’s like using LiveCycle Designer in Workbench.

It’s not a tutorial so much as it is a quick tour, but if you’re curious about LiveCycle, Designer, Workbench and how they interact, have a look.

HTTP POST Update

Posted on June 20, 2007 by Steve Tibbett | Comments (0)

I haven’t posted in a little while, but I’m going to try to get back into it. Famous last words, I know, but I’ll start with a post with some real content in it.

Quite a few people have commented on an entry I posted back over a year ago, where I talk about the data format that’s POSTed from a form to an HTTP server.  The data format is supposed to look something like this:

TextField1=test1&TextField2=test2&RichTextField=&ListBox1=&RadioButtonList=

However, some of you said that you were getting data that looked like this:

TextField1=test1TextField2=test2RichTextField=ListBox1=RadioButtonList=

This was actually a bug in Acrobat 8.0, and is fixed in the 8.1 update. If you’re running Acrobat 8.0, allow the Adobe Updater to install Acrobat 8.1 and you’ll get the data in the correct format.


LiveCycle Designer 8

Posted on September 18, 2006 by Steve Tibbett | Comments (0)

Acrobat 8 has been announced, and we’re in the Acrobat 8 Professional box so we share a little bit of that spotlight.

There’s a lot to talk about with version 8.  One of the big new features is a new type of form designed for users who need to take an existing form (either scanned or generated in some other program) and make it an interactive, fillable form while preserving the exact look of the original form.  Just what you’d expect from PDF.  We’ll be talking about this more once more infomation on the product has been released.

On a related note, it’s great to see Breeze getting the spotlight through it’s rebranding as Acrobat Connect.  Breeze is the best collaboration tool I’ve used.

MAX

Posted on September 14, 2006 by Steve Tibbett | Comments (1)

I’m not going to MAX this year.  I went last year, though, and had a great time. 

Last year’s MAX experience for me was mostly about discovering that the Flash player has become a serious virtual machine and runtime for even CPU-intensive applications, thanks to its ability to compile ActionScript down to native code.  There’s even a Commodore 64 emulator for Flash Player 9. 

And it was about discovering Flex and Flex Builder, the Eclipse-based IDE that you use to build Flex apps.  I had no experience with Flex before MAX; now it’s near the top of my “things to dive into more deeply” list.

Last year, MAX happened just before the Adobe / Macromedia merger was finalized, so there wasn’t any official Adobe sessions; this year, MAX has a track for Adobe LiveCycle Technologies.

This year Flash and Flex folks will have the opportunity to discover LiveCycle the way we LiveCycle folks had the opportunity last year to discover Flash and Flex.

If you’re in that boat, don’t miss Matt Butler’s session on Adobe’s Core LiveCycle Architecture and Hands On Deployment, and Sanga Viswanathan’s session, LiveCycle 8: What’s Coming. 

Acrobat Typewriter Tool

Posted on September 3, 2006 by Steve Tibbett | Comments (0)

Working for Adobe, I have access to Adobe software. Acrobat is a tool I don’t think I would have considered buying before starting with Adobe, but after using it for the last two years, I can say it’s right up there with Microsoft Office as one of the things I’d have to have on a new computer.

I was reminded of this just recently, when I was filling out the Tarion 30 day warranty form for my new house.

I received a paper copy of this form as part of the huge stack of documents I got when the house sale closed, but after compiling a list of ~30 items, I just didn’t feel like writing it all out. That’s where Acrobat comes in.

Fillable forms come in two flavours: XFA and Acroform. Acroform forms are forms where you’ve placed the input fields on the form using Acrobat itself; XFA forms are forms created using the Form Designer tool.

I found the forms online, but they’re not fillable. This is pretty common – form authors create forms using something like Illustrator or InDesign, and then create a PDF from that and just post it online, rather than taking the extra step of importing that into Form Designer and adding fields.

But Acrobat has a feature that’s designed for this specific problem: The Typewriter Tool.

I loaded up the Tarion form, got out my handy typewriter, and filled out the form. Printed it, signed it, and faxed it off.

The nice thing about doing it this way is that as I was filling out the form, quite a few times I had to go back and edit something; if I was filling it out on paper, that would have been impossible. I could have filled out a draft on paper and then copied it to the real form, but that’s just more work.

What would the next best thing have been? Loading a bitmap of the form into PhotoShop and filling it out there, I guess – doable, but not nearly as easy.