ハイライト
iOS 14 と macOS Big Sur は Siri イベントの提案を拡張し、アプリ、Safari、メールがインテントの寄付または schema.org マークアップを使用してカレンダーに予約を書き込むことができるようにし、マップ、ロック画面、シミュレーター、コンソールを介した到着とデバッグのプロセスを改善します。
主要内容
レストラン、航空券、ホテル、チケット発券アプリで予約をした後も、ユーザーの仕事はまだ終わっていません。確認ページは最初のステップにすぎません。次に、出発リマインダー、ルート、フライトのチェックイン、店舗に到着するまでの時間判断、一時的な変更やキャンセルなどがあります。以前は、この情報がアプリやメールにのみ保存されていた場合、カレンダー、マップ、ロック画面でユーザーが適切なタイミングでこの問題を続行できるようにするのは困難でした。
Siri イベントの提案は、このブレークポイントを処理します。セッションの開始時に、機能の境界が定義されます。ユーザーは通常どおりアプリで予約を完了し、システムはその予約をカレンダーに追加し、デバイス側のインテリジェンスを使用してロック画面で出発を通知したり、マップでルートの提案を表示したり、フライト前にチェックインを促したりします (00:42)。
2020 年の変化は 2 つあります。最初のレイヤーはアプリ側の拡張機能です。バスとボートの予約がサポートされており、macOS Big Sur と Mac Catalyst App は Intents フレームワークを通じて予約を寄付することもできます。 iOS アプリと macOS アプリによって提供されたデータが一貫している場合、システムはエンドツーエンド暗号化を使用してデバイス間で予約を同期します (02:28)。
2 番目の層は Web と電子メールです。ユーザーはウェブサイトで注文し、アプリで注文を変更し、メールで確認情報を確認することができます。 iOS 14 と macOS Big Sur では、Web サイトと電子メールが schema.org マークアップを使用して同じサブスクリプションを表現できるようになり、Safari とメールがそれをシステムに寄付する責任があります (04:12)。これにより、アプリを開いていないユーザーも、カレンダー、マップ、Siri の提案の同じエクスペリエンス チェーンを得ることができます。
詳細
schema.org を使用して、Web サイトおよび電子メールで予約をマークアップする
(05:34) Web と電子メールの統合では schema.org を使用します。 Apple は JSON-LD と Microdata を明示的にサポートしています。以下は、レストラン確認メールのステータス、確認番号、人数、レストラン、時間、電話番号、住所を構造化した公式スニペットの Microdata バージョンです。
<div itemscope itemtype="FoodEstablishmentReservation">
<link itemprop="reservationStatus" href="http://schema.org/ReservationConfirmed"/>
<meta itemprop="reservationId" content="IWDSCA"/>
<meta itemprop="partySize" content="2"/>
<div itemprop="reservationFor" itemscope itemtype="FoodEstablishment">
<meta itemprop="name" content="EPIC Steak"/>
<meta itemprop="startDate" content="2020-06-26T19:30:00-07:00"/>
<meta itemprop="telephone" content="(415)369-9955"/>
<div itemprop="address" itemscope itemtype="PostalAddress">
<meta itemprop="streetAddress" content="369 The Embarcadero"/>
<meta itemprop="addressLocality" content="San Francisco"/>
<meta itemprop="addressRegion" content="CA"/>
<meta itemprop="postalCode" content="95105"/>
<meta itemprop="addressCountry" content="USA"/>
</div>
</div>
</div>
キーポイント:
reservationStatusシステムがこれを確認された予約、変更された予約、またはキャンセルされた予約として扱うかどうかを決定します。 -reservationIdこれは、同じカレンダー イベントに対する以降の更新のキー フィールドです。 -startDateローカル タイム ゾーンを使用すると、ユーザーは都市やタイム ゾーンをまたぐときに誤ったリマインダーを回避できます。 -address地図と出発リマインダーに位置ベースを提供します。セッションでは、アドレスが完全であればあるほど、ユーザー エクスペリエンスが向上することが明確に述べられています。
変更とキャンセルの両方で同じ予約 ID を維持する必要があります。
(06:49) ユーザーが時間を変更するか予約をキャンセルする場合、マークアップは最新のステータスを反映する必要があります。 Apple の例では、レストランの予約を変更するときに保持IWDSCA、時間を午後 7 時 30 分から午後 6 時 30 分に変更するだけです。キャンセルする場合は、ステータスを に変更しますReservationCancelled。 Siri も同じものに依存していますreservationId元のカレンダー イベントを見つけて更新します。
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "FoodEstablishmentReservation",
"reservationStatus": "http://schema.org/ReservationCancelled",
"reservationId": "IWDSCA",
"partySize": "2",
"reservationFor": {
"@type": "FoodEstablishment",
"name": "EPIC Steak",
"startDate": "2020-06-26T19:30:00-07:00",
"telephone": "(415)369-9955"
"address": {
"@type": "http://schema.org/PostalAddress",
"streetAddress": "369 The Embarcadero",
"addressLocality": "San Francisco"
"addressRegion": "CA",
"postalCode": "95105",
"addressCountry": "USA"
}
}
}
</script>
キーポイント:
reservationStatus確認済みからキャンセルに変更すると、システムは対応するカレンダー イベントをキャンセルします。 -reservationIdステータスの変化によって変更することはできません。変更された場合、システムにより別の予約として扱われます。 -startDate、レストランの名前と住所は、システムが処理対象の同じものを見つけやすくするために引き続き保持されます。- この段落は公式スニペットからのものであり、フィールド構造はセッション表示に従って保持されます。
ローカル デバッグの場合、ドメイン名と HTTPS の制限をオフにする必要があります。
(07:38) 正式リリースの前に、Web サイトのドメイン名を Apple に登録する必要があり、サイトは HTTPS を使用する必要があり、電子メールには有効な DKIM 署名が含まれている必要があります。開発段階では制限が一時的に緩和される場合があります。 macOS では 2 つのデフォルト コマンドを使用し、iOS では開発者設定で対応するスイッチをオンにします。
defaults write com.apple.suggestions SuggestionsAllowAnyDomainForMarkup -bool true
キーポイント:
- このスイッチは、ローカル環境またはテスト環境に適した、未登録のドメイン名を許可するために使用されます。
- 正式な登録に代わるものではありません。ドメイン名とマークアップのサンプルは、公開前に提出する必要があります。
defaults write com.apple.suggestions SuggestionsAllowUnverifiedSourceForMarkup -bool true
キーポイント:
- このスイッチは、未検証のソースを許可するために使用されます。セッション デモでは、HTTPS がローカルで利用できない環境を処理するためにこれを使用します。
- 検証をオフにすることは開発マシンにのみ適しており、実稼働プロセスに入るべきではありません。
予約用の URL を入力し、デバイスにアプリがない場合は Safari に戻ります
(19:44) アプリが寄付されましたINReservationiOS 14 に URL プロパティが追加されました。アプリがインストールされていないデバイスにカレンダー イベントが同期されている場合、システムには [Safari で表示] ボタンが表示され、ユーザーは指定した Web ページを開いて予約の管理を続けることができます。 Web マークアップの公式スニペットも同じ考えを示しています。
<script type='application/ld+json'>
{
"@context": "http://schema.org",
"@type": "http://schema.org/FoodEstablishmentReservation",
"reservationId": "IWDSCA",
"reservationStatus": "http://schema.org/ReservationConfirmed",
"url": "http://localhost:3000/reservations/6",
"underName": {
"@type": "http://schema.org/Person",
"name": "John Appleseed"
},
"broker": {
"@type": "http://schema.org/Organization",
"name": "Apple Reservations"
},
"startTime": "2020-06-26T19:30:00-07:00",
"partySize": "2",
"reservationFor": {
"@type": "http://schema.org/FoodEstablishment",
"name": "EPIC Steak",
"telephone": "(415)369-9955",
"address": {
"@type": "http://schema.org/PostalAddress",
"streetAddress": "369 The Embarcadero",
"addressLocality": "San Francisco"
"addressRegion": "CA",
"postalCode": "95105",
"addressCountry": "USA"
}
}
}
</script>
キーポイント:
urlカレンダー イベントによってユーザーが特定の予約ページに戻るようにします。 -underNameそしてbroker予約の帰属とサービスプロバイダーを補足しました。 -startTimeISO 8601 を使用し、予約場所のタイムゾーンを含めます。- 同じ予約情報セットが Web ページ、電子メール、アプリからシステムに提供される可能性があり、フィールドの一貫性が更新の効果に影響します。
アプリの寄付では、予約番号、containerReference、itemReference を区別する必要があります
(13:43) アプリは独自の予約モデルから開始し、予約の詳細をINReservationオブジェクトを入力し、Siri に寄付するためのインテント応答とインタラクションを入力します。ユーザーがカレンダーの「アプリで表示」をクリックすると、システムが構築しますINGetReservationDetailsIntent、アプリは寄付のコンテナとアイテムの参照を使用して、正しい予約を取得します。
App reservation details
-> INReservation objects
-> intent response + intent
-> donated interaction
-> Calendar event
-> INGetReservationDetailsIntent when user taps "Show in App"
キーポイント:
reservation numberソース間で同じ予約を識別するために使用され、アプリ、メール、ウェブサイトは一貫している必要があります。 -containerReferenceアプリ内の予約全体を識別します。これには複数の部分が含まれる場合があります。 -itemReference往復の鉄道チケットのセクションなど、予約の個々の部分を識別します。- 複数の旅程で同じ旅程を再利用することはできません
itemReferenceそうでない場合、アプリは起動時にどの段落を表示するかを決定できません。
寄付のタイミングとデバッグ パスは実際の変更をカバーする必要があります
(20:22) Apple は、ユーザーが今後の予約、個々の予約、予約の特定部分のリストを表示するとき、また、アプリ外での変更後にシステム データを更新するときに寄付することを推奨しています。バックグラウンド アプリ更新では定期的に更新を確認でき、サイレント プッシュでは変更が発生したときに更新して再寄付できます。
Upcoming reservations list
Single reservation screen
Specific reservation part
Background App Refresh
Silent push notification
キーポイント:
- 初めて予約を寄付する場合にのみ、システムからユーザーに通知されます。短期間内の複数の寄付は、賢くグループ化されます。
- アプリ外で変更やキャンセルが発生した場合は、古いデータがカレンダーに残らないように、新たに寄付を行う必要があります。
- iOS 14 は、シミュレーターでの Siri Event Suggestions API のテストをサポートしています。
(22:06) デバッグするときは、Console.app を見て、カテゴリでフィルターします。siri-event-suggestions。セッションのデモでは、2 つのよくある間違いが示されています。2 つのバス予約部分が同じものを再利用しています。itemReference; 新しいシミュレーターはカレンダーの新着情報画面をまだ確認していません。 Web マークアップでは、サブスクリプションの終了時間が経過した場合など、同じタイプのログ位置決めを使用することもできます。
Console.app
-> select device or Mac
-> search category: siri-event-suggestions
-> start streaming
-> trigger app donation or reload Safari page
キーポイント:
- 寄付とマークアップは両方とも非同期で処理される場合があり、このプロセスでアプリが常に明示的なエラーを取得するとは限りません。
- カテゴリ フィルタリングにより、システム ログを Siri イベント提案関連メッセージに集約できます。
- ログは重複などの特定のフィールドの問題を指摘します
itemReferenceまたは終了時刻が過ぎています。
重要ポイント
1. カレンダー アウトレットを予約システムに追加します
やるべきこと: レストラン、イベント、ホテル、航空券、または発券アプリが成功を確認したら、その予約を Siri Event Suggestions に寄付すると、そのイベントが自動的にカレンダーに表示されます。
実行する価値がある理由: このセッションでは、ユーザーが予約を完了した後も、システムは出発リマインダー、ルート、チェックインの提案を提供し続けることができ、その価値はアプリの外部で発生することを説明しています。
開始方法: まず、内部注文モデルを統合された予約番号、時間、場所、ステータス、管理 URL に整理します。アプリを使用するINReservation寄付、Web、電子メールでは schema.org マークアップを使用します。
2. 確認メールをシステムの入口にします
対処方法: メールがバックグラウンドで予約を認識し、カレンダーに追加できるように、確認メールの HTML に JSON-LD または Microdata を追加します。
価値がある理由: ユーザーは確認情報を得るために電子メールを頻繁にチェックします。 Mail がマークアップをサポートすると、ユーザーはアプリを開かずにカレンダー バナーとキャンセル プロンプトを表示できるようになります。
開始方法: レストランまたはイベントの確認レターから開始します。保証付きreservationStatus、reservationId、時間、場所、住所が完了しました。ドメイン名を登録し、テストに合格したら DKIM を確認します。
3. 複数区間の旅行に関する参照ルールを確立する
やるべきこと: 往復航空券、複数区間の航空券、旅行パッケージなどの複数部分の予約を設計するcontainerReferenceそしてitemReference命名規則。
実行する価値がある理由: セッションの電車と旅行パッケージの例は、システムがアプリに要求するのは一定期間の予約のみであることを示しています。項目参照を繰り返すとジャンプが失敗します。
開始方法: 注文番号全体をコンテナとして使用します。チケット番号、フライト番号の組み合わせ、またはサーバーによって生成された部分 ID をアイテムとして使用します。人間が読める説明で SpokenPhrase を記述します。
4. Web ページのフォールバックをカレンダー イベントに追加する
対処方法: 各予約には、開くことができる管理 URL が用意されており、アプリのないデバイスでもカレンダーから Web ページにアクセスできるようになります。
実行する価値がある理由: カレンダーのイベントはデバイス間で同期されるため、ユーザーは必ずしも各デバイスに同じアプリをインストールする必要はありません。
開始方法: 確認ページを、表示、変更、キャンセルをサポートする安定した URL にします。アプリの寄付INReservationどちらも Web マークアップとして同じページ アドレスを使用します。
5. Siri イベント提案のデバッグ チェックリストのセットを作成する
やるべきこと: シミュレータ、コンソール カテゴリのフィルタリング、マークアップのデフォルト、カレンダーの初回使用の確認、および有効期限のチェックを QA プロセスに書き込みます。
実行する価値がある理由: セッションによって表示される失敗は、繰り返しフィールド、初期化されていないカレンダー、期限切れのサブスクリプションなど、見落としやすい詳細に焦点を当てています。
開始方法: 各テストとフィルターの前に Console.app を開きます。siri-event-suggestions;アプリの寄付は最初にシミュレーターをテストし、Web マークアップは最初にデフォルトを使用してローカル ドメイン名と未検証のソースを解放します。
関連セッション
- SiriKit とショートカットの新機能 — iOS 14 の SiriKit、ショートカット、コンパクトな Siri UI、システム アクション ポータルに対するグローバルな変更を初めて見てみましょう。
- インテントを強化する — インテント処理、アプリ内インテント処理、パフォーマンス バジェット、および豊富な会話エクスペリエンスについて詳しく説明します。
- 一般的な Siri エラーを解読して対処する — Siri とショートカットのデバッグにプロセス、ログ、完了ハンドラー、デバイス ログのチェックを追加します。
- インテリジェンスのためのデザイン: 「システム」と友達になる — システム インテリジェンスがインテント、寄付、拡張性からアプリの機能をどのように学習して実行するかを理解します。
- インテリジェンスのためのデザイン: 新しい機会の発見 - カレンダー、マップ、ロック画面、検索などのシステム入口がアプリ機能の可視性をどのように向上させることができるかを説明します。
コメント
GitHub Issues · utterances