あなたは、クライアントが取り込むための PDF フォームをデザインしています。クライアントが「個人」を選択した場合、アカウントの種類として、フォームには名前と社会保障番号のフィールドが表示される必要があります。 「ビジネス」を選択した場合、フォームには、代わりに会社名と雇用主識別番号のフィールドが表示される必要があります。紙のフォームでは、両方のセクションを印刷し、「該当する場合」と記入します。それぞれの隣にあります。デジタル PDF では、条件付きロジックにより無関係なセクションを完全に非表示にし、実際に入力する必要があるフィールドのみをユーザーに表示できます。
PDF フォームの条件付きロジックは実際に機能しますが、重要な注意点があります。 JavaScript と CSS によって表示設定とレイアウトを柔軟に制御できる Web フォームとは異なり、PDF の条件付きロジックは、PDF 形式の制限された JavaScript 実装と、さまざまな PDF ビューアでの一貫性のないスクリプト実行方法によって制約されます。何が可能で何が不可能かを理解していれば、テスト環境では機能しても受信者の半数にとっては機能しないフォームを設計することができなくなります。
PDF フォームの条件付きロジックで実際にできること
PDF の条件付きロジックは、2000 年代初頭から PDF 仕様の一部となっている JavaScript の簡易バージョンである Acrobat JavaScript で実行されます。ユーザー入力に基づいてフォームフィールドを表示または非表示にすることができます。フィールドを有効または無効にしたり、フィールドの色や境界線を変更したり、フィールドを必須またはオプションとしてマークしたり、ルックアップ テーブルからフィールドの値を設定したりできます。ユーザーの入力時に入力を検証し、警告メッセージを表示し、特定の条件が満たされた場合に計算をトリガーできます。
ページレイアウトを再構築することはできません。フィールドを非表示にすると、そのフィールドは表示されなくなりますが、フィールドが占めていたスペースは残ります。以下のフィールドは上にスライドして隙間を埋めることはできません。ページはリフローしません。これが、PDF フォーム と Web フォームの唯一の最大の違いであり、PDF 内で Web フォームのエクスペリエンスを再現しようとするときに最も失望する原因です。条件付きロジックでページ レイアウトを大幅に変更する必要がある場合、PDF は間違ったツールです。固定レイアウト内でいくつかのフィールドを表示または非表示にする必要がある場合、PDF の条件付きロジックがそれを適切に処理します。
ドロップダウンまたはチェックボックスの選択に基づいて表示/非表示ルールを設定する方法
最も一般的な条件パターンは、後続のどのフィールドを表示するかを制御するドロップダウンまたはラジオ ボタンのセットです。 WukongPDF のフォーム エディターで、制御フィールド、つまり値によって次に何が起こるかを決定するドロップダウンまたはラジオ ボタン グループを作成することから始めます。 「accountType」のような明確な名前を付けます。次に、表示または非表示にするすべてのフィールドを作成します。可能なすべてのフィールドが最初からフォーム上に存在する必要があります。条件付きロジックは可視性のみを制御します。フィールドを作成したり破棄したりすることはありません。
フィールドを作成したら、制御フィールドのプロパティを開き、「検証」または「ブラー時」イベント タブを見つけます。ここに、ユーザーの選択に応答する JavaScript を記述します。単純な表示/非表示スクリプトは次のようになります。 this.getField("ssnField").display = (choice === "個別") ?表示.可視 : 表示.非表示; this.getField("einField").display = (choice === "ビジネス") ?表示.可視 : 表示.非表示;ユーザーがドロップダウンを変更すると、スクリプトが実行され、選択された値がチェックされ、各フィールドの表示プロパティが表示または非表示に設定されます。
重要な詳細: すべての条件付きフィールドの初期状態を、制御フィールドのデフォルト値と一致するように設定します。ドロップダウンのデフォルトが「個人」の場合、 SSN フィールドは表示され、EIN フィールドは非表示になります。フィールドが間違った状態で開始されると、最初にドロップダウンを操作するまで、ユーザーには両方が表示されるか、どちらも表示されず、壊れているように見えます。初期状態とスクリプト ロジックは一致する必要があります。
ユーザーが次に進む前に入力をチェックする検証ルール
条件付きロジックは、可視性を超えて入力検証まで拡張されます。日付フィールドでは、入力された日付が許容範囲内にあるかどうかを確認できます。電子メール フィールドでは、入力に @ 記号とドメインが含まれていることを確認できます。電話番号フィールドにはちょうど 10 桁が必要です。検証スクリプトは、フィールドの Validate イベントで実行され、ユーザーがフィールドを離れようとすると発生します。スクリプトがevent.rc = falseを呼び出した場合、フォーカスはフィールドに留まり、ユーザーは入力が修正されるまで先に進むことができません。
実際の電話の検証は次のようになります。 if (phone !== "" && !/^\d{10}$/.test(phone)) { app.alert("10 桁の電話番号を入力してください。");イベント.rc = false;このスクリプトはスペース、ダッシュ、括弧を取り除き、残りの文字が正確に 10 桁であるかどうかをチェックします。すべての電話フィールドが必要なわけではないため、フィールドが空の場合は検証に合格します。フィールドに内容はあるが 10 桁ではない場合、スクリプトは警告メッセージを表示し、ユーザーがフィールドから離れることをブロックします。
検証ルールは慎重に使用し、明確なエラー メッセージを付けて使用する必要があります。あらゆるフィールドで不可解なアラートを表示してユーザーをブロックするフォームはフラストレーションを引き起こします。間違った入力が実際に問題を引き起こすフィールドのみを検証し、ユーザーが修正する必要があるものを説明するフォームは、自信を生み出します。警告テキストには、何が問題なのか、そしてそれを修正する方法を正確に記載する必要があります。 「無効な入力です」役に立たない。 「電話番号はスペースやダッシュを含まない 10 桁でなければなりません」ユーザーに何をすべきかを指示します。
ビューアの互換性の問題とその回避方法
PDF JavaScript は、Adobe Acrobat Reader、Acrobat Pro、およびほとんどのデスクトップ PDF アプリケーションでサポートされています。 Chrome の組み込みビューア、Firefox の PDF.js、Safari のプレビューなど、ほとんどのブラウザベースの PDF ビューアではサポートされていません。一部のモバイル PDF アプリでは部分的にサポートされていますが、完全にサポートされていないものもあります。フォームが条件ロジックと検証スクリプトに依存しており、受信者が JavaScript を実行しないビューアでフォームを開くと、非表示にするフィールドを含むすべてのフィールドが表示され、検証ルールはいずれも起動されません。
これに対する完璧な技術的解決策はありません。最良のアプローチは、明確なラベルとフォームの上部にある目立つ説明を組み合わせることです。条件セクションにトリガー条件のラベルを付けます: 「上でビジネスを選択した場合は、このセクションを完了してください。」こうすることで、スクリプトが失敗した場合でも、ユーザーは手動でフォームに従うことができます。 Interactive PDF エクスペリエンスは、理解できなくなるのではなく、使用可能な静的形式に正常に劣化します。
複数のビューアにわたる条件付きフォームのテスト
条件付き PDF フォームを配布する前に、デスクトップの Adobe Acrobat Reader、Chrome 組み込み PDF ビューア、Mac の Safari またはプレビュー PDF ビューア、iPhone と Android の両方のモバイル PDF ビューアの少なくとも 4 つの環境でテストしてください。それぞれの環境で、フォームを体系的に処理してください。ドロップダウンの選択を変更し、正しいフィールドが表示されたり消えたりすることを確認します。無効なデータを入力し、検証メッセージが表示されて送信が妨げられることを確認します。フォームを保存して再度開き、保存された状態が一貫していることを確認します。
社内フォームや特定のポータル経由で送信されたフォームなど、既知の対象者に送信されるフォームの場合は、対象者が実際に使用するビューアのみをテストします。組織内の全員が Adobe Acrobat を使用している場合、ブラウザの互換性は関係ありません。フォームが公開 Web サイトに投稿され、あらゆるデバイスを使用して誰でも開く場合、かなりの割合のユーザーが JavaScript なしでフォームを閲覧すると想定してください。すべてのフィールドが表示され、すべての指示がクリアされた状態で、劣化した状態でも問題なく機能するようにフォームを設計し、条件付きロジックを要件ではなく機能強化にします。
条件付きロジックが代わりに Web フォームに属する場合
フォームにマルチステップのウィザード、動的なフィールドの作成、リアルタイムのサーバー検証、またはフィールドの表示と非表示時のページのリフローが必要な場合は、PDF ではなく Web フォームが適切なツールです。 PDF フォームは、インタラクティブな拡張機能を備えた静的なドキュメントです。 Web フォームは、ドキュメントのような出力を備えた対話型アプリケーションです。 PDF で複雑な条件付きフォームを構築した後に、視聴者の半数がそれを意図したとおりに使用できないことが判明するのは、イライラと時間のかかる間違いであるため、この区別は重要です。
実用的なハイブリッド アプローチは、データ収集と条件ロジックに Web フォームを使用し、署名、アーカイブ、共有のために送信されたデータから PDF を生成することです。 WukongPDF の PDF Editor は、このワークフローでうまく機能します。Web フォーム経由でデータを収集し、回答を PDF テンプレートに入力し、記録用に洗練された PDF をユーザーに配信します。 Web フォームがロジックを処理します。 PDF がプレゼンテーションを処理します。各ツールは、それぞれが最も得意とすることを実行します。