Are you developing this on OS/X? Because loading a PDF is not so seamless on operating systems that don’t use the format natively. On a badly-configured workstation, the debug-compile-test cycle you’re forcing the user into will be longer.

Add clear button.
Only hide help text if the user changes it.
SSL certs.
PDF cell alignment and stretching.

1) Start with the help text.

2) If onFocus the text is still the help text, empty it.

3) If onFocus anywhere else and the help text is empty, reset it.

I did it that way because I hate not being able to get back to the start state of a program — I didn’t want the text to disappear forever. This raises a potential issue though: What if the user wants to print a return with an empty business number?

Really I want to set a flag if the user changes the text, but that can go on the TODO list.

Paper doesn’t validate.

Calendar pickers cause a context change from keyboard entry to mouse entry, and all the default calendar pickers have tiny buttons.

Good one.

@Separators:

I’m going to try a version of the fields without them. Yes, they’re unhonored — and will be in the form too when it’s cleaned up (I always used to write in the space over the separators at the firm).

@Date fields:

I did think about calendar fields, but the “multiple cheap retries” idea makes those unnecessary too.

The “from” and “to” dates are quarterly, unless it’s a partial-period return. The due date is also statutory, but you can finesse that too. There’s a lot of “validation” possible there that would just get in the way.

Calendar pickers aren’t really useful for picking quarterly dates — you’d have to start each use with paging to the correct month, a huge time-sink. That alone is enough to nix them for me.

Once I start adding validation there are so many special rules on the dates that I wouldn’t have finished. Add to that: Some firms might want dates in different formats. Or different formats for different clients.

But low-cost text-based retries fix all that. Basically: Date picker fields are out-of-scope because they’ve got an inappropriate cost/benefit trade-off. And yes, I thought about this before starting

@Usability:

Usability includes validation when failure takes ages to recover from. If your feedback loop is tight enough I assert that validation is a waste of time. Interactive script sessions are more responsive than debug/compile/test.

I might do number field checking, but the cost of user failure recovery is so low the task is not urgent.

• You need to make the help text disappear when the user activates the control.
• What’s the point of the character separators in the fields if you’re typing? Oh, they’re on the output form but you’re not honoring them?
• I guess accountants don’t like calendar pop-up controls for the date fields?
• I think good usability includes validation. But you’re probably one of those people who likes dynamically-typed programming languages.