その画面は使いやすい?

画面を作ってテストしているとき、「使いにくいなぁ」「うぜぇ」と思う一瞬があると思います。
この一瞬の閃きを逃してはイケマセン。
作っている人間が「使いにくい」と思うのなら、使うユーザは、もっと「使いにくい」と思うはずです。
使いやすいようにとっとと直してしまいましょう。

誰が、何のために使うのか?

詳細設計から実装の段階に入ると、ついつい忘れがちになってしまいます。
今作っているものは、
・誰が使うのか?
→どんなユーザなのか?自分の親ぐらいのエンドユーザなのか?それともシステム管理者なのか?
・何のために使うのか?
→どういうことをしたいのか?どんな時に使うのか?
→何をするために、このアプリを、或いはこの画面を使うのか?
場所によっては、「ユーザシナリオ」と言われることもあります。
要するに、報告書の”5W1H”見たいなモンでしょうか。これらの要素は、ついついお留守になってしまいがちです。
なので、時々、基本設計なり概要設計なり、そういうフェーズに立ち戻ってそれらを思い出す必要があります。
これを完全に忘れたまま作ってしまうと、
・誰も嬉しくない代物が出来上がる(最終的にディスクの肥やしアプリと化す)
・ユーザレビューやら総合試験やらでボッコボコにされる(大炎上!)
とかとか、そういう事態になってしまいます。

正解を知らなければ設計すらできない

プログラム(でもアプリケーションでも何でも)を一つの「箱」としてみる時、必ずInとOutがあります。中には

[VB.NET]
Public Sub Something()
End Sub

などというわけの判らん代物もありますが、そういうネタ的事例はおいておきます。
で、そのInが何で、Outが何かを知らなければ、設計も何もあったものではないわけです。
Outはこのテーブルだ。
それは良いでしょう。
じゃぁ、各カラムにはどんな値を設定するのか?検索条件は?InsertなのかUpdateなのか、それとも…
設計する以上は、少なくともそこを熟知しなければいけないわけです。むしろ、それが設計ってモンだろ-ってな程です。
で、期待するInとOutを元に、テストを作り、モノを作るわけです。
#なんで今更こんなことを書いているのかというと、今日、そういう類の事件が起きたもので…。「ここでこういうデータが出来たけど、正しいですか?」って、設計したのはオマエだろ!!と、怒鳴りつけたくなる衝動を抑えるのに苦労しました。

仕様の誤りは仕方がない

仕様は人間が決めて、他の人間に伝えるものです。
したがって、仕様は伝言ゲームとなり、その過程でどうしても変わって行ってしまいます。
これは、人間対人間の作業である以上、仕方のないことです。
そこは敢えて、サッパリあきらめてしまいましょう。
誤りの有無を短い周期で確認することによって、手戻りを小さく。
誤りを前提として変更しやすくすることによって、修正工数を小さく。
特に後者は、「ここ違うんだよね…」といわれても瞬殺できるような構造にしておくと、多少の仕様変更は怖くなくなります。
それがどこか…というのは、多分に嗅覚=経験の問題となります…。
※だからと言って、何でもかんでも”.config”に逃がせばよいという話ではありません。念の為。

用済みなら処理しない-ASPネタ

一覧とか検索とか、重くなりがちな処理があります。
でもって、利用者も利用者で、気が変わったとか間違えたとか、処理終了前に閉じたり、戻ったり、違う操作をすることがあります。
でも、ウッカリすると、バックグラウンドの重い処理は動きっぱなしで、全体のパフォーマンスに影響します。
それを防ぐには、「もう用済みではないか?」というのを聞いておけばよいわけです。
Response Object の中に、IsClientConnected というプロパティがあります。これがTRUEなら「まだ入用」、FALSEなら「用済み」。
で、「用済み」といわれたら、「やーめた」といって、処理を打ち切ればよいわけです。
そんな重い処理を作らないのが大前提でしょうが、そうもいかない時には結構使えるテです。
ASPでもASP.NETでも使えます。

でも、テストはきちんと

設計・実装担当をやっていると、過分のお褒めに預かることも稀にあります。
しかし、だからといって、テストを省略、あるいは短縮しないでください。それとこれとは別のハナシです。
同じバグでも、テストで発見されるほうが、リリース後に発見されたほうが良いに決まっています。そして、どんな設計者・実装者でも、必ずどこかにバグを作ります。
それを見つけるのも、テスト担当の仕事です。

