繰り返し予定を編集するUX：一回・以降・全体の範囲と例外

繰り返す予定を編集するときは、「何を変えるか」と「どの回に適用するか」の両方を、確定前に示す必要があります。今後の予定に個別の変更があるなら、その例外もプレビューに含めます。短い範囲ラベルだけで、変更の影響をすべて伝えることはできません。

毎週木曜、ロンドン時間の09:00に行うデザインレビューを考えます。11月の一回だけは、すでに11:00へ変更されています。主催者はこれからの通常の回を一時間遅らせたいと考えています。一律に新しい時刻を当てはめると、別に調整した約束まで取り消してしまいます。

日付ピッカーの設計ガイドでは、日付や期間の入力、制約、タイムゾーンを扱います。妥当な日時を入力できたら、次はその値を予定の正しい範囲へ適用します。この記事では、四回のレビューを使って、この判断の流れを設計します。

一連の予定を、読み取れる形にする

最初の設計では、回数を限定します。2026年10月22日、10月29日、11月5日、11月12日の四回、各45分のレビューです。通常は09:00開始ですが、11月12日だけは個別に11:00へ変更済みとします。この例では、主催者が10月29日の回を開始前に開き、その日以降の通常の開始時刻を10:00へ変えます。

予定の名前、選んだ日付、所要時間、予定のタイムゾーン、繰り返しの概要をまとめて表示します。「毎週木曜・全4回・ロンドン時間」なら、どの予定か把握しやすくなります。11月12日の詳細には「開始時刻を11:00に変更済み」と示します。繰り返しルールの記号列を理解しなくても、他の日との違いが分かる画面にします。

一回分の予定を移した後も、元の一連の予定との関係は保つ必要があります。Google Calendarの繰り返し予定のドキュメント（英語）は、現在の開始時刻と、一連の予定の中でその回を識別する元の開始時刻を区別しています。画面でも、木曜の回を金曜へ移したときに「元はその木曜のレビューだった」と認識できるようにします。無関係な追加の会議に見せてはいけません。

適用範囲ごとに、変わる日付を示す

範囲を選んでいる間も、選択中の回を見える状態にします。この例では、時刻を編集した後に、変更内容の要約と範囲の選択を並べます。範囲を選ぶとプレビューが変わりますが、この時点では保存しません。

これは、この設計例で明示した製品のルールです。実際のサービスでは、過去の予定や例外を違う方法で扱う場合があります。ラベルを決める前に、製品・開発担当者と動作を合意します。今後の予定にしか作用しないなら、「すべての予定」は不正確です。選んだ回そのものが例外なら、その回への個別の上書きを編集するのか、通常の時刻を編集するのかも説明します。

互いに排他的な選択肢なので、一つだけ選べる選択部品を使います。説明に、最初に変わる日付と例外の数を含められます。前の編集で広い範囲を選んだからといって、気付きにくいまま次へ引き継がないようにします。一回だけ会議室を変えるつもりの操作に、以前の「全体を変更」が残っていてはいけません。

確定ボタンは「2回のレビューを変更」のようにできます。そのすぐ上に対象の日付を置きます。終了のない一連の予定なら、有限の総数を作り出さず、「10月29日以降の毎週木曜」のような開始の境界と、一定範囲のプレビューを使います。

通常の回と例外を、一緒に確認する

「この予定と以降の予定」では、四回すべての結果を示します。この例では、変わらない行も見せることで、変更対象だけの一覧では隠れる前後関係を伝えられます。

表には「すべてロンドン時間」と付けます。確認文は「10月29日から2回のレビューを10:00へ変更します。11月12日は11:00のままです」と具体的に書けます。色で変更行を目立たせても、変更前後の文字と理由だけで結果が分かるようにします。

個別の変更を保つのは、この例で選んだ方針であり、すべてのカレンダーの保証ではありません。実際の操作が個別変更を置き換えるなら、影響する例外と結果の値を保存前に列挙します。長い一連の予定では、件数と展開できる一覧を使えます。会議室だけを変え、時刻は変えていない例外も考えます。すべての項目をリセットすると、今回の依頼に関係ない情報まで失うおそれがあります。

もっと複雑な変更では、例外が元々属していた回がなくなることもあります。木曜を火曜へ変えると、開始時刻を一時間遅らせる場合とは別の問題が生じます。すでに木曜から金曜へ移したレビューを、どうするのでしょうか。サービスが計算した実際の予定をプレビューへ返すようにします。保存済みの例外が必ず維持される、移される、消える、と画面設計だけで決めないようにします。

夏時間の切り替えで、何を一定に保つかを示す

