1. 揮発性の低いものほど人間は安心感を覚える
1.1. 例
1.1.1. 書籍
1.1.1.1. 紙は安定している
1.1.1.2. ページを閉じても中身は消えない
1.1.1.3. 書き込んだ内容も消すまで保存される
1.1.2. X Window System よりも Windows
1.1.2.1. Windows は アプリの 不具合時に ウィンドウが 残りやすい?
2. Web アプリの「戻る」
2.1. 望ましい動作
2.1.1. ジャンル選択から特定の一覧を表示する
2.1.2. 一覧から明細を表示する
2.1.3. 明細を修正する
2.1.4. 「戻る」を押すと一覧に戻る
2.1.5. さらに「戻る」を押すとジャンル選択に戻る
3. クリック/タップのみで使える
3.1. ボタンが見えていて一発でクリックできる方が使いやすい
3.1.1. 多い場合にはドロップダウンで出てくると良い
3.2. 右クリック→メニュー→選択は煩雑
3.2.1. タップの場合には長押しの方が良い
4. 継続・履歴
4.1. 履歴をフル活用する
4.1.1. 再び簡単に選択・表示できるようにする
4.1.1.1. 最近使った選択項目 (取引先) など
4.1.1.2. 以前に表示した詳細画面など
4.2. 自然にフェードアウトする
4.2.1. 最近使ったものほどまた使う
4.2.1.1. Excel を閉じたすぐ後で内容を参照する必要がある
4.2.1.2. Windows のアプリも自然にフェードアウトすればいいのに
4.2.1.3. Excel を開いたままで、最後に使ってから 10 分経ったら自動的に閉じる、など
4.2.2. 消えないが 一覧から 見えなくなる
4.2.2.1. すべてを 見ることも できる
4.2.3. 例
4.2.3.1. iPhone のアプリ
4.2.3.1.1. バックグラウンドにする
4.2.3.1.2. メモリーが足りなくなると自動終了される
4.2.3.1.3. 必要に応じて自動的に保存される
4.2.3.2. 最近使った項目の一覧
4.2.3.2.1. 古いものは一覧から消える
4.2.3.2.2. すべての一覧には入っている
4.3. 開いた時に閉じた時の状態に戻れる
4.3.1. Foxit J-Reader は開くと読みかけのページが表示される
4.3.2. Readability もページ中の読んでいる場所が表示される
4.4. デフォルトで最近のものが表示される
4.4.1. 初期画面として
4.4.1.1. 条件を指定しなくても表示される
4.4.2. 最近のものが上になるように
4.4.2.1. 時系列の逆順で
5. Web アプリは柔軟な UI を作成できる
5.1. 例
5.1.1. 支払条件
5.1.1.1. 選択肢
5.1.1.1.1. 全額現金
5.1.1.1.2. 現金と手形
5.1.1.1.3. 現金と手形とその他
5.1.1.2. 選択肢によって入力可能な欄 (テキストボックス) が柔軟に現れたり消えたりする
5.1.2. リスト項目の 編集
5.1.2.1. 編集ボタンの 数
5.1.2.1.1. 1 つ
5.1.2.1.2. 複数
6. UI には ヒント情報を 出す
6.1. UI の 影響に ついての 情報を ユーザーに 提供する
6.2. 例
6.2.1. タイマーに ON / AUTO という スイッチが あったとき
6.2.1.1. ON
6.2.1.1.1. 常時運転
6.2.1.2. AUTO
6.2.1.2.1. タイマーに 従って 運転
7. 普段は シンプルに, いざという時は 詳細に 設定 できる
7.1. 例
7.1.1. 普段
7.1.1.1. ワンクリックで 既定のプリンタに 印刷される
7.1.2. いざという 時
7.1.2.1. プリンタや トレイ, 倍率を 変更して 印刷できる
8. 編集画面を 閉じる時には 常に 保存する
8.1. 操作が シンプルに なる
8.2. 内部状態と 表示が 一致する
8.3. 選択肢
8.3.1. ×
8.3.1.1. 保存して 閉じる / 保存しないで 閉じる
8.3.2. ○
8.3.2.1. 保存して 閉じる / リセット
8.3.2.1.1. 開く 前の 状態に 戻したい 時の ために, リセット 機能を 用意する
8.3.2.1.2. リセットは 画面遷移しない
9. WebアプリはJavaScriptに頼りすぎないようにする
9.1. 他のページにフレームで入れられるようにする
9.2. 単純なブラウザでも使えるようにする
10. ファイルではなくドキュメント
10.1. ユーザーに生ファイルを見せない
11. Web アプリは "ドキュメントに編集ボタンが付いている" ように作るとよい
11.1. アプリとして作ると制御が難しく, 他のアプリと組み合わせにくくなる
11.1.1. 例: 仕入伝票を表示する画面は ドキュメントとして単独で表示できるようにしておくと 集計アプリから呼び出して表示したりしやすい
11.2. 本来 HTML はユーザーインターフェイスではなく ドキュメントを表現するために作られた
11.2.1. 「戻る」で入力データが消えてしまう フォームはいらない － ＠IT
11.3. ドキュメントとして考えることは REST との親和性が高い
11.4. 検索結果は "検索結果が一覧で載っているドキュメント" として扱う
11.4.1. キャッシュができる
11.5. 構造を HTML で, 見た目を CSS でという役割分担に従う
11.5.1. "編集を JavaScript で" と拡張できると良さそう
12. GUI は CUI のラッパーとして使うのがよい
12.1. UNIXとかの直交性と多様性、とか
12.1.1. GUIなソフトはどうにも肥大化しすぎていて, アプリケーション同士のつながりも作りにくい
12.1.2. GUIはCUIのラッパーという使い方が一番有用なんじゃないかな
13. 究極の形はフロー UI なのかも
13.1. 古くて新しい"フロー"UI - .mjtの日記復帰計画
13.2. 上から下に流れる対話式の UI
13.2.1. 情報が対話的に時系列に (流れるように) 表示される
13.2.2. 表示された情報と対話できる
13.2.2.1. 例
13.2.2.1.1. Mathematica のノートブック UI
13.2.2.1.2. Google Chrome の Developer Tool
14. 電話越しに相手が操作できれば使いやすい
14.1. 電話越しに使えれば, シンプルでわかりやすい UI になっている
15. 3 歳児でも使える
15.1. iPhone は 3 歳児でも使える
16. Web の一覧, 詳細, 編集画面
16.1. Doit.im の例
16.1.1. 一覧表示
16.1.1.1. タスクを一覧で表示
16.1.1.2. チェックボックスのみ操作可能
16.1.1.3. タスク名クリックで詳細画面へ
16.1.1.4. コンテキストメニューの [編集] で編集画面 (オーバーレイ表示)
16.1.2. 詳細画面
16.1.2.1. メニューの [編集] で編集画面 (オーバーレイ表示)
16.1.3. 編集画面
16.1.3.1. オーバーレイ表示される
16.1.3.1.1. 独自の URL を持たない
16.1.4. 画面の URL
16.1.4.1. 持つ
16.1.4.1.1. 一覧画面
16.1.4.1.2. 詳細画面
16.1.4.2. 持たない
16.1.4.2.1. 編集画面
16.1.4.3. ブラウザの "戻る", "進む" では表示画面のみ移動する
16.1.4.3.1. 「フォームを再送信しますか?」というようなメッセージを回避できる
17. 「リロードするまで現状待機」型UIの利点
17.1. はてブの星
17.1.1. 付けた直後は画面遷移せず, 末尾に星が増える
17.1.1.1. そのままの画面で操作を続けられる
17.1.1.2. つけた星をすぐ消せる
17.1.2. リロードすると他の星と同様に組み込まれる