何のための画面?

画面設計とかの際に、「この画面は何の画面?」といいたくなるときがあります。
なんでもかんでも、ごちゃごちゃと詰め込みすぎて、情報が散乱してしまっているようなページです。
そういう画面では、おそらく、ユーザの視線はあっちへうろうろ、こっちへうろうろ。かなりさ迷い歩くことになると思います。
そして、機能の習得にも時間がかかり、かなり厳しいことになると考えられます。
そういうことにならないために、「この画面は何がしたい画面なのか?ユーザは何が嬉しくてこの画面を開くのか?」と考えると、すっきりいくことが多いようです。
また、「何が嬉しいのか?」が判ったら、それを促進する、少なくとも妨害しないようにする事が必要です。
例えば、投稿記事詳細画面では、投稿された記事が読みたいのであって、スポンサーの広告が読みたいのではありません。
このように妨害されると、ユーザはかなりイラつくことになると考えられます。
おそらく、その辺りを包含した用語が「エクスペリエンス」なんでしょう(推測)。

直感的UI

UI-ユーザインターフェイス-は直感的であるべきです。
マニュアルを読まなくてもある程度使いこなせる事をもって最上とすべきです。
たとえば、MacOS (OS9以前)の Finder システムはその最たるものと思います(突っ込みポイントはありますが)。
で、ここでは MacOS vs Windows vs X をやりたいわけではなく、アプリケーションUIの設計の話です。
アプリケーションとしてはユーザが
・今何をしているかが理解できる
・次に何をするべきかが理解できる
そんなUIを目指すべきと思います。
トリッキーな操作や、何処を見れば解らないステータス表示。こういうものは、可能な限り避けるべきです。
直感的に操作できるUIを作っておけば、ユーザマニュアルの作成は楽になります。そして、このユーザマニュアルは、往々にして後回しにされ、ないがしろにされがちな「ドキュメント類」納品物です。
マニュアルがないと使い物にならないUIだと、ないがしろにされた「ドキュメント」に対して矢のような催促が来るか、サポート依頼が大量に来て、更に首を絞めることになります。
良いUIを作っておくことで、後々楽ができるというわけです。

それをエンドユーザに押し付けますか?

例えば住所の「番地」を入力するテキストボックス。
これに半角を入れると怒られる訳ですよ。
これ、「できる」シリーズを片手にひーひー言わされている初心者ユーザに判ります?”1″と”1”。ぱっと見て理解できます?
番地を全角で格納したい、電話番号を半角で格納したい。
それはシステムの都合です。それをエンドユーザに強制しないでください。確かに、技術的に「できるけど引き合わない」事があるのはわかります。しかし、全角半角変換ですよ!少なくとも半角→全角はStrconv一発呼べば終わりじゃないですか。
どうなんでしょうかねぇ…。

視点が違えば意味も違う

かつて、別の項(8/24のblog)でも書きましたが、世間的に定義の定まっていない術語を使う際には、十分な注意が必要です。
それと同様に注意が必要なのが、関心のありようによって意味が違うように解釈できる術語です。
その良い例が、「フレームワーク」(Framework)という語です。
.NET Framework とか J2EEとか 、いろいろありますが、それは「アプリケーション-プラットフォーム」間という意味で見た場合の「枠組み」です。
さらに一階層視点を変えてみると、Application Blockとか Enterprise Library とか Struts とか。これらも、違う立場=関心を持つ「枠組み」です。
さらに、違う視点で眺めると、これらのさらに上位にあるものをさす場合もあります。
これらの視点が異なっていれば、当然のことですが、話は通じません。ですから、まずはそれを明らかにしないと、話はすれ違いで終わります。
話が撚れていると思ったら、その辺りを疑ってみるのも良いでしょう。
——————–おまけ——————–
なお、先ほど出した例ですが、建築にたとえるとわかりやすいと思います。(単に比喩であり、それ以上の意図はありません。また、この比喩が正確であるかの保証もいたしかねます。)
・.NET Frameworkなど:建築学一般(物理学、地理学などとの橋渡しを含めて…という枠組み)
・Enterprise Libraryなど:商業ビル建築一般(建築学からさらに特化して)
・各アプリケーション:個別のビルの設計思想(個別に特化した状態)
・各機能:基礎、構造、外装、内装など…(更に細分化された状態)
と、考えると、イロイロと判りやすいと思います。