はじめに
UI設計を行う時に心がけるルールの一つとして、UI Stackという考え方があります。この考え方はこの記事で紹介しました。この記事ではこの考えを活かして実際に開発を行ってみます。
実装のためリにReact、Material UIを採用しています。この記事ではUI設計についてのみを話題にするためこれらの実装については一切触れませんので安心してください。実装された内容に興味のある方はCodeSandboxで実装を確認してください。
作成するアプリ
タイトルで既に触れていますが、ToDoリストを作成します。
最低限の機能として以下の6つを実装します。
- タスクの追加
- タスクの完了
- タスクのお気に入り
- タスク一覧の表示
- 完了したタスクも含めた一覧の表示
削除機能があっても良いですが、デフォルトではタスクの完了と同時にタスクを非表示にするのでこの記事では考えないものとします。
Ideal State
まずはこのアプリの理想的な状態を考えましょう。このアプリにおいて理想的な状態とはいくつかのタスクが存在していてその中にお気に入りのタスクがあったり完了済みのタスクがある状態です。
Error State
このアプリでエラーを発生するケースは1つしかありません。追加するタスクのテキストに対するバリデーションです。タスクの追加を行うときに文字数が空もしくは31文字以上であればエラーメッセージを表示するようにします。エラーが発生したときの挙動は以下のようにします。
エラーが起きている場所をわかりやすくするためにラベルとテキストフィールドの色を変更し、テキストフィールドの下にはエラーを解決する助けとなるようなメッセージを表示するようにしています。一度エラーが発生したらそれが解決するまでボタンは無効になるようにしました。
また、エラーが発生することを示すのはボタンを押してからだけではなく、30文字を超えて入力があった場合は動的にエラーを表示するようにしました。今回入力する部分は一つなので恩恵は薄いですが、送信してから修正することに比べて手戻りが少なくユーザーの助けになりやすいです。
さらに、ボタンを押してバリデーションに失敗した場合でも値は残すようにしました。
Partial State
私はこのアプリにおけるPartial Stateは存在しないと考えているので設計しません。このようにアプリを作成する中で必要のない状態も出てきますが、最初にその状態が必要かどうかを考えることは重要なので忘れずに行いましょう。
Loading State
タスクを読み込んで表示する必要があると仮定すると、読み込み中の状態が必要となります。画面全体にSpinnerを配置するのもこの規模で話ではないですがここではタスクの読み込み、書き込みを行う部分のみを読み込むような設計にします。
このようにすることでLoading中にタイトルを見てこの画面はどのような画面かユーザーが理解することが可能になったり、完了したタスクを表示にするか、非表示にするかの決定を行うことができます。
他にも今はサーバーとの通信を行っていませんが、サーバーとの通信を行う必要があっても画面上ではタスクのお気に入り、追加、完了の即時反映を行って裏側でサーバーの通信を行うようにすることでユーザーにストレスなくアプリを利用させることができます。
Blank State
最初からダミーデータとしてタスクをいくつか表示させて置くことで、初期利用時にデータが空になることを防ぐようにしました。ユーザーがこれらのデータの扱いに困るケースが考えられるので得策ではないですが、どのように利用すれば良いか理解できるという点では有利に働きます。実際に出荷するアプリで採用するときはダミーデータとわかるようなデータを作るのが良さそうです。
完了したタスクを表示しないとき、全てのタスクが完了して表示するデータが空になったときにはユーザーに対して賛辞を送るようにしました。完了したことで次の行動のイメージがわかないユーザーのために簡単な説明も表示しています。
成果物
こうして作成されたのが以下のアプリケーションです。
データの読み込みを5秒間行うように大袈裟に実装してLoading状態を表示できるようにしました。他は説明の通りです。