「毎週木曜09:00」にも、時刻の基準が必要です。名前付きタイムゾーンの09:00に固定する会議では、UTCで表した時刻が変わることがあります。08:00 UTCに固定した予定は、ロンドンの時計では別の結果になります。

英国では2026年10月25日に時計を一時間戻します（英語）。ここでは編集後の10:00ではなく、元の09:00を使い、切り替え前後の違いを比較します。

仕事に合う基準を選び、繰り返しの概要の近くに明示します。このレビューなら「ロンドン時間09:00」で、チームの現地の会議時刻を保てます。遠隔地の参加者には「あなたの時刻」の併記が役立ちますが、それで予定の基準となるタイムゾーンを黙って置き換えてはいけません。主催者が基準のゾーンを変える場合は、現地の時計の時刻を保つのか、それまで予定していた瞬間を保つのかをプレビューします。

RFC 5545（英語）は、UTC、タイムゾーンを指定した現地時刻、特定のゾーンに結び付かないフローティング時刻を区別しています。フローティング時刻は特定のゾーンと独立しているため、国際会議の時刻を省略して表す方法として安易に使えません。同じ仕様では、繰り返し規則から生成される無効な日付や、存在しない現地時刻を除外します。「毎月31日」や、春の時計の切り替えで存在しない時間帯には、モックアップで推測した日付ではなく、実際の予定のプレビューが必要です。

そのような予定を扱う製品では、繰り返しを計算する仕組みの結果をデザインレビューに持ち込みます。除外された日や調整された日を、サービスの実際の方針に従ってどう説明するか決めます。説明は該当する日付の近くに置きます。数画面先の一般的なタイムゾーンの注記だけでは、予定が見当たらない理由は伝わりません。

キャンセルと保存結果まで、編集の流れに含める

キャンセルでも、同じように範囲を明確にします。「11月5日のレビューをキャンセル」と「11月5日より前で繰り返しを終了」は、結果が異なります。前者では後のレビューが残り、後者ではサービスの規則に従って、それ以降の予定がなくなります。曖昧な「予定を削除」の確認では、この違いが隠れます。

一回をキャンセルした後は、予定の履歴など、適切な場所で結果を確かめられるようにします。プロトタイプでも、後の回が残っていることを示します。復元を提供するのは製品が対応している場合だけにし、その回を戻したときに、以前の個別変更も戻るかを説明します。

保存中も、依頼した範囲とプレビューを見せ、誤って二重送信しないようにします。明確に失敗したら、主催者の編集内容を残します。応答から結果が分からないときは、再保存を促す前に、現在保存されている状態を確認します。クライアントが結果を知らないだけなのに、「何も変わりませんでした」と断言してはいけません。

プレビューを開いている間に、別の人が11月12日のレビューを移すこともあります。新しく変更された回を示し、確定前に影響を見直してもらいます。主催者が指定した10:00は残し、最初から入力し直さずに変更を調整できるようにします。

サービスが区別できるなら、保存と通知の状態も分けます。「2回のレビューを更新しました」は予定の状態、「招待を送信しました」は別の処理の結果です。後者は確認できた場合だけ表示します。参加者全員が新しい時刻を見た、あるいは承諾したと、画面で約束しないようにします。

Pixsoで、範囲を選んだ結果を試す

Pixsoに五つのフレームを作り、つなぎます。10月29日の選択中のレビュー、編集した時刻と範囲の選択、四回分のプレビュー、維持する11月12日の例外の詳細、保存後のカレンダーです。日付、所要時間、タイムゾーンのラベルを各フレームで一致させます。レビュー行を部品として再利用し、選択中や処理中の見た目を変える際に、データまで変えてしまわないようにします。

Pixsoのプロトタイピング機能（英語）では、画面の要素を行き先のフレームへつなぎ、開始フレームを設定し、操作をプレビューできます。各範囲の選択から対応する結果へつなぎ、キャンセルの経路も含めます。フレームは合意したスケジュールの動作を表します。プロトタイプ自体が繰り返しを計算したり、実際のカレンダーを更新したりするわけではありません。

参加者には、「10月29日以降の通常のレビューを10:00にし、別に調整済みの11月の回は11:00に保つ」と依頼します。保存前に、どの日付が変わるかを尋ねます。保存後は例外を探し、11月5日の回だけをキャンセルしてもらいます。予想と表示された結果が食い違う場所を記録します。

次に、「10月の時計の切り替え前後でも、ロンドン時間09:00のレビューを保つ」という別の依頼を試します。正しい範囲を選べても時刻の基準を説明できなければ、判断材料がまだ足りません。誤解が生じた場所の概要やプレビューを直します。目指すのは、主催者が、動く日付、残る例外、参加者が従う時刻を具体的に説明できる状態です。