2x Datepicker vs 1x Datepicker + Range select
最速で最も便利な方法で出発日と帰りの日付を選択する方法を理解しようとしていますフライト検索フォーム。
旅行業界の標準は、出発と帰りのカレンダーを1つにすることですが、ユーザーの約70％が2週間の旅行を検索するため、「日付1 +期間」を選択するのは遅いアプローチのようです。
私たちの言語では、少なくともスウェーデンでは、多くのシステムのように期間を指定していません。 「10月10日に出発し、10月24日に戻る」と言ったり考えたりすることはありません。 「10月10日に出発し、2週間留守にする」と言う人もいます。
では、ほとんどの旅行サイトで使用されている標準の2つの日付ピッカーの代わりに、1つの日付ピッカー+期間を使用する方が速くて優れているのではないでしょうか。また、マウス入力のないデバイス（電話/タブレット/将来的に不明なデバイス）の方がはるかに高速になります。
画像
大きなサイズのバージョンの画像をクリックしてください。
。
標準の2x日付ピッカー
1x日付ピッカー+範囲選択
上記の説明（「...またはカレンダーを使用」に注意してください）
2014年5月23日更新
Izhakiの返信からインスピレーションを得て更新された例/テスト
2014年5月28日更新
iPhone 4の例。 iP4-バージョンは、アイデアがより小さいビューポートにどれだけ適合するかを確認するために作成されました。 「戻る」ボタンについてはわかりません。同じビュー内に組み込むのではなく、日付範囲の選択をカレンダービューの外に残した方がよい場合があります。
2つのカレンダーアプローチが非常に広く採用され、使用するのに非常に便利である理由は、ユーザーの思考プロセスと同期しているためです。つまり、人々がチケットを予約するとき、旅行の出発日と帰国日がわかっています。しかし、滞在期間を意識的に意識していることはあまりありません。彼らに持続時間を述べさせる（したがって、最初にそれを精神的に計算する）と、短期的な認知負荷が増加します。また、10日に出発し、17日に戻るとすると、少しの間休止して、期間として7日と8日のどちらを入力するかを考えます^
インターフェースの変更に固執している場合（はい、現在のバージョンは退屈です）、@ user43251が述べたアプローチを使用することをお勧めしますが、以下の詳細なアプローチを実装することにより、より直感的な感じを与えることができます
ユーザーが選択している日付（出発または帰国）が明確に示されている。出発日選択中は、戻るボタンは無効になります。日付を選択した後、ユーザーは返却日の選択に進みます
（両方の日付を一度選択した後）クリックで何が実行されるかについて混乱がないため、この方法を特に選択しました。この方法では、最初に選択した日付に間違いがあった場合に、戻り日を簡単に編集できます*。また、下部にはユーザーが期間を手動で入力できる期間を示すフィールドがあります（必要に応じて、色とタイプを使用してこの領域をさらに強調表示できます）。
UIをより面白く/視覚的に魅力的なものにするために、モックアップで行ったように、太字/大きなテキストの詳細を実装し、タイポグラフィで混乱させることができます。このようなものはおそらく：
^「10月10日に出発し、2週間滞在します」と言うこともできますが、通常は1〜2日の許容範囲であることを意味するため、それほど具体的ではありません。
* http://jsfiddle.net/IrvinDominin/LALED/ の場合とは異なり、移動期間は最後の2つのクリックの間の期間です（以前のクリックを破棄し、誤った情報を入力したユーザーを罰します）そしてさらに悪いことに、これは明らかに明らかではなく、数回のクリックの後にのみ収集できます）
OPのコメントの後に編集
その場合、期間フィールドをより強調表示（色、タイポグラフィなど）して、最初にそれを埋めることができます。レイアウトも少し変更できます。
短期的な認知負荷を軽減する目的は同じです。ユーザーのメンタルプロセスを理解し、その解決策を設計することは、考慮に入れるユーザーベースによって異なります。ユーザー調査について確信がある場合は、@ Izhakiが提案する解決策はかなり良いものです。私は個人的に最も効果的だと思うことに応じて、少し変更を加えました。
当然、視覚的なデザインを改善する必要がありますが、このインターフェースの利点は、Izhakiのインターフェースと比較して、ユーザーが大量のスクロールをしなくても、はるかに大きいまたは小さい数値を入力できることです。また、日数が連続してリストされている場合、カレンダーの数と混同される可能性があります。 （カレンダーに記載されている日付の数を減らして、出発の1週間は表示されず、出発の次の2週間のみが表示されることに注意してください。これにより、ユーザーが圧倒されないように、インタラクション要素のサイズが圧縮されます。不必要に大きいインターフェースによる）
pSこのインターフェースは、予約の返品部分用です。出発部分を予約するために、以前のデザインが立っています。したがって、フロー全体は次のようになります。ユーザーがフィールドをクリックする->カレンダーがポップアップして予約の出発日が表示されます->ユーザーが出発日をクリックする->同じカレンダーの遷移で、帰りの予約が示され、日数のフィールドに対応します。
デュレーションのアイデアはかなり売れたと思いますが、タッチデバイスの方が速くなるかどうかわかりません。
また、期間のコンボボックスがある理由もわかりません。それは余分なクリックであり、何が入っているのかわかりません。
おそらく、このデザインからいくつかのアイデアを借りたいと思うかもしれません。
ノート：
- あなたは色でより良い仕事をすることができると確信しています。
- カレンダーでは、何とかして返却日を示すこともできます。
How many days?見出しの横に「カレンダーを表示」を追加して、日/カレンダーの選択を切り替えることができます。- 何日か離れた場所にマークを表示すると、返却が視野から外れると、ユーザビリティの問題が発生します（たとえば、このカレンダーの誰かが3月30日に14日を選んだ場合、アウェイ日は4日で終わります1月のビューでは、35日を超える旅行には必ずこの問題が発生します。
- 1ページあたり1か月という現実世界のメタファーがユーザビリティを低下させることは、今ではかなり一般的な知識です。非常に少数のカレンダーウィジェットは、カレンダーがどうあるべきかに追いつきます-継続的にスクロール可能な年（iPhoneのように）。したがって、そのように実装すれば、実際に町に行くことができます。これにより、上記の箇条書きの範囲外の返品の問題が解決されます。
