ユーザビリティとアーキテクチャ
これは、前回のエントリ Developer Usability(2008-06-25 - ソフトウェアスペシャリストへの道)の続きである。このエントリでは、実際にソフトウェアを利用するエンドユーザにとっての使いやすさ(End User Usability)は、アーキテクチャで制御することはできないのではないか。というのが私の結論だった。
この疑問に対して、次の本を引っ張りだして確認してみたところ、「ある意味」明確な解が述べられていたので紹介しよう。
- 作者: Len Bass,Rick Kazman,Paul Clements,前田卓雄,加藤滋郎,吉野圭一,佐々木明博,新田修一
- 出版社/メーカー: 日刊工業新聞社
- 発売日: 2005/10
- メディア: 単行本
- 購入: 1人 クリック: 33回
- この商品を含むブログ (13件) を見る
4.2 アーキテクチャと品質特性
使いやすさには、アーキテクチャ的な側面と、非アーキテクチャ的な側面が必要である。非アーキテクチャ的な側面には、ユーザインタフェースをわかりやすく、そして使いやすくすることが含まれる。ラジオボタンや、チェックボックスを提供するべきか。どのような画面レイアウトが最もわかりやすいのか。どのような書体が最も見やすいのか。これらの詳細は、エンドユーザに対して大きな問題となるし、使いやすさには影響を与えるものではあるが、それらはアーキテクチャに関するものではなく、設計の詳細に関するものである。しかし、ユーザに対して、操作をキャンセルする機能、操作を元に戻す機能、あるいは以前に入力されたデータを再利用する機能をユーザに提供するかどうかは、アーキテクチャに関する問題である。それらの要求の実現には、多くの要素の協調が必要である。
この節は「アーキテクチャと品質特性」と題されているが、品質特性とはいわゆる非機能要件のことである。アーキテクチャ的と非アーキテクチャ的とは、それぞれ非機能的と機能的と読み替えても良いだろう。*1
つまり、ユーザビリティ(使いやすさ)に関してはアーキテクチャで制御できるものとできないものがあるという。なるほど。僕は、これらを二者択一しようと考えて悩んでいたのだが、そもそも「あいまい」というかキッチリ線を引くことができないという。そうなると、僕の出した結論もあながち間違いではないらしい。
この本も購入してから結構時間が経つのだが、今までリファレンス程度にしか読んでいなかった。実はこの章も読んだつもりだったのだが、全然頭に入っていないことが判明した。うーん。。。
また、僕の中で「アーキテクチャ」というものの定義を明確にでないことも明らかになった。いろんな言い回しを駆使して説明できないことはないのだが、これという自信を持って説明ができない。もちろん「アーキテクチャ」とはソフトウェアアーキテクチャを指すのだが、この用語にはいろいろな定義がなされているため、自分の言葉で説明するとどうなるのかを今後のエントリのネタにしてみようと思う。
なにかがおかしい
今日のニュース。奈良県大和郡山市で「１７歳の長男がおのとナイフで父親殺す」という事件があった。普段なら「怖い」と思って終わりだったのだが、この事件の舞台は僕の地元なので、いつもよりリアルに「怖い」と思った。
秋葉原の事件といい「なにかがおかしい」。
僕の子供たちが通う幼稚園の先生が言っていたことだが、今の子供たちも「なにかがおかしい」らしい。例えば、園児がひとりひとり育てたアサガオが花開いたので「お花が咲いたよ！」と呼びかけたところ「面倒くさいからいい」という園児がいたそうな。もちろん、これだけの理由ではなく、いろいろあったことが積み重なって「なにかがおかしい」と感じておられるのだろう。因みに、この先生はベテランで信頼できる方である。
この「なにかがおかしい」状況を救うには、どうすればよいのだろうか。
マザーテレサは、ノーベル平和賞を受賞したときの会見で「世界の平和のために私たち一人一人にできることはありますか？」という問いに「家に帰って、あなたの家族を大切にしてあげてください」と答えたそうだ。
僕がまずやるべきこと、そして、できることは「子供たちに愛情をもってちゃんと教育する」これしかないように思う。
Alternative
僕はHHKキーボードを愛してやまないのだが、自分の手に慣れ親しんだツールにこだわるのは何もエンジニアだけではない。和田先生のアメリカ西部のカウボーイ話ではないが、自分の使いたい道具、インタフェースを使うよろこびは誰にでもあるだろう。
僕は、ブラウジングはIEではなくFirefoxを使いたいし、テキスト編集はviよりもemacsを使いたい。そう、UNIXのEDITOR環境変数や、Debainのalternativesのようなものは、Androidに置いてもほしい機能である。
前置きはさておき、このAlternativeな仕掛けっぽいことをAndroidで実現できないか調べてみると、android.intent.category.ALTERNATIVEカテゴリを利用することで「やんわり」と実現できる。「やんわり」とは、完全に僕のイメージを満たすものではないが、まぁ、ギリギリセーフかもしれないけれど、やっぱりアウトかな。というニュアンスを表現してみた。
The offering application
The application offering the service must include an
element in the manifest, inside the tag of the offering Activity. The intent filter includes all the details describing what it can do, such as a element that describes the MIME type of data that it can handle, a custom value that describes what your handling application can do (this is so that when it receives the Intent on opening it knows what it is expected to do), and most important, include a filter with the value android.intent.category.ALTERNATIVE and/or android.intent.category.SELECTED_ALTERNATIVE (SELECTED_ALTERNATIVE is used to handle only the currently selected element on the screen, rather than the whole Activity intent.
Android Developers | Android Developersより引用
これは、Activityを呼び出すときに複数のActivityから1つを選択できる機能である。例えば、VimとEmacsの2つのエディタがインストールされており、ユーザがテキスト編集したいときにどちらか好きなエディタを選択する。というような場合に使えるのではないだろうか。
ここで、EditorLauncher, AndroidEmacs, AndroidVimという3つのActivityを例にあげて説明する。EditorLauncherは、文字通りエディタを起動するActivityでLunchボタンを持っている。このLaunchボタンを押下すると、使いたいエディタ(AndroidEmacs or AndroidVim)をユーザが選択し、どちらかを起動するというものである。
まず、AndroidEmacsとAndroidVimのAndroidManifests.xmlを見てほしい。
- AndroidEmacsのマニフェスト
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.mamezou.android.editors.emacs"> <application> <activity android:name=".AndroidEmacs" android:label="AndroidEmacs"> <intent-filter> <action android:name="android.intent.action.EDITOR" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.ALTERNATIVE" /> </intent-filter> </activity> </application> </manifest>
- AndroidVimのマニフェスト
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.mamezou.android.editors.vim"> <application> <activity android:name=".AndroidVim" android:label="AndroidVim"> <intent-filter> <action android:name="android.intent.action.EDITOR" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.ALTERNATIVE" /> </intent-filter> </activity> </application> </manifest>
このように、android.intent.category.ALTERNATIVEカテゴリを両方に設定することで、次のようにIntentがブロードキャストしたときにフィルタ条件が一致するActivityの選択画面ダイアログをAndroidが自動的に表示してくれるのである。
public class EditorLauncher extends Activity {
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
setContentView(R.layout.main);
Button le = (Button) findViewById(R.id.launch_editor);
le.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View arg0) {
Intent intent = new Intent("android.intent.action.EDITOR");
startActivity(intent);
}
});
}
}
僕はこんな機能があることは知らなかったし、ググっても案外でてこないので書いてみた。
Developer Usability
In contrast to common belief, architecture is not only about functional requirements and operational qualities. It is also about usability. A system that meets all requirements but is not usable, is of no value for its users. As an example: I owned Rio and Creative MP3 players which provided an incredible amount of features, but lacked usability. After a while I switched to Apple IPods which have less features and are significantly more expensive but offer a great user experience.
- 意訳
アーキテクチャは、なにも機能要件や運用上の品質だけではない。ユーザビリティもアーキテクチャである。すべての要求を満たしたシステムであっても、使いにくいシステムはそれを利用するユーザにとってなんの価値もない。例えば、私の持っているRIOとCreativeのMP3プレーヤーは、かなりすぐれた機能を含むが、ユーザビリティが欠落している。対して、AppleのiPodは、機能は少ない上、明らかに高価だが、すぐれたユーザエクスペリエンスを提供する。
この引用だけでは文脈が伝わらないが、ここでのユーザビリティはUIに限ったものではなく、APIなども含んでいる。確かに、使う立場に立ったもの作りは基本としてわすれてはならないし、いつも心がけているつもりだが、ちょっと疑問に思ったことがあるので書いておく。
僕は仕事でよくアプリケーションアーキテクチャ構築の支援をするのだが、例えばフレームワークを作った場合、ユーザにあたるのはその「フレームワークを使ってアプリケーションを開発する人」である。なので、ユーザビリティというのは、実装手順がシンプルでわかりやすい、とか、エラーハンドリングのような横断的な関心事はできるだけ意識しなくてよいといったことになるのだろうか。また、アプリケーションを開発する人にとってのユーザは「アプリケーションを利用する人(エンドユーザ)」となるため、ユーザビリティ＝UIの使いやすさ というのがピンとくる。
では、アーキテクチャにとってのユーザビリティとは何だろうか。Stalさんの言うとおり、ユーザビリティもアーキテクチャの要素であることはわかっているつもりだが、よく考えると「あれ？」と思った。例えば、エンドユーザに対するユーザビリティ(UIの使いやすさ)の向上を目指したとしても、アーキテクチャでがんばれることは、リッチなWebのUIを実現するためにAjaxを取り入れたりすることぐらいなのかもしれない。つまり、いくらよくできたアーキテクチャであっても、エンドユーザが利用しやすいUIを実現できるわけではない。言い換えれば、アーキテクチャとUIの使い勝手は直交しているのだろうか！というのが今日の発見だった。
本題にもある「Developer Usability」は文字通り、開発者に取ってのユーザビリティなのでアーキテクチャで十分サポートできる範囲だが、「End User Usability」は、アーキテクチャによって直接的に良くなったり、悪くなったりするものでもないということだ。
iconvライブラリではまったこと。
Rails-1.2.6で、ActionMailerを使って日本語(iso-2022-jp)でメール送信する場合は次のようにすればよいのだが、僕の環境では長〜〜い本文を送ろうとするとエラーになるという現象が発生した。
class Notifier < ActionMailer::Base
def greeting(sent_at=Time.now)
@recipients = "宛先メールドレス"
@subject = "=?iso-2022-jp?B?#{Base64.encode64('グリーティング'.tojis)}?="
@body = render_message('greeting', {}).tojis
@from = "送信元メールアドレス"
@sent_on = sent_at
@headers = {}
end
end
エラー内容は「Iconv::BrokenLibrary」と言っている・・・ 明らかにiconvライブラリがあやしい。
このときの僕のRails開発環境は次のようなもの。
- Windows XP SP2
- Ruby 1.8.6-p115-mswin
- Rails 1.2.6
- Libiconv DLL 1.10-20060516 for Windows (香り屋 — KaoriYaさんのがらくた置き場より)
で、この問題は同じく香り屋 — KaoriYaさんのがらくた置き場より「Libiconv DLL 1.9.1 for Windows」をダウンロードしてiconv.dllを置き換えれば解消した。
短い日本語の文章ならば、iconvの1.10でもうまく送信できるので最初は狐に包まれた感じだった。
懐かしのSKID ROW 〜Slave to the Grind〜
昨日、近くのTSUTAYAが半額デイだったのでよってみたら、SKID ROW(スキッドロウ)が目にとまったので思わず衝動借りしてしまった。
- アーティスト: Skid Row
- 出版社/メーカー: Atlantic / Wea
- 発売日: 1994/06/17
- メディア: CD
- クリック: 3回
- この商品を含むブログ (14件) を見る
SKID ROWは、僕が高校時代に聞きまくっていたハードロックバンドで、このアルバムはかれこれ14年前の作品となる。たぶん、SKID ROWで一番売れたアルバムなんじゃないかなぁ。とにかくかっこよかった。というか、再度聞いてみるとやっぱりかっこよかった。
TSUTAYAには、僕の聞いたことがないSKID ROWのアルバムが他にもいくつがあった。実は、大学からはハードロック／メタルバンドからちょっと卒業しようと思い、このアルバム以降の作品は聞いたことがないのだ。
貧乏性の僕は「聞いたことがあるアルバム」と「聞いたことがないアルバム」があれば、迷わず「聞いたことがない」方を選ぶことが多いのだが、あえて穴が開くほど聞いたこのアルバムだけをレンタルした。
この心境を言葉ではなかなか表せないのだが、その夜のTV番組で向田邦子先生の「深イイ話」がぴったりだったので引用しよう。
ムキになって確かめない方がイイ思い出もある。
何十年とかかった懐かしさと期待で大きく膨らませた風船を、
自分の手でパチンと割ってしまうのは、もったいない…
