Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 26/248: « 22 23 24 25 26 27 28 29 30 »

三宅島に行ってきた(三宅島でダイビング体験編) - Sep 30, 2011

船酔い地獄の次の日は、朝から体験ダイビングをやって、昼過ぎの船で東京に帰る(到着は深夜)というスケジュールでした。

ところで、三宅島は車があればすぐに島全体を一周できるくらいの大きさではあるけれども、各スポットがかなり離れているので、徒歩であちこち歩き回るのはさすがに無理です。それに、島内はバスが走ってるんだけど、三宅島1日目の夜になってから知ったのですが、その宿の最寄りのバス停の最終時刻はなんと17時台(ということは、どこに行くにせよ17時頃には帰ってこないといけない)。なのでレンタカーか何かがないとどうにもならない。この辺は、普通に車社会な田舎と同じですね。

が、直前までスケジュールが確定できなくてバタバタしてたせいでレンタカーを予約しそびれてしまってて、島に着いてから問い合わせたらもう全部予約で一杯だと言われてしまいました。これは痛い。

……という事を海猿隊の方に送迎してもらう時の車中で話していたら、提携してるホテルに連絡して下さって、ホテルのレンタカーを貸してもらえる事になったのです。言ってみるもんだね! というか、これに限らず海猿隊さんには柔軟に対処してもらえすぎて超助かりました。(宿もそう。海猿隊は提携先のホテル海楽に宿泊する前提でドルフィンスイムとかのプランを提供してるんだけど、彼女が問い合わせた時にはすでにホテルがどこも満室で、それで海猿隊の方で民宿(海猿隊のショップのすぐ近くにある、つくばという民宿でした)を手配してくれて、宿に困らず三宅島で寝泊まりすることができた。ありがたい。)

そういうわけで、体験ダイビングが終わったら車でどっか行くという事で、宿は朝の時点でチェックアウトする予定になってました。そしたら朝食の時に宿のおかみさんが御土産にと生のアシタバ2束を持たせてくれまして(スーパーで売ってるホウレン草みたいな感じをイメージして下さい)。宿で出た食事もアシタバの天ぷらがあったり刺身の下に敷いてあるのがアシタバだったりという具合で何かとアシタバが出てきてた(アシタバは三宅島の特産品の1つなんだそうです)ので、土産にまでアシタバ!と、彼女と二人で笑ってしまいました。ちなみにこのアシタバは帰ってから茹でてあく抜きをした後、炊き込みご飯に入れたりシーチキンと混ぜて醤油を加えて和え物にしたりして食べてますが、まだあります。あとどうやって食べようか……

アシタバの話は置いといていいかげんにダイビングの話をしましょう。

ダイビングは、扱いに注意が必要な機材を色々使うのと、潜るという行為の中で色々と注意が必要なのとで、素人がさっと行ってさっと潜るという訳にはいかないようです。講習を受けて認定証(いわゆるライセンス)を取得しないと、ショップに行っても門前払いなんだそうです。しかしディスカバーなんちゃらというプログラムに従ってインストラクターの指示に従う形でちょこっと潜るのであれば、ライセンスがなくてもダイビングできるのだそうです。なので、この日はそのコースでちょっとだけ潜らせてもらいました。

前日の船酔いゲロゲロで、小型船はもう勘弁して!!!!という事で怯えてたんだけど、何のことはない、前日午前中の練習の時と同じ港でやるのだとの事でした。安心した。

ハンドサインのおさらいをして車で出発し、港に着いたら今度は実際の装備を見ながら「このボタンは押しちゃダメ」という話を色々聞いてから、いよいよフル装備になりました。そこで初めてダイビングのフル装備を体験したんですが、空気ボンベの重い事重い事……しゃがんでいる所にインストラクターさんに背中から背負わせてもらってそこから立ち上がろうとするのですが、人一人背負ってるような重さでフラフラしてしまい、彼女に至っては本気で立ち上がれない様子でした。海に入ったら気にならなくなるんだろうなあと思うと同時に、その後揚がる時がまた辛そうだなあとも思うわけで、やっぱりダイビングも体力勝負なのですね。

海に入る時はハシゴに捕まりながらちょっとずつ潜っていったのですが、途中で何度も耳が痛くなって、その都度耳抜き(水圧で鼓膜が耳の内側の方に押し込まれて痛くなってくるのに対して、鼻をつまんで息を勢いよく吹こうとする事で内耳の気圧を高くして押し込まれた鼓膜を元に戻す事)を試みたもののどうもうまくいかなくて、水底に着いてもしばらくパニックになってしまいました。事前に聞いてても、これは非常に焦ります。

でも、ちょっとずつ耳の痛いのが楽になってきた(耳抜きに成功したのか、耳の中に水が入ってきてしまったのかわかんないけど)のと、シュノーケリングの時と違って水中でも深呼吸できる(ダイビングでは残圧を気にしないといけないけど、今回の体験ダイビングだと潜ってる間に空気が切れる事は絶対無い、もしそんな事になったらインストラクターとして大問題になってしまうくらいだ、と事前に聞いていたので安心して空気を吸えた)という事から、だんだん焦りがなくなってきてリラックスできるようになってきました。

そうなると周囲を見回したりする余裕も出てきて、普通に息ができる状態なのに、体が軽くてちょっと一かき一蹴りすれば上に行ったり下に行ったり前に進んだりどこにでも行けるという自由さがあって、だんだん愉快になってくるんですね。僕は平泳ぎで空を泳いで飛ぶ(?)という夢をよく見るのですが、まさにそれと同じ。「空を泳ぐ夢」では当然自由に息ができるわけで、それに対して普通に水の中で泳ぐと息が苦しいわけで、泳ぎつつ息ができるというのは、初めてのはずなのによく知った感覚だなあ……と思ってしまいました。現実なのに夢の中みたいで、すげー面白かったです。

これは彼女が撮った写真。手前が僕で、奥がインストラクターさんです。

いやもうほんと何度でも書くけど、安心して息ができるって大事ですよ。焦ったり不安になったり痛かったりしても、深呼吸したらちょっと落ち着くじゃないですか。前日のシュノーケリング練習でも、疲れて水面に仰向けでぷかぷか浮いて休憩しましたが、波が顔にかかると息ができなくなるという恐怖であんまり安心できませんでした。でもこの日はレギュレーターを咥えてる限りは全然楽に息ができた(噛むとスプレーみたいに空気が吹き出してくるとかそんな感じなのかなー、だったら呼吸するのに練習がいりそうだなー、と不安に思ってましたが、そんなことは全然無くて、普通に咥えて息を吸ったら空気が出てきて吐けば泡になって出ていくので、地上で息をするのと全く同じ感覚なのです)ので、ほんとにリラックスできてました。

インストラクターさんの案内で水底を移動すると、水族館やテレビでしか見た事ないような鮮やかな色の魚が色々泳いでて、「おおおほんまもんやー!!!」とテンション上がりまくりました。昨日は見れなかったけど底の方はこんな風になってたのか! 港の底ってもっと殺伐としてるもんかとばかり思ってましたよ。

これは水底にいた魚(名前忘れた)。右上に写ってる手はインストラクターさんの手です。

ところで、海の中の写真も記念に撮っておきたい!と思って使い捨てカメラの耐水の奴(ビックカメラに行ったら27枚撮りで980円で売られてたので、自分用と彼女用で2個買った。普通のデジカメを入れて使えるケースというのもあったけど、ダイビング用品を扱ってる店で見た時は何万円とか書いてあって目ん玉飛び出たので、今回は使い捨てカメラにした。)を持ってきていたので、ダイビング中は事ある毎にジーコジーコパシャリジーコジーコパシャリと撮りまくってました(このエントリに貼ってある写真は、それを現像したときに一緒にデータ化してもらった物)。でも帰ってきてから現像してみたら、ピンぼけだったりブレてたり見切れてたりと散々な写真ばっかりでした……でかいゴーグルかけてるからファインダーなんて覗いてらんねえよ!と横着したのが敗因だったようです。あと、底が砂地で舞い上がった砂でちょっと水が濁ってたからか、あんまり遠くのものはちゃんと写らないっぽい。次やるときはそこの所に気をつけておきたいです。

そんな感じでしばらく水底を泳いで散歩したあと、最後にインストラクターさんの持ってたデジカメで記念写真を撮ってもらって、誘導されながら一人ずつハシゴに捕まって海から揚がりました。

水から揚がろうとする彼女(奥)とインストラクターさん(手前)。このくらいの距離なら綺麗に撮れてるんだけど。

この時、案の定ですが水から揚がった途端に背中が激重で、ハシゴを昇るのにも結構難儀しました。何分くらい潜ってたのかは分かりませんでしたがほんとにあっという間に終わってしまって、非常に名残惜しかったです。もっと長く潜ってたいし、もっと色々見て回りたかったし……いつかちゃんとライセンスを取ってもっとダイビングを楽しみたいなー、と思った1日なのでした。

……って、まだ終わってないです。朝8時30分に集合して10時台にダイビング終わって、まだまだ全然朝なんですよ(日程が1日短くなってしまったのでちょっと観光する時間を取りたい、と相談したら体験ダイビングの時間を早めに設定してもらえて、それでこうなった)。ここから島を去るまでの間の話はまた次のエントリに書く事にします。

三宅島に行ってきた(三宅島に着いてから編) - Sep 26, 2011

なんやかやあって、23日の早朝に三宅島に上陸できたわけです。三宅島行きは「条件付き出航」扱いで、船が出てても接岸できなければ三宅島を素通りしていた所だったそうなので、運が良かったですよほんと。

1日目の予定はドルフィンスイムというやつで、つまりイルカと遊ぼう的なアレです。三宅島から少し離れた所にある御蔵島周辺には野生のイルカがいるそうで、船でそこまで行ってシュノーケリングで泳ぐという寸法です。

上陸してから海猿隊の方に車で宿まで送っていただいて、仮眠取って朝食いただいて、水着に着替えた頃にまた迎えに来てもらって、下船したのと同じ港でシュノーケリングの練習をやりました。

この時の装備はウェットスーツに足ヒレとシュノーケルとマスク(ちなみにこの時僕が借りたマスクは度付きの物でした。目が悪い人は使い捨てのコンタクトレンズを使うかこういう物を使う必要があります。眼鏡かけた上からマスクをかぶる事は残念だけどできない。)というもので、まずはこれに慣れないといけないのです。イルカは水面近くに上がってくる事もあるけれども、深い所を泳いでいる事も多いので、この装備で深く潜る練習をしないといけないんですね。

それでちょっとやってみたんですが、全然うまくいかないの。あれ、僕ってこんなに泳ぐの下手だったっけ?!みたいな。自分で驚いた。まあ泳いだのなんて下手したら10年単位ぶりかもだから当たり前といえば当たり前かもなんだけど。それに、息が自由にできない事、息が荒くなってしまって焦れば焦るほど水が口の中に入ってくる事、その水がしょっぱい事、ウェットスーツが体を締め付けてきて苦しい事、疲れてシュノーケル付けたまま水面に仰向けで浮いて息をしようとしたら海水を思いっきり吸ってしまった事、水面下が(前日まで台風だったからか)濁りまくってて全く前が見えなかった事、いろんな事が一気にストレスになってパニックになってしまいました。その状態で潜る練習もちょっとやろうとしてみたんですが、水底が全く見えない所で真下に潜ろうとすると怖くて及び腰になってしまってすぐにくるんと横に回ってしまって、そんな事を繰り返してるうちにだんだん目がぐるぐる回ってきてしまったので、途中で上がって横になって倒れてました。波酔いというか海酔いというか、そういうやつになってしまったらしいです。

一緒に練習していた彼女によると、後半は水も澄んできて結構底の方の魚(クマノミとかいたらしい)も見れたらしいのですが、僕はその後結局一度も水の中に戻れずじまいでした。

昼前に一旦海猿隊のショップまで引き揚げて、お昼の弁当を食べた後ちょっと休憩して、いよいよ本番のドルフィンスイムに向かう事になります。僕はこの時一応酔い止めの薬(トラベルミン)を飲んでいきました。

御蔵島までは小型の漁船に乗せてもらうという事で、練習したのとは別の港から出発。

で、港を出たあたりから、もう揺れが凄いんですよホントに。前日にジョイポリスで乗ったアトラクションより怖いんじゃないのってくらいに、激しいアップダウンで揺さぶられる事小一時間。最初の頃は「うひょー!」とか言ってられる余裕もありましたが、座ってる位置が悪かったのか波がばんばんかかってきて前も見えないし息もできないし、相変わらず揺れは続いてるしで、だんだん口数も少なくなっていって。

御蔵島の近くに着いて一旦停まった時には、一緒に参加してた男の人が海にゲーゲー吐いてました。僕もハンパなく気分が悪くなってしまったので横にならせてもらおうと思ったのですが、船の前の方だとみんなが乗り降りするから邪魔になると言われてしまったので、なんとかヨロヨロと後ろの方まで伝って歩いて行ってそこでぶっ倒れ。

その後はもう地獄というか悪夢というか酷い物でした。基本的に、イルカがいる所を船長かインストラクターの人が見つけたら船でそこに向かってみんなで海に入って、イルカが移動してしまったらまた船に戻って次のポイントに移動して、という事の繰り返しなのですが、その度にまた船がぐわんぐわん揺れるわけですよ。横になってるとかもう関係無い。上に下に右に左に断続的に揺すられて、停まってもエンジンのアイドリングで小刻みに揺すられ続けて、結局僕も人知れず船の後ろの方でゲロゲロ吐いてました。

あと辛かったのが寒さ。船が動く度に、風が吹いてくる度に、波飛沫で濡れた体が冷える事冷える事。体がこわばってガタガタ震えて、かといって水の中に入る元気もなく(水温が高めだったからむしろ海に入ってた方が暖かい。でも海に入るためには、倒れてる場所から船の前まで移動してブーツ履いたり足ヒレ付けたりシュノーケル付けたりしないといけない。そして立ち上がったらそれだけでゲロっちゃう)、せめて暖を取りたくて持ってきてたバスタオル等を取りに行きたくても、停まったと思ったらまたすぐ次のポイントに向かって方向転換・発進で立ち上がれず、そんなこんなで寒さに震えながら時折耐え難い吐き気が来た時だけ上体起こして船縁に抱きついてゲーゲーやってました。吐いた物が鼻の方にも入ってそっちから出てきたりもして、自分の吐いた物の臭いと潮の匂いが混ざってなんかよくわかんない臭いがずっとしてました。

そうこうしてるうちに、エンジンが止まって静かになったのを感じました。ドルフィンスイムの時間の終わりです。同行してた人達が戻ってきて、船が停まったのをこれ幸いとヨロヨロ歩いてバスタオルやジーンズ(これも飛沫をかぶっててびしょ濡れでしたが)を回収して、また後ろに戻って倒れてそれらを布団代わりにガタガタやりながら、また帰りの小一時間を堪えてしました。が、その道中も堪えきれずにまた1~2回は吐いたかもしれません。

永遠とも思えるような時間が過ぎた後、気がついたらエンジン音が停まっていて、船が港に着いていました。やっと降りられる……と思って立ち上がったら、またこみ上げてきてゲロゲロゲロ。結局昼に食べたものはこの時までで全部吐いてしまった気がします。下船後もしばらく体調が戻らなくて、僕だけ港のコンクリの上でしばらく横になってました。

うん。もうね、イルカどころじゃなかった。魚に餌をやりに行っただけだった。水面から出る背びれ、を見る事すらできなかった。

唯一の救いは、彼女の方は僕みたいな事にはならずにちゃんとイルカと遊べたらしいということでしょうか。

後で聞いた所によると、こんなに揺れたのは台風の後でまだ波が高かったからで、普段はここまで酷い事にはなってないんだそうです。この時はよっぽど酷かったようで、僕も含めて4人くらいダウンしてたみたいです。ただ、インストラクターの人曰く、こういうタイミングというのは長い間ずっと人が来ていなかったせいでイルカの方が人間を待ち焦がれていて普段よりずっとイルカと出会いやすいというメリットもあるのだそうで(その逆に、人の多い時期はイルカが人と遊び飽きて全然寄ってきてくれないということもあるそうです)、波に耐えられさえすれば絶好のドルフィンスイム日和とも言えるのだそうです。究極の選択ですね。

あと、これも後で聞いた話ですが、トラベルミンは酔い止めの中でもあんまり効かない方だそうで、ダイバーの人は大抵アネロンという薬を使っているのだそうです。成分が違うのか効力が強いのか、他の薬では効かなかった人でもこれなら一発だそうです。次に行く時は僕もアネロンを使ってみようと思います。

港で横になってたらやっと起き上がれそうになってきたので、車に乗せてもらってショップに戻って、ウェットスーツ等を脱いでまた宿まで送り届けてもらいました。

宿に着いた後は夕食の時間まで宿でぶっ倒れてて、ご飯の時間になってなんとかそれを食べて、またぶっ倒れて、気がついたらもう夜も遅くでした。レンタカー借りれなかったからどこにも行けないやというのもあったとはいえ、仮にレンタカー借りれてもとてもじゃないけど他の所になんて行ける状態ではありませんでしたね。

その後、みんなが寝静まった民宿の風呂にこっそり入って、風呂あがりにちょっと宿の周りを散歩してみようとして、明かりが全然なくて怖すぎて逃げ帰ってきて、就寝して、三宅島での1日目が終わりました。

これだけだとあんまりにあんまりなので、彼女が撮ってくれたドルフィンスイムの時の写真を最後に何枚か貼ってお茶を濁してみます。

1枚目。彼女は間近でイルカを見れたそうです。羨ましい!!!

2枚目。水底にいるイルカ。御蔵島の近くは水が青くて、底は岩場になってたそうです。

3枚目。水面近くを泳ぐイルカ。

4枚目。なんか魚の群れ。すごいよく撮れてるなー。

2日目の事はまた次のエントリに書こうと思います。

三宅島に行ってきた(三宅島に行くまで編) - Sep 25, 2011

2泊3日で行くはずだったのが1泊2日になったけど三宅島に行ってきましてん。

事の起こりは9月上旬、「海に行きたい!」と彼女が言った事でした。

例によって毎年8月上旬はコミケのために時間が潰れ、お盆を過ぎると一般的にはクラゲうじゃうじゃになってしまって海水浴なんかできないんじゃないのという感じで(思い込みならすみません)、今年も海だの何だのは無しだったなあ……と思っていた所での急な話だったので、正直「えっ、今から行くの?」と思ってしまったのは事実です。が、彼女の調べによると例えば三宅島ではダイビングとかシュノーケリングとかは余裕でシーズン中だそうで、その中にはイルカと一緒に泳いで遊ぼうというプランもあるそうで、そういう事ならせっかくだから僕も相乗りさせて貰おうか……と思ったのです。シュノーケリングもダイビングもイルカも、僕が普通に生きてたら、やる機会なんてまず無かったでしょうからね。

それで全てのコーディネートを彼女に丸投げしたのですが、その時点で次の連休といえば9月後半の大型連休?となるわけで、当然そこには多くの人が詰めかけるわけで、まあ普通に予約が取れないわけですよ。特に船と宿。いくら泳ぎの方の予約が取れても、三宅島まで行けなかったり、行っても泊まる所が無かったりするのでは、意味が無いですよね。

東京から三宅島に行く船は、前日夜22時に出発して翌朝5時に到着するというスケジュールなので、22日発(連休は23から25なので)でまず船を探して貰ったのですが、これはもう見事に満席でした。でも1日前ならギリギリまだ予約が取れそうという事だったので、22日に有給休暇を取って21日の夜に出発し、船の中での泊まりを除いて2泊3日の24日帰還にしようという事になりました。

あと宿の方ですが、これは今回ダイビング等の面倒を見て貰う事にした海猿隊さんの方でどうにか手配して貰えて、民宿に泊まれる事になりました。海猿隊さんには今回の度の間中ずっとお世話になりっぱなしでした。ありがとうございます。

という事で後は当日を待つばかりとなっていたのですが、そこで来たのがあの台風15号ですよ。21日の夕方から夜にかけて首都圏を直撃したアレ。案の定、定期便の運行にも影響が出まくりで、21日夜の船は朝の時点でもう欠航が決まってしまいました。

「諦める?」という話もちょっと出はしたのですが、準備もしたし気分も盛り上がってきてるのに今更おあずけは無いよママン!!! 島に行きたいイルカ見たいダイビングしたい!!!! と僕がワガママを言いまして、急遽22日朝発の飛行機のチケットを取ってもらいました。しかしこれでもまだ安心できない。なんでも三宅島は(2000年の噴火以来)有毒ガスがずっと垂れ流しで、風向きによっては空港が使えなくなることもあってそういう時は飛行機が飛ばないらしいんですね。で、予報によると22日の風向きは見事に空港のあたりを直撃する事になってて、飛行機が飛ぶ確率は40%だとかなんとか。

なのでさらにもう1つ最終手段で、22日夜の船の「席無し」というチケットを取ってもらえました。これは、甲板でブラブラするとか通路にシート敷いて寝るとかそういう風にして船に乗る、映画や舞台でいう所の立ち見席みたいな物だそうです。でも22日の便ですら出てくれるかどうか、出ても三宅島に接岸できるかどうかが分からないということで(接岸できないとそのまま八丈島まで行って帰ってくるただのクルーズになってしまう)、もう全く安心ができない。

もうここまで来るとなんだか島に全力で「来るな!!! 絶対来るな!!!」と拒否られてるような気すらしてきて、悲しくなってしまいました。

さて。夜が明けて迎えた22日、航空会社のWebサイトで無情にも「欠航」の告知が為されている事を空港に向かう途中で知り(欠航になるかどうか決まるのが出発1時間前で、家を出るのはそれよりさらに前じゃないといけなかったから)、最後の頼みの綱の船までの10時間あまりをどうにか過ごさなくてはならない事になってしまいました。乗船場所が竹芝だったので、ゆりかもめで豊洲まで行ってららぽーとで買い物をしたり(シュノーケリングの時に着るパーカーを持ってなかったので僕はここで買いました)、引き返して船の科学館を見学してバブル時代の「未来の船」超伝導推進やら何やらを見てなんとも言えない気持ちを味わったり(船の科学館、9月30日で閉館なんですってね。初めて行ったのが閉館直前だったなんて、なんというタイミングなんでしょうか。ちなみに閉館までの間は大人でも入場料200円の激安価格です。)、ジョイポリスでホスト診断受けたりでかい蜘蛛を撃ったりゾンビを撃ったりアトラクションで乗り物酔いしたりして、なんだかんだでお台場を楽しんでから乗船しました。

船の中は結構混んでいて、通路上のイイ所は大体先に他の席無しの人に取られてしまっていたのですが、キャンセル待ちで1等客室に入れたので(その分お金はかかりましたが……)どうにか安心して横になって眠れました。他の席無しの人がどういう風にしてたかというのもちょっと見てましたが、船内の通路に陣取ってる人(床にシート敷いて寝る事を前提に、緩衝材のマットを持ち込んでる人すらいました)、デッキ上で輪になって鍋?を囲んでる人達、デッキ上にテントを立ててその中で寝てるらしい人など、色々あってすごいなーと思いました。

という所までが、三宅島に行くまでの話です。続きは次のエントリに書こうと思います。

Back to Owner Tab(親のタブに戻る)を「進む」に対応させた - Aug 30, 2011

親のタブに戻るで使ってる再起動不要なアドオンのテンプレートそのものに「無効化した状態でアップデートしたら勝手に有効になってしまう」という重大な不具合があったので、その更新も兼ねて、「進む」方向への対応を加えて肉リリースした(太平洋標準時)。

前のバージョンでは単純にタブの.ownerを見て戻る先を判断してたんだけど、これはタブのフォーカスが切り替わるとクリアされてしまうので、1回親のタブに戻ったらそれっきりだった。また、.ownerがクリアされてしまっては、「進む」がクリックされた時にどこに「進」めばいいか分からないし、仮に分かったとしても現在のタブから複数の子タブが開かれていた場合はどこに「進」むのが妥当かという判断がつかない。ということで、「進む」への対応はしてなかった。でも実際使ってたらうっかり「戻」ってしまった後にまた「進」みたくなるという場面が結構あったので、いずれは何とかしたいなーとは思ってた。

で、肉リリース目指してせっかくだから片付けとこうと思って手を付け始めたら、これが結構大がかりな事になってしまって、結局、タブ毎に固有のIDがあって、各タブが自分の親のタブの情報を常に持っていて、ついでに自分が最後にフォーカスされた時刻も持っている、というファットな実装になってしまった(ツリー型タブの初期のバージョンと同じくらいの情報を持ってることになる)。

それでどうなったかというと、前までは1回しか「親のタブに戻る」できなかったのが、何階層でも祖先のタブに「戻」って、その後また元見ていたタブまで「進」む、という事ができるようになった。タブの垣根を越えて透過的に「戻る」「進む」できるというのはかなり変な気分だ。横置きの普通のタブバーでやると、自分が今どのタブを見てるかわかんなくなるんじゃないだろうか。そういうわけで、これはツリー型タブとの併用をお薦めしておきたい(ツリー型タブとの併用時ならツリー構造として既に構築済みの親子関係をそのまま「戻る」「進む」に使えるというメリットもあるのです)。

マルチプルタブハンドラで、タブの選択で一部のタブがスキップされないようになった - Aug 30, 2011

マルチプルタブハンドラはタブの上でドラッグ操作をやると複数のタブを選択できるという物で、mouseoverとまmouseoutとかのイベントを拾ってそういう挙動を実現してるんだけど、mouseover/mouseoutのイベントが発火されない事があるせいで、タブを選択しようとして一部のタブだけ選択されなくてイラッと来る事が時々あった。具体的に言うと、例えばA, B, C, Dの4個のタブがあったとして、AからCまでの3個を選択したくてAの上でドラッグ開始してCの上でマウスのボタンを放した時に、AとCは選択されるのにBが選択されないという感じ。

期待されているイベントが発火されないのはFirefox自体のバグみたいなんだけど、こんなのもうどうしようもないじゃんと思って放置してた。そしたらtitoさん(Komodo EditやSeamonkey用のアドオンを作られている方で、僕のアドオンのいくつかにスペイン語ロケールを提供してくれてる)が「こうすればいいんじゃない?」という提案をして下さったので、プルリクエストで貰ったパッチを参考にもう少し改良した上で実装してみた。基本的な理屈としては、あるタブを選択する時に「直前に選択されたタブ」を保持しておいて、新しく選択されたタブと直前に選択されたタブの間にタブがあればそれらも選択されたものと見なす、というもの。この「直前」の判定基準にはtitoさんのパッチで提案されていた300ミリ秒という数値をそのまま使わせて貰った。

それで実際使ってみたら快適すぎワロタ。今までどれだけこのバグがストレスを産み出していたのか…… タイミングがちょうどよかったから肉リリースしておきました。自動アップデートで皆さんもこの快適さを味わうといいです。

あと、日本語環境向けの細かい変更で、タブを選択した時のメニューのラベルが「Close All」の直訳で「すべて閉じる」とかになってたのを「閉じる」のようにまず動詞が先に来るように直した。こうしておかないと、メニューに項目がずらっと並んだ時にぱっと見で判別できなくて困るという事が多かったので。

Fox Splitterを元の設計に戻して欲しい (Why Fox Splitter lost its functionalities in old versions: multiple panes in a window, not multiple windows?) - Aug 25, 2011

Q

Why did you remove the awesome functionalities from Fox Splitter 0.6 and replaced it with Fox Splitter 2? Fox splitter is now just a way to glue multiple instances of Firefox together.

I would like to ask you to remake the functionality of Fox Splitter 0.6.2009110501, perhaps as it as a function that can be enabled or disabled? Or perhaps just make the 0.6.2009110501 version workable on newer Firefox versions?

どうしてFox Splitter 0.6の素晴らしい機能(※訳注:1つのウィンドウの中を複数のペインに分割する機能)を削除してFox Splitter 2で置き換えたのですか? 今や、Fox Splitterは単に複数のFirefoxのインスタンスをくっつけて一緒に操作するだけの物になってしまいました……

Fox Splitter 0.6.2009110501の機能を復活させて、オプションで有効無効を切り替えられるようにならないでしょうか? それか、単にバージョン0.6.2009110501を新しいFirefoxの上で動作するようにできないでしょうか?

A

I recommend you to try Tile Tabs or Tile View, if you want to split a window to multiple panes and don't want toolbar/tabbar for each pane.

Sorry, Fox Splitter never introduce "multiple panes in a window" feature in future releases. There are some reasons.

After I initially released the old Fox Splitter, I realized that each "pane" should have navigation toolbar for usability. So I actuary did it. However, much codes was required, it had too less maintainability, and it was strongly depended on codes of the specific version of Firefox. So I couldn't update the old Fox Splitter for 1.5 years.

During that time, similar new addons "Tile Tabs" and "Tile View" debuted. I hope that they can replace my old Fox Splitter. However, after I tried them, I couldn't become familiar with their concept. I thought that their "tiled view in a tabbrowser" is hard-to-understand.

Moreover, both "Tile Tabs" and "Tile View" didn't provide navigation toolbar for each pane. I realized that it was a unique feature of my old Fox Splitter and no other addon inherited the concept. I thought that I have to implement such an extension by myself if I want to use it -- no one does it for me except myself.

Yes, I decided to update Fox Splitter. And, I decided to drop functionality to split a browser window to multiple panes, because it requires huge codes and it is very hard to maintain for current rapid-released Firefoxes. I don't want to abandon the new Fox Splitter for a long time anymore. High maintainability (and compatibility) code is strongly required for me. The old Fox Splitter didn't have them and I cannot cover them by my crazy hacking time - now I have less time to do it.

もしあなたが分割されたそれぞれの領域のためのツールバーやタブバーを必要としないのであれば、Tile TabsTile Viewを試す事をお薦めします。

申し訳ないのですが、Fox Splitterが「1つのウィンドウの中を複数の領域に分割する機能」を将来のバージョンで実装する可能性はありません。それにはいくつかの理由があります。

私は、Fox Splitterの最初のバージョンを公開した後で、実用性のためには分割後の各領域がそれぞれ専用のツールバーを持っている方が望ましいという事を実感しました。それで実際にそのような機能を実装しました。しかしそのためには非常に多くのコードを書かなければならず、コードの量が多いという事はメンテナンス性も低かったですし、さらに言うと、それらのコードは特定のバージョンのFirefoxに強く依存した物でした。そのため、私は旧Fox Splitterを更新し続ける事ができず、1.5年もの間完全に放置してしまっていました。

そうこうしている間に、Fox Splitterに似た新しいアドオンの「Tile Tabs」と「Tile View」が公開されました。私は、これらのアドオンが私のFox Splitterの代わりになってくれればいいと期待していました。しかしながら、実際にそれらを試してみると、私にはどうしてもそれらの設計コンセプトに慣れ親しむ事ができませんでした。それらがやっている「1つのタブブラウザの中でタイル表示を行う」というのは、直感的な理解が難しいアプローチなのではないかと、私には思えました。

それに加え、「Tile Tabs」と「Tile View」の両者とも、それぞれの分割された領域のためのナビゲーションツールバーを提供していませんでした。これに至って私は、それが旧Fox Splitterに特有の機能で、そのコンセプトを継承した他のアドオンはまだ登場していないのだという事を理解しました。そのような物を使いたいのであれば、自分自身で実装するしかないーー自分以外の誰もそういう事をやってはくれないのだ、と、私は思いました。

それで、私はFox Splitterを更新する事を決意しました。また、それと同時に、実現するために非常に多くのコードが必要になる上に、現在の高速リリース体制になったFirefox向けにそれをメンテナンスし続ける事は非常に難しいということで、1つのウィンドウの中を分割する機能を廃止する事も決めました。私はもうこれ以上、Fox Splitterを更新できないまま長い期間放置してしまうような事になってしまうのを望んでいません。高いメンテナンス性(そして互換性)を持つコードこそが、私の求めていた物でした。旧Fox Splitterにはそういう視点が欠けており、そういった問題を絶えず修正し続けるために狂ったように多くの時間を注ぐ事は、今の自分には不可能だとも思っています。

「あっち」側なのだなあという実感 - Aug 21, 2011

みかんの星の人が完全に「あっち」に行ってしまった件というエントリを過去に書いてて、偶然読み返す機会があったので読み返してて、ここでいう「あっち」とはまぁ平たく言えば「リア充」の事なんだけど、このエントリを書いた2008年当時は

  • 彼女というものはできた。
  • しかし膨れあがった承認欲求は主観的にはいまいち満たされていなかった。
  • その釈然としなさから、ぐじぐじと非モテ話を垂れ流していた。
  • そしたら「お前もう彼女ができてリア充のくせに何を不幸ぶってやがるんだ」「リア充なんだから非モテ面すんな」と煙たがられた。(参考:rAdio-AktiV - 日本三大ウソ非モテ

という状況で、きっぱりと「あがり」を表明した人達の事を「すげえなあ」「自分はああはなれないなあ」と思って見てた。

最近読んだ長刀漫画の「あさひなぐ」で、剣道やってた子が長刀に転向するにあたって防具を長刀向けに短く切る(そうするともう剣道に戻れなくなる)という話があって、その子は剣道に戻るかもしれないからと防具を切る事を躊躇するというエピソードがあるんだけれども、ちょっとそれに似てると思う。ここで防具を切ってしまったら、もう慣れ親しんだ世界には帰れなくなる。ここでリア充表明をして非モテ時代に決別してしまったら、もう非モテな話は書けなくなる。切るべきか、切らざるべきか。

といっても、その子の場合は「やっぱり剣道の方がいい」と思った結果能動的に戻っていく事になったのだろうという予想ができるのに対して、僕の場合は「彼女と別れる事になっちゃって、やっぱり非モテは非モテだよねアハハハ(泣)」的な単なる脱落というか挫折というかそういう事になるだろうという予想だった、という点では大きく違うんだろうなあと思うんだけど。

でも今だったら、僕もためらいなく「あがり」を表明できるなあと、冒頭のエントリを読み返してて思った。(今このタイミングで「あがり」を表明してしまってよいものか? という葛藤を乗り越えて敢えて「あがり」を表明するという格好いい選択ではなくて、自分を省みた時に「あがっちゃってたわー」と後から言うというのが、僕の卑怯な所がよく表れててアレだなーと思う所はあるけど。)

続きを表示する ...

日経Linuxで漫画の連載をやることになりました - Aug 08, 2011

日経Linux 2011年9月号から、しばらく漫画の連載をする事になりました。「シス管系女子」というタイトルで、コマンド解説とかTips紹介とかそういう内容にしていく予定です。僕の月産ページ数自体が少ないので短い漫画にせざるを得ず、あんまり掘り下げた話はできないのですが。

日経Linuxでは6年前にOpenOffice.orgの使い方解説記事の連載を持たせていただいた事があります(だからというわけでもないのですが、今回の漫画にもその時の挿絵のキャラが再登場しています)が、まさか同じ雑誌で今度は漫画を描く事になるとは思いもしませんでした。どうしてこうなった……!

あと同時に美女Linuxのコラボ記事も連載開始されたという事を知らなくて、実際にできた本を見たらコンセプト被りすぎワロタ。情報量的に負けてるじゃん……やばい……

ジム通いを始めた - Jul 24, 2011

キックボクシングのジムでやってるボクササイズとヨガのクラスに通い始めました。キックボクシングのクラスにも行ってみましたが、眼鏡を外すとまるで見えなくてお話にならないという事を痛感したので、キックボクシングをやるのはコンタクトレンズを付けられるようになってからかなーと思っています。

動機は主に健康面です。通い始めたのは健康診断の結果が出る前からではありましたが、健康診断の結果を見ると年々中性脂肪の値が高くなっていっていて、そういう風に数値で示されるまでもなく、ちゃんと継続して運動をしなければそのうち死んでしまう……と恐怖を覚えていた所に、ボクササイズをやろうと誘われたのが決定打になりました。

運動はキツい事はキツいのですが、毎日やるわけではないのでわりと楽といえば楽です。月謝を支払う立場なので「お金払った分行かなきゃ損だ」という思いもあって、その思いが辛さを上回る事ができるレベルといった所です。

むしろ「こんなんで効果なんてあるんかいな」と不安を覚えてすらいるのですが、僕より前から通っていた人から「2年くらいやってて、始める前に比べて10kg痩せた。1ヶ月1kgくらいのペースで落ちた。」という話を聞いて、無駄にはならないんだと思えて、ちゃんと続けようと改めて思いました(しかし今から2年後というと31歳なので、色々と遅きに失した感は否めません)。

そういえば今まで何度か「お金のかからない健康増進法」を何個か試してみていましたが、どれも長続きしませんでした。お金を払ってでもという事と、誘ってくれた人と同時に通っている(自分がサボっててもその人は通っている、という焦りを感じずにはいられない)という事、あと上記の話から、今回は長く続くといいなあ、長く続けたいなあと思っています。

今日行ったクラスはほとんどの参加者の方が女性で、男性は僕の他にもう1人しかおられなかったのですが、終わってシャワー浴びて汗を流した後に更衣室で2人きりになってしまって、これはむしろ話しかけない方が危険だ……と思ったので自分から名乗って挨拶をしたのですが、そのおかげで会話ができて上記のような話も聞けて決意を新たにできたので、慣れない事(自分から話しかける)をして良かったと思っています。

オチはないです。

Firefoxアドオンの開発を通じて考えるようになったインタラクションデザイン - Jun 30, 2011

あかつかだいすけさんのご紹介で、6月27日に慶応大学湘南藤沢キャンパスでインタラクションデザインについての講義を1時間ほどやらせていただきました。その際の発表資料はいつもの通り「高橋メソッド in XUL Returns」で作ったのですが、Remote XULがデフォルトで禁止されるようになったFirefox 4以降だとこれを見るためには色々と面倒が多いので、代わりに講義の内容を思い出しながら資料を引用しながらエントリにまとめてみたいと思います。

事前に伺っていたオーダーは、これまでのアドオン開発の中でUIという点についてどういうデザインポリシーを持って開発してきたのかを、また、コンセプトを実装する際の経験から得られた知見を語るというものでした。今までにもこの場やTwitter等で断片的に語ってきている事ではありますが、改めて整理するいい機会になったと思います。

自己紹介

まず簡単に自分の事をお話ししておきましょう。

僕は大阪出身の28歳で、Firefoxのアドオンとの関わりは「Firefox」というプロダクトが世に出るより前からなので、もうそろそろ10年になろうとしています。アドオンをやり始めた頃は大学1年とか2年とかの頃だったと思いますので、講義を聴いていただいた皆さんくらいの年の頃からということになります。卒業制作(僕のいた学科では卒論ではなく卒業制作、しかも選択制だったのです……)もMozillaの拡張機能で「2次元的にWeb閲覧の履歴を表現する履歴表示UI・兼・Webブラウズ用UI」という物だったので、余計に感慨深い物があります。

そういう僕ではありますが、今はクリアコードという受託開発の会社でプログラマとして勤務しており、最近はRubyでWebサービスを作るといった案件に関わっています。仕事の上でインタラクションデザインの事を考える事は実際の所ほとんどなくて、そういう事を実践する機会趣味のアドオン開発の場面くらいしか無いというのが実情です。(きちんとインタラクションデザインの事について学んでいる人に比べると、おそらく物凄く初歩的な事しか理解していない、本来であれば人前でインタラクションデザインについて一席打っていいような立場ではないとは思っています。)

自分はこの何年かで数だけはやたら多くのアドオンを開発してきましたが、インタラクションデザインという観点から語りやすそうな物として、以下の4つを特に取り上げて語ってみたいと思います。

  • ツリー型タブ:タブバーをウィンドウの上ではなく左に移動して、タブを縦に並べて表示し、タブの親子お関係をインデント幅で表現する。
  • マルチプルタブハンドラ:複数のタブをドラッグで選択して、まとめて閉じたりリロードしたりと言った操作を可能にする。
  • Fox Splitter:Firefoxのウィンドウを複数の表示領域に分割し、複数のページを平行して閲覧できるようにする。
  • セカンドサーチ:FirefoxのWeb検索バーにおいて、文字を入力した後で実際に使う検索エンジンを選べるようにする。

自分がUIをデザインする時に気をつけている事

5W1Hで目的をはっきりさせる?

ニュース記事を書く時の5W1Hという原則をご存じでしょうか。

  • 誰が(Who)
  • いつ(When)
  • どこで(Where)
  • 何故、何のために(Why)
  • 何を(What)
  • どのようにしたのか(How)

これらをきちんと抑えた文章にする事で、一体何の記事なのか、どういう事が起こったのか、という事を読者に過不足無く伝えられるという原則が5W1Hです。

僕は、UIのデザインにおいてもこれらの5W1Hが重要だと思っています。

  • 誰が(Who)
  • どういう利用局面で(When、Where)
  • どういう目的で(Why)
  • 何を(What)
  • どのように操作するのか(How)

これらを満たす事のできるUIを考える、というのが出発点としては分かりやすいのではないか。闇雲に「何か新しいUIを」と考えるよりも、これらを意識した方がゴールを設定しやすいのではないか。という事です。

何事でも目的は大事です。特にソフトウェア開発では、無目的に「単に技術的に可能なので作ってみました」という風に生み出したプロダクトがあっても、自分で使わないし誰も使わないために、そのまま死んだプロジェクトになってしまう恐れがあります。

ただ、それとは逆の場合もあると僕は思っています。「単に技術的に可能なので作ってみました」という物を、試しに自分で使ってみたら案外使い勝手が良かった。常用するためにもっと改良したくなった。というケースが僕には実際にありました。ツリー型タブは、元を正せばそのようにして生まれたアドオンです。

ツリー型タブの誕生の経緯

かつて僕はタブブラウザ拡張(Tabbrowser Extensions、TBE)という、Mozilla SuiteやFirefoxの貧弱なタブブラウズ機能をなんとなくいい感じにパワーアップするというようなオールインワン型のアドオンを開発していました。

その頃既に僕は、10とか20とかの多数のタブを同時に開いてWebを閲覧するという使い方をしていました。そういう使い方だと、通常の横一列のタブバーだと、今見ているタブが画面外に吹っ飛んでしまったり、さっきまで見ていたタブがどこに行ってしまったのか分からなくなったり、という具合に色々困った事が起こります。それで僕は2つの機能をTBEに持たせていました。

  • タブバーを多段表示して、1度に多くのタブを見えるようにする。 (タブバーを多段表示した様子)
  • タブを色分け表示して、どのタブからどのタブを開いたのかという親子関係を色で示す。 (タブを色分け表示した様子)

「多段タブ」は、僕がWindows 95を使い始めた頃から時々見かけていたインターフェースでした。Windowsのコントロールパネルで多数の設定項目を持つ項目を開いた場合に、そのダイアログが多段タブになっている場合があったからです。タブが多ければ2段や3段に分けて表示すればいい、というのは日常的に使うWindows自体の一般的なUIを見ていれば自然と思い浮かぶ発想でしょう。

タブの色分け表示は、元々は何か他のブラウザがそういう機能を持っていたのを真似て実装したような記憶があります。親となるタブと子タブとを同じ色で表示しておけば、タブの親子関係が一目で分かるようになります。IE7でもリンクからタブを開くとそれと同じようにタブが色分け表示されるようになっていましたが、当時としては、これもまたそう珍しくない機能だったのでしょう。

そこにツリー表示機能を加えるきっかけになったのは、malaさんが自身のブログで紹介されていたiRiderというIEコンポーネントブラウザでした。

livedoor Readerの開発者として知られるmalaさんは昔からJavaScriptで変態的な、もとい、他の人が思い付いたり実践したりしていなかったような先進的な試みを色々とやっている方なのですが、そのmalaさんが2005年に2005年もパクられてこなかったもの私的まとめベスト3というエントリを書かれていた際に、iRiderというブラウザの名前を挙げておられました。今では配布元のドメインが失効していて百式のエントリにあるスクリーンショットくらいしか様子を窺える物が残っていないのですが、あのmalaさんが(「あの」って付けるくらいに、僕はmalaさんの着眼点はいつも鋭いと考えているのです)名前を挙げているくらいなのだからさぞかし凄い物に違いない!と思ったので、興味本位に加えて腕試しにという思いもあって早速TBEに「タブの親子関係を色分けだけでなくツリー表示というシルエットの変化で示す」という機能、あと、リンク先のエントリでも触れられている「撫でるインターフェース」も併せて実装しました(実はこれが現在のマルチプルタブハンドラの原型だったりもします)。

iRiderのツリー表示というのは、実を言えば、「タブのツリー表示」ではありませんでした。ウィンドウの左に表示されているのはあくまで2次元的に表現されたWebページの閲覧履歴であって、それらの履歴項目をドラッグしたりクリックしたりするとウィンドウの右側でページを見る事ができる、というのがiRiderの挙動です。ただ、当時既にTBEが持っていた「全てのリンクを新しいタブで開く機能」「リンクから開かれたタブを現在のタブの子タブとして扱う機能」にいくつかの機能を加えさえすれば、(メモリの消費量等の観点ではオーバーヘッドはあるものの)表面的にはiRiderと同じような挙動を示すようになるだろうという見通しは立っていました。

ちなみに、タブに相当する物をツリーで表示するブラウザというのは当時既にいくつか存在していたようですが、僕はそれらの事を意識していませんでした。というか、ツリー? 一体何がおいしいの? みたいな認識でした。そういうわけなので、この時はタブをツリー表示する拡張機能を作ったというよりも、iRiderの挙動をFirefoxで(無理矢理)再現するというのが、やった事の本質を正しく言い表しています。

そういう事でとりあえず技術的には可能だったから実装してみるだけしてみたのですが、タブを履歴の代わりに使うというのは当時の自分にはあまりに違和感が大きすぎましたし、iRiderの「履歴」と違ってMozillaのタブは開いていればその間ずっとメモリを消費する物であるという背景もあって、自分はこの時実装した機能のうち「タブをツリー表示する機能」だけを、せっかく実装したのだから……と、ずっと使い続けていました。

そしたら、これが案外便利だったんですね。

という事で自分自身がすっかりツリー機能に依存するようになってしまいました。その後メンテナンスしきれなくなったために僕はTBEの開発を中止しましたが、まずは「なでるインターフェース」の再現のために書いたコードを応用して、その機能だけを抽出して「タブを選択してから操作する」というコンセプトで再設計したマルチプルタブハンドラを公開し、さらに続いて、タブのツリー表示機能だけを抽出したアドオンをツリー型タブとして公開して、TBEの頃と同じような使い勝手を保ち続けて今に至っています。

自分が「良い」と思えるUIのデザインポリシーを逆算する

タブのツリー表示のどの点が便利だと感じたのか、自分自身でもそれと意識する事はなかったのですが、ツリー型タブをMozilla主催のアドオンコンテストに出品するにあたってアピール文を書こうとして、改めて「自分がツリー表示されたタブを使いやすいと感じた理由」を言語化してみる事にしました。

その時自分で分析して思いついた「使ってみて分かったツリー表示のいい所」は、以下のようなものでした。

  • 一覧性が高い。(多数のタブを開いていても、縦に重ねた表示形態であればまだ全体を見通せる。)
  • ページを閲覧してきた履歴がそのまま可視化される。(どのタブからどのタブを開いたのか、どのページからどのページへ遷移したのか、という事がツリーとして視覚的に、2次元的に表現される。)
  • タブが自分の存在を主張してくる。(ブックマークフォルダの奥にしまい込んだ時のように、存在を忘れてしまわないですむ。未消化のタスクがタブとして溜まっていくと、タブバーをだんだん圧迫してきて、「片付けなきゃ」という意識を僕自身に喚起させる。)

これらをもっと突き詰めて一言にまとめると、「ツリー表示であればうろ覚えでも使える」からこそ自分は利便性を感じたからなのではないか。それが自分の辿り着いた結論でした。

うろ覚えで使える、とはどういう事か。もう少し具体的に考えてみましょう。

  1. ボケーッとしてても使える。
    • どこに何があったんだっけ、という事を憶えてなくてもUIを見れば必要な情報がそこにある。
    • 且つ、それらがうるさく主張しすぎてもいないので、多すぎる情報を前にして迷う事がない。
  2. 考えなくても使える。さあこれからこのタスクをこなそう!といちいち気張らなくても使える。
  3. 初見でも使える。使い方を知らない状態で初めて使う時でも、戸惑わないで済む。
  4. 忘れても使える。使い方を忘れてしまって、初めて使う時の感覚に戻ってしまっても、初見と同じようにすぐ慣れる事ができる。
  5. 既存の物に似ている。それ自体の使い方を特別に覚えなくても、他の物からの類推で違和感なく使える。

1は、表示される情報が適切な量になっているという事だと言えると思います。2から5は、学習コストが低いという事です。どうやら僕は、これらの点を満たしている時に「良いUI」と感じているみたいです。

適切な情報量とは

この点はSFCでの講義では話せていなかった点ですが、このまとめでは書いておきます。

情報が適切に整理されている、という事は非常に重要です。例えばある家具屋さんの折り込みチラシを見てみましょう。 (チラシの画像。様々な商品の情報が所狭しと押し込まれている。) この種のチラシは「新春初売りセール開催中ですよ!」という事を顧客に告知して集客する事を第1の目的に、そして売り込みたい商品にどういう物があるのかをなるべく多く知らせる事を第2の目的にしていると考えられます。情報を見やすく整理するという事はあまり重視されていないので、余白を設けるよりも、少しでも多く情報を詰め込む工夫が為されています。顧客はこのチラシの中から目を皿のようにして安い商品を探す事になります。セールのチラシの場合は顧客には「そこにどんな情報があるのかをじっくり読み取る努力をするモチベーション」がありますから、多少の苦難は乗り越えられます。

しかしブラウザのUIは、使い手の側にそれほど強いモチベーションはありません。「さっきまで見ていたタブ」を見つけるためにいちいちこのようなゴチャゴチャした絵面の中を一生懸命探すのは、ただのストレスにしかならないでしょう。常用するUIがこんな感じではとても使えません。

視覚的な情報の量を調整するテクニックはいくつかあります。DTPのセオリーやWeb制作のセオリーなどを読んでもらうといいと思いますが、今自分でもぱっと思いつく物としては以下の4項目があります。

  1. 適切な余白を設ける。要素と要素を詰め詰めに配置しすぎない。(詰め詰めに配置すると、誤操作の元にもなり得る。)
  2. 同じ種類の要素は近くにまとめたり、同じ位置に揃えたりして、グループとして認識できるようにする。
  3. 色を整理する。バラバラの色を混在させないで、同じような物は同じような色でまとめておく。そうする事で、特別な場合にだけ色を変えるという事が「特別」として活きてくる。
  4. 色ではなくシルエットで判別させる。モノクロディスプレイだったり色盲だったりといった色の違いが分からない状況でも、シルエットの違いなら認識できる。また、一般的に色の違いよりも形の違いの方が人は認識しやすい(とどこかで聞いた気がする)。

ツリー型タブによる縦型タブバーの場合、2から4が特に顕著だと僕は考えています。

(ツリー型タブのスクリーンショット) スクリーンショットを見ると分かりますが、縦にUI要素が揃う事で、左にアイコン(とインデント)、真ん中にタイトル、右に「タブを閉じる」ボタンが集まっています。 (ツリー型タブと情報化タブの併用時のスクリーンショット) ここにサムネイルというUI要素が加わっても、縦に同じような位置に同じような物が並んでいるので、これはまとめて意識の外に置いておきやすいはずだ、と僕は思っています。実際、自分はこのようなタブバーの左の方を見ている時は右側を無視していますし、右側を見ている時は左側を無視している気がします。

逆に、横置きのタブバーでは、「アイコン、タイトル、クローズボックス、アイコン、タイトル、クローズボックス……」とそれぞれ異なるUI要素が一列に並んでいるので、「アイコンにだけ注目する」とか「クローズボックスにだけ注目する」という事がやりにくいと僕は思っています。

タブの親子関係は、タブの色分けではなく、インデント幅というシルエットの違いで表現されています。これなら、2段階以上のネストであっても状態を正しく把握できるでしょう。

視覚的な情報の整理の仕方はデザインの本を学ぶと色々と情報を得られると思います。自分は一時期Webデザイナーになりたいと考えていたので、DTP的な記事が多く載っていたWebデザイン雑誌も何度か目にしていたのですが、上記のような話はそういった所で仕入れた物のような気がします。

学習コストを低くするためには

ヒューマン・インターフェースのデザインのセオリーという物がいくつかありますが、それらはソフトウェアにおけるインターフェースのデザインにも適用できます。

見た目の工夫

何のための物か、何を表している物なのか、説明がなくても一目で分かるようなデザイン。形がそれ自身の役割を表す。これはUIのデザインでよく言われる事です。

ソフトウェアの場合は、まずそのOSにおける一般的なデザインの流儀に則ってUI要素をデザインしておけば、少なくとも「ここはクリックできる場所なのだな」といった事を伝えられます。その上で適切なアイコン画像を加えましょう。基本はやはり重要です。

見えているUI要素はそのまま使えるようにする、という事も大事です。「見えているのに使えない」「見た目通りには動かない」というのは、ユーザを惑わせるばかりの害悪です。例えば以下のような物は論外でしょう。

  • グレイアウトされていないのに、クリックしても何も反応しないボタン。
  • グレイアウトされているのに、クリックを受け付けるボタン。
  • いかにも押せそうな風に出っ張った視覚的なデザインであるにもかかわらず、ボタンになっていない。

基本的に、人は他の場面で憶えたやり方を別の場面でも使いたくなるものです。タブを掴んで移動できる、という体験をExcelでやった後であれば、Firefoxのタブも掴んで移動できると考えておかしくないでしょう。UIの基本的なルールを統一しておく事の意義はそこにあります。

ですので、奇をてらってワケの分からないUIにするよりも、まずは既存の類似のソフトウェアの挙動に合わせる事ユーザがこれまでに学習してきた事に反しないようにする事。これをまずは意識しておくのが大事です。AndroidアプリのUIガイドラインなど、各OSで何らかのデザインのガイドが提供されているのであれば、目を通しておいて損はないです。

ツリー型タブも、タブをドラッグ&ドロップした時の挙動はAdobe Illustratorのレイヤーの操作をモデルに整備しました。また、マルチプルタブハンドラも「Ctrl-クリックでタブの選択状態をトグルする」「Shift-クリックで複数のタブを一気に選択する」という、Windowsやなんかで一般的な操作で使えるようにしてます。こういうのも、既存の物に合わせている例ですね。

見た通りに使えるかどうか、という観点で「こりゃあかんわ、好きになれんわ」と自分が最近感じたUIは、以下の2つのアドオンです。

これらはいずれもFox Splitterと同ジャンルのアドオンで、Firefoxのブラウズ領域を複数に分割してそれぞれに別々のページを表示できるようにする物です。

実際インストールして試してみると分かると思いますが、これらはどちらも、ウィンドウの上の方にあるタブバーやナビゲーションツールバーという操作UIが、タイル表示されたWebページの間で共有される設計になっています。下のペインで「戻る」操作をしたければ下のペインにフォーカスしてから上のツールバーの「戻る」ボタンをクリックする、という具合に、操作の対象と操作のために入力UIがバラバラに切り離されてしまっています。

また、タブと対応するWebページとが離れてしまっているのも問題です。どのタブをクリックしたらどのコンテンツ領域がフォーカスされるのか、どのコンテンツ領域をクリックしたらどのタブがフォーカスされるのか、今どのコンテンツ領域にフォーカスが当たっているのか(フォーカスされているコンテンツ領域の周りには枠が表示されますが、背景色によっては枠がとけ込んでしまう)、といった事を、このUIだとぱっと見て判断しにくいです。慣れれば使えるのかもしれませんが、これに慣れたくはないなあ、というのが僕の正直な感想でした。

UIが常時見えている事、表示UIが入力UIでもある事

入力UIが状態の表示のためのUIを兼ねる、というのもUIのデザインでよく言われるセオリーです。

  • 音量のボリュームをいじるダイヤルは、回した角度が入力となり、また、ボリュームの角度がそのまま音量を示すインジケータになる。
  • ガスコンロのつまみなら、回した角度が入力となり、同時にその角度が火の強さを示すインジケータになる。

ソフトウェアの場合もやはり同じ事が言えます。例えばクリックする度に機能の有効・無効を切り替えるトグル式のツールバーボタン(XULでは<toolbarbutton/>要素)であれば、これはチェックボックス型(<toolbarbutton type="checkbox"/>)としておきましょう。チェックボックス型のツールバーボタンは、1回クリックすると押し下げられたままの見た目で固定され、もう1度クリックすると出っ張った状態に戻ります。これは、入力装置であると同時に、見た目で今の状態を表すインジケータとなります。

ツリー型タブの場合も、タブという元々入力と状態の表示を兼ねたUIであった物を、そのまま少し形を変えて縦に並べています。

使用頻度の高いUIについては、常時見えている事も大事です。クリックしないと出てこない物は、そのワンステップが煩わしくてそのうち使われなくなってしまいます。Firefox 4から標準搭載されているPanoramaもこの問題を抱えていますし、Google Chrome版のTree Style Tab(※作者は僕ではないです)も、Chromeの拡張機能向けAPIの仕様上の制限でそのようになってしまっています。パネル型でもいいので、これを表示したままの状態に固定できるようにならないと、常用するUIとしてはちょっとキツいと自分は思います。僕が自分でツリー型タブをChrome向けに移植しないのは、この点をクリアする方法がまだないように見えるからという理由もあります。

カーソルを合わせたら自動で出てきて、カーソルを外したら自動で消える、という物は、場合によっては有用です。

  • 意図しないタイミングで出てきてしまえばストレスになる。
  • 出てきて欲しいのになかなか出てこない(例えば、表示するために1ピクセルの幅の領域の上を正確にポイントしないといけないとか)のもストレスになる。

「自動で隠す」系のUIは、WindowsのタスクバーやGNOMEのGNOMEパネルのような、画面全体の一番端に貼り付くUI以外ではあまり実用的ではないと僕には思えます。(余談ですが、UI要素は大きければ大きいほどそれを操作しやすく、画面の端であればどこでも反応するというボタンやUI要素は「無限の大きさを持っているに等しい」とよく言われます。Windowsでウィンドウを最大化した時に画面の右上にマウスのポインタを移動させてみれば、大雑把に指し示しただけで「閉じる」ボタンがハイライトされる事が分かると思います。)

モーダルよりもモードレス

これは1つ前の話とも少しかぶるのですが、「入力するモード」と「それ以外の操作をするモード」という風な排他的なモード切り替えは、極力避けるべきだというのが僕の考えです。設計を見直して、そもそもモードの切り替えが必要ないようにする、くらいに突き詰めていいと思います。

モーダルなUIは、ユーザの持つメンタルモデルの中にモードの違いがキッチリ組み込まれていればいいのですが、そうでない場合(ユーザのメンタルモデルの構築に失敗している場合)には混乱の元になります。いつもやっている操作を違うモードでやっても何も反応しない。でもユーザは、モードが違うせいでそうなっているという事に気付かない。「違うモードなのでその操作はできませんよ」と警告を出しても、根本的な解決にはなりません。

この観点で僕がどうしても好きになれないソフトウェアの代表例が、viとかvimとかVimperatorとかそのあたりという事になります。vi系のエディタはコマンドモードと編集モードを行き来しながら操作するという設計になっていて、この種のストレスを自分はしょっちゅう感じます。

単機能・明確なコンセプト

これは「UI」というよりも、もっと前の段階のテーマ決めの話になるかも知れません。

「何でもできる」という謳い文句は、「何をすればいいか分からない」という問題と表裏一体です。何をするための物なのかとか、どう使うべき物なのかとか、それを使う事で自分の生活がどう変わるのかとか、そういった事が伝わってこないとユーザは戸惑ってしまいます。先程、視覚的なデザインによって目に飛び込んでくる情報を制限して情報量を抑えるという事を述べましたが、コンセプトの設定にも同じ事が言えます。

「これができる」「これをする物だ」という事がはっきり見えていればいるほど、メリットが見やすくなるのと同時に、どういうデメリットがあるのかも見やすくなります。基本的にアドオンのインストールには多かれ少なかれデメリットがつきまとっていますが、そのデメリットを乗り越えてでも欲しい機能があるのだという人と、そういうデメリットがあるのであれば絶対に使いたくないという人とをきちんとスクリーニングできれば、ユーザを無駄に不幸にさせずに済むというのが僕の考えです。

カスタマイズ性の高い設計にしていたとしても、というか、カスタマイズ性が高い場合にこそ、既定の設定は重要です。第一に想定しているユーザ、この人にまずは使ってもらおうと思っている相手が、違和感なく使えるような設定をデフォルトにしておきましょう。インストールした後必ず自分に合わせた設定の変更を行わなくてはならないのでは、使い始める時の心理的コストが大きくなってしまいますし、そもそも、使う前から「どういう設定が望ましいか」をユーザが判断するというのが土台無理な話です。

また、最近はいろんな機能を1つのUIに統合する事が流行っているような感じがあると思いますが、「何でもできるUI」として1つのUIに2つも3つも機能を詰め込んでしまうと、実際の利用時に却って不便になる事もあります。

Firefoxのロケーションバーと検索バーを統合して「普通の単語を入力したらGoogleで検索して、URLっぽかったらタブを開いて……」という風な「文脈に応じた自動判別」を行うようにしたとして、「google.comという単語を検索したい」という意図をそのUIは正しく受け取れるでしょうか? 文脈の機械的な自動判別には今のところ限界があるので、誤判定、いわゆる「誤爆」の発生はゼロにはできません。

じゃあ考えられる候補をすべて一気に列挙してしまおう、というのも乱暴すぎる話です。入力欄に何か語句が入力されたら、検索結果を3件、その下に過去の履歴で入力とマッチした物を3件表示する、とした場合、ユーザが最初から「過去に見ていたページをもう一度見たくて」その入力を行っていたのであれば、最初に出てくる検索結果3件はただのノイズになってしまいます。ユーザがその時したい事に対して適切な結果が帰ってこないのは、単純にストレスですよね。

ある機能の利用頻度が特に高いのであれば、その機能には専用のUIを割り当ててやった方がいいです。よく使われている物を無理矢理他の物と統合するというのは、信頼性の低い自動判別を無駄に1枚噛ませるだけになったり、メニューを選ぶための手間を無駄に1つ増やすだけになったりという事になると思うので、僕はなるべくそういう事は避けたいと考えています。

Appleは、コンセプトをはっきりさせるという事を非常に強く実践しています。例えばiPodは非常に割り切った設計で「音楽を聴く」事に特化していて、関係ない要素をガンガン省いていました。それによって、「これは音楽を聴く物なのだ」という事が嫌でもユーザに伝わります。Appleの場合はスティーブ・ジョブズが「これがいい」と言った物を会社を挙げて製品にしており、製品の第1顧客はいつもスティーブ・ジョブズだと言えます。また、キングジム社のポメラも、会議の場で商品の企画が出た時にはほとんどの人が反対したけれど、1人だけ「買いたい」と言った人がいたので商品化できてヒットに繋がったといいます。(余談ですが、リンク先の記事によるとその1人というのは慶応大学の印南教授だそうです。何とも奇遇ですね。)

あらゆる人の方向を向こうとして誰の方向も向けないよりも、誰の方向を向いているのかがはっきり分かるようにした方がいい。100人を満足させようとしてみんなに「ふーん、悪くないね。まあ機会があれば試してみるかもね。」って言われて実際にはそのままスルーされてしまうよりも、99人にそっぽを向かれてもたった1人のユーザに「これすごくいい!!」と飛びついてもらえる、その人を確実に満足させられる方がいい。というのが今の自分の考えです。これだけ物や情報が溢れている世の中では、そうやって製品の特色をはっきりさせないと、評価してもらう前の段階で埋没してしまうのではないでしょうか。

これらの点で僕が「駄目だなー」と思っているのが、かつてのTBETab Mix Plusといったオールインワン型の多機能アドオンです。メリットを一言で説明しにくいから紹介する側も「とりあえずこれ入れとけ」という風な言い方にならざるを得ず、紹介された側はどこが具体的にどう変わるのか・どのようなデメリットがあるのかをきちんと把握できず、それのせいでトラブルが起こったとしても「何をするためのアドオンを入れたからこうなった」という事が全く分からないから原因を切り分ける事もできず、という負の連鎖が起こってしまいます。

先に入力を受け付けておいて、どうするかは後で選べるようにする。思考を途切れさせない。

僕が持ってる携帯電話は、待ち受け状態で数字をぽちぽち入力すると、その数字を電話番号として電話をかける以外にも、電卓機能を起動したり、積算メモ(簡易家計簿)に記入したり、という風な事ができます。メニューから「電卓」を起動して数値を入力するのでも、積算メモ機能を起動してから金額を入力するのでもなく、数字をぽちぽち入力したら画面の中で「この数字を電卓に流し込みたい時はこっちのボタンを押す」「この数字を積算メモに記録したい時はこっちのボタンを押す」という誘導が行われるんですね。

僕はどうも、そういうUIが好きみたいです。セカンドサーチは、Web検索バーで文字を入力した時に「既定の検索エンジンで検索するの? Amazonで検索するの? それとも英和辞書?」という具合に利用できる検索エンジンをポップアップで列挙して、文字入力からそのままスムーズに検索エンジンの選択に移れるようにする……というアドオンですが、前述の携帯電話のUIと考え方は共通していると思います。(なお、僕がセカンドサーチを作ったのはこの携帯電話を使い始めるよりずっと前でした。)

思い返してみると、セカンドサーチを作った動機は、「検索エンジンを選んでから検索して、また元のGoogleに戻して、という操作が死ぬほどめんどくさい。やってらんない。」という不満からでした。

エンジンを切り替えるのが面倒だから、大抵既定の検索エンジンで済ませちゃう。たまに検索エンジンを切り替えて使うと、その後無意識のうちに既定のGoogleで検索したくなって、しかし検索エンジンを切り替えたという事実をすっかり忘れていて、うっかり別の検索エンジンで検索してしまう。そういうのが鬱陶しくて、僕は結局Googleしか使わなくなってしまいました。でも、せっかくOpenSearchとかで検索エンジンを追加登録できても、それらを使う機会が全く訪れないなんて、こんな勿体ない事があっていいはずがない。そう思って、「先に検索エンジンを選ぶのと、後で元に戻すのがめんどくさいんだ」と判断して、「後から検索エンジンを選べて、既定の検索エンジンに戻す必要がない」という操作ができるようにしてみたんですね。

こういう傍目から見てアホとしか思えない行動を取ってしまう人はけっこういるんです。Web検索バーに文字を入力する時には、入力しようと思っている語句に注意がいっているから、「どの検索エンジンが選択されてるか」という事に注意が向かないんですね。そういう風な思考ができあがっている時に、期待通りの結果が得られないと、「なんでやねん」とストレスを感じてしまうわけです。

そういうミスに対して「それはあんたの使い方が悪いんだ」と責める人もいるでしょうけど、道具は使う人のためにデザインされるべき物と考える限りにおいては、人がそういう行動を取ってしまうのなら、その行動に合わせて道具をデザインした方がいいと僕は思っています。

ユーザの行動や入力をトリガーにする

1つ前の話を別の観点からもう1回語ってみます。

金額の事だけで頭がいっぱいになっていて、とりあえず無意識に数字を入力し始めてしまう、という僕の行動をトリガーにして、僕の携帯電話はよさげな機能をサジェストしてくれるわけです。同じようにセカンドサーチも、頭の中が調べたい単語の事でいっぱいになっていてとりあえず無意識に単語だけ入力してしまうという僕の行動をトリガーにして、適切な検索エンジンを後から選べるようにサジェストしてくれます。このように、無意識の行動を起点にして各機能を呼び出せるようになっていると、「機能をどこから呼び出すのか」を改めて考えなくて済みます。

機能をどこから呼び出すのか、というのは結構重要な問題です。

メニューを何階層も辿った奥にある機能というのは使うのが億劫なので、だんだん使わなくなってしまいます。しかし、だからといって階層の浅い所にメニュー項目を増やしていったり、ツールバーのボタンをどんどん増やしていくと、機能が増えていった時に収拾が付かなくなってしまいます。

WindowsのコマンドプロンプトやLinuxやMac OS Xのターミナル(端末エミュレータ)のようにコマンドを入力させる形式なら表示領域を悔いませんが、今度は、ユーザが「どんなコマンドが使えるのか」という事を常に頭の中に入れておかないといけないようになってしまいます。コマンドだけじゃなく、今どこのディレクトリにいるのかとか、ログインしているユーザが誰なのかとか、いろんな「モード」を把握してないと使えません。僕はそんなの全部は覚えてられないので、CUIでコマンドライン入力というのは基本的に好きじゃないです。

表示領域も食わないし文字列のコマンド入力よりも直感的、という事でマウスジェスチャ(リンクをドラッグしたままマウスを上下左右に動かすと、その軌跡(ジェスチャ)がコマンドとして解釈される機能)はどうなんだ? っていう話になってきますけど、マウスジェスチャも「ジェスチャを覚えないといけない」という問題はやっぱりあります。上上下下左右……みたいなややこしいジェスチャを全部覚えてられるかというと、まあ無理な話です。実際、マウスジェスチャを使ってる人でも「憶えてるのは上下左右の各方向にマウスを動かす単純な動き程度でそれより複雑な物は全然使わない」と言ってました。

という話の中にも出てきていますが、ごく簡単なジェスチャだったらアリだと言えます。リンクを引っ掴んで適当にぽいっと投げたらそれをタブで開く、とか、その程度の大雑把さなら苦になりません。ただ、この場合は「ジェスチャを入力している」と言うよりも、「リンクというオブジェクトを掴んで何かしようとしている」という場面だと解釈した方が正しいでしょう。

僕が「ユーザの入力をトリガーにする」という言葉で表現したかったのはそういう事です。何かキー入力を始めたとか、何かオブジェクトがドラッグされたとか、そういう行為そのものをトリガーにするっていう事であって、「どういう文字が入力されたのか」とか「どういう風にマウスを動かしたのか」とかの細かい所を情報として使うという話ではないんです。もちろん、入力された内容にそぐわない機能を除外した上でサジェストする(例えば数字だけが入力されていたら英和辞書は候補に出さないとかの)工夫はあってもいいと思いますが。

「冷蔵庫に卵とトマトがある事を確認して、それからクックパッドで卵とトマトを使ったレシピを探そう」という風な理路整然とした行動計画を、現状から目指すゴールまでを最初から完全にきちんとイメージできる人ばかりではないんです。というか僕自身がそういう事ができない方なんですね。おなかすいてとりあえず冷蔵庫を開けてみたとか、そういう無駄な事をやってしまう方です。

そういう最初のアクションを無意識レベルで起こした結果、機能がサジェストされたり視覚的なフィードバックがあったりして、そこからさらに「そういえば自分はこういうことをしたいんだった」と次の行動が喚起される。(もっと言うと、その時の既定の挙動が一番利用頻度の高い物になっている。)という風な誘導がウザくないレベルで働くようなUIが、僕にとっての「良いUI」なんでしょうね。

ブラウザのUIはゲームのUIではない

ちょっと話はズレますが、ストリートファイターとかの対戦格闘ゲームを考えてみましょう。この種のゲームは、技を出すための複雑なコマンドを覚えたり、覚えたコマンドを適切なタイミングで正確に入力できるようになったり、という努力の末の「上達」が「勝利(報酬)」に結び付くというゲームのデザインになっています。勝てるようになれたら嬉しくて、負ければ悔しくて、なのでみんな必死になってコマンドを覚えるし、正確に入力できるようになろうとする、そういうモチベーションがある。

翻ってブラウザのUIという物を考えてみると、誰が好きこのんで複雑なコマンドを覚えたくなるの? ブラウザを上手く使えるようになる努力をして、上達して、それのどこが嬉しいの? って話なんですよ。普通のユーザにとって、ブラウザとかUIとかってそんな努力を費やす対象ではないです。勉強しないとまともに使えない斬新な文房具とか包丁とか、使いたくなりますか? なりませんよね。普通の人にとってのブラウザって、そういうレベルの物でしかない。

UIをデザインするんだ!って思って頑張る時に勘違いしてしまいやすいのはそこなんですよね。こんだけ頑張って斬新なUIを考えました、他に類を見ないUIになりました、ただし使うのにはそれなりに慣れが必要です、っていって作った物をユーザに見せても相手にされないですよ。そんなの作り手の自己満足でしかない。自分にとって物作りそれ自体が楽しくなってきた頃に犯しがちなミスです。

実用品のUIと、娯楽だったり趣味の物だったりのUIとは、別の物として考えて欲しいです。日常的な利用にゲーム性を加えてみましたとか、普段の利用がちょっと楽しくなりますとか、たまにありますけど、それで本来の用途に支障をきたしたりストレスが増したりするようになってしまっては本末転倒です。

自分の部屋とかキッチンとか

自分が生活する部屋や、日常的に使うキッチンの事を考えてみて下さい。

  • よく使うものは奥にしまわない。流しの下を開けたらすぐそこに包丁があるとか、毎日使う茶碗は引き出しの手前に入れておくとか、そういう風に自然となってる。逆に、奥の方にしまい込んだ鍋とかは、出すのが面倒でほとんど使わないという事も結構ある。
  • どこに何があるか、自分にとって分かりやすいような配置に落ち着いてるはず。
  • どこに何を置いたか、だいたいは把握できている。こういうことをしよう、と思った時にどこに手を伸ばせばいいかは無意識に判断できる。

ソフトウェアのUIも基本は同じだと思います。

よく使うものを手前に置くとかの話はここまでで述べた話に通じています。ここで新しく述べたいのは、「どこに何を置いたかだいたい把握してるはず」という部分です。

ロケーションバーと検索バーの統合という風に、最近は(主に表示領域を広く取るために)複数のUIを1つにまとめる風潮があるみたいなんですが、そうすると使う時に余計なステップが増えてしまいかねないというデメリットがあります。UIをどんどんまとめていくという事に固執しないで、時にはUIを分けるという判断も必要だと僕は思っています。「使い方を頑張って覚えなきゃいけない様なUIは駄目だ」という風な事を前述しましたが、並んでる物を使い分ける程度の事は大抵の人にはできるはずです。あんまりユーザをなめんなよ、ということですね。URLを入力したい時にはロケーションバーをクリックして、検索したい時は検索バーをクリックして、という事をユーザが無意識にできるのであれば、そこはUIの設計に組み込んで活かしてもいいはずです。

あと、キッチンに例えるついでに言うと、キッチンを清潔に保った方がいいのと同じでソースコードも清潔にした方がいいです。詳しくは実装の話で述べますが、生ゴミを放っておくと腐って虫が湧くように、汚いソースコードも放置すればバグの温床になりますので。

人は自分の行動パターンを変えようとしないという事

一般的に言って、フツーの人は「どうしても必要だ!」という強烈な動機がない限りは新しい物の使い方を積極的には覚えようとしませんし、いつも取っている行動のパターンも変えたがりません。というか、無意識のうちに同じ行動を取ってしまいます。そこから意識して外れようとすると、これはストレスになります。何度も述べていますが、「素晴らしいUIを作ったから、ユーザは使い方を覚えるために苦労してくれるはずだ」というのは作り手の傲慢なんですね。そんな物は、そのうち使われなくなってしまうのがオチです

ただ、あんまり人間の順応性をナメすぎてもいけません。最初は違和感があった「いつもと違う行動パターン」でも、そのうち慣れちゃうというのは結構あります。そこを考慮から外してしまうと、常用するのがウザいUI(例えば、いつまで経っても毎回馬鹿丁寧に「どうしますか?」と聞いてくるような)になってしまいます。

  • 今まで慣れ親しんできたものと同じ要領で使えるようにする。
  • 同じ要領では使えないものでも、なるべく早く慣れる事ができるようにする。
  • 慣れてしまった人に余計なストレスを与えないようにする。

これが大事なんだ、「どこまで丁寧にやってどこからはユーザの慣れに期待するか」のバランス感覚が必要だ、と僕は思っています。

この観点から、僕はKDEでのファイルのドラッグ&ドロップの操作は「馬鹿丁寧すぎ」の方に入るのかなーと思っています。Linuxのデスクトップ環境の1つであるKDEでは、ファイルを別の位置にマウスの左ボタンでドラッグ&ドロップすると、必ずメニューが出てきて「コピー」「移動」みたいなその時可能な操作を選べるようになっています。これ、最初はいいなって僕自身思ってたんですが、使ってるとだんだんうざく感じるようになってしまいました。「上の階層のフォルダにドロップしたんだから、コピーじゃなくて移動したいに決まっとるがな!」「新しくフォルダ作ってそこにドロップしたんだから、移動したいに決まっとるがな!」と、自分の場合は少なくとも、ファイルのドラッグ&ドロップは「移動」のためにやる場合が圧倒的に多かったんですね。それなのに毎回「コピーですか? 移動ですか?」って訊かれる。これがそんなにストレスになるとは、実際使い続けてみるまで僕には分かりませんでした。

なので、セカンドサーチは何も検索エンジンを選ばなければ既定の検索エンジンで検索しますし、マルチプルタブハンドラも、「グッ」と押し込む感じで敢えて長くタブの上でボタンを押し続けない限りはタブの選択操作が始まらないようになっています(このタブ選択操作の挙動はユーザからの提案で実装したものですが、採用して大正解だったと思ってます)。

ユーザの「言う事」に振り回されない・惑わされない

「ユーザからの提案を取り入れて正解だった」と書いた直後に述べるのも何ですが、ユーザの提案を何でもかんでも呑んでしまうのは避けた方がいいと僕は思ってます。

ユーザは基本的に自分の不満を素直に言ってくるもので、その提案を取り込んだ結果他のユーザにどういう影響があるかとか、実装がどう変わるかとか、そんな事までは考えてないと思っていいと思います。そういう提案をどんどん取り込んでしまうと、最初に定めたはずの「これは何をするためのソフトウェアだ」というゴール設定がブレてしまう事にもなりかねません。なので、僕はユーザからの提案に対しては、最初に決めたコンセプトに沿っているか・既存の物を壊してしまわないかという事をなるべく考えて、折り合いが付かなければ「それは取り込めない」と回答するようにしています。

タブブラウズの機能を何でもかんでも拡張するTBEというアドオンを作っていた時は、僕はわりと何でも提案を取り込んでしまってましたが、その結果どうなったかというと、ソフトウェアが肥大化するわUIが複雑化するわコードがごちゃごちゃになるわで散々でした。これは、当時の僕が名誉欲だとか人に感謝されたい欲だとかに突き動かされていたからという理由だけでなく、ソフトウェアのコンセプトが曖昧だったので、何を入れて何を外せばいいのかという判断がそもそもできなかったせいでもあるんじゃないかと、今では思ってます。

コンセプトがはっきりしていると、寄せられた意見を取捨選択しやすいです。意見を退ける時も、「それはコンセプトに合わないから」とはっきり言える。好き嫌いだとか意地悪だとかで言ってるんじゃないという、ある意味では言い訳を自分に対してできるんですね。八方美人タイプだと人の頼みを断る事自体がストレスになってしまいますが、こうすれば罪悪感を感じなくて済みます。

ということでNOと言う事の大事さを散々説いたのですが、かといって頑なになりすぎるのも良くないです。ユーザ1人だけが言ってきているのならまだしも、同じ要望・不満が別々のユーザ10人から飛んでくるようだと、これはユーザの使い方ではなくてUIの方が(ひょっとしたらコンセプトも)悪いという可能性を疑った方がいいでしょう。「なんでみんな理解してくれないんだ、こんなに素晴らしい物なのに!!」という思い上がりに囚われてしまってはいけません。

あと、意見を取り入れる時も、取り入れ方は工夫する必要があると思います。例えば「ここにこういうボタンが欲しい」という要望が来た時に、本当にそのまま言われた通りにボタンを追加する前に、なんでそこにボタンが欲しくなったんだろうかという事を考えるという事です。そこで考えた結果、やっぱりボタンを追加した方がいいという結論に辿り着くかも知れませんが、ボタンを追加しなくても別の方法で解決できるという事が分かるかも知れませんし、コンセプトの見直しを図るきっかけになるかも知れません。

余談ですが、Microsoftは製品を開発する時に、ユーザの言葉を聞くんじゃなくて、ユーザがその製品をどう使おうとしたかという様子を観察して製品にフィードバックするという事をやっている、という話を以前にどこかで読みました。ユーザ自身が自分の要望や不満を100%正しく言語化できるわけではない、ユーザ自身が気付いていない問題や視点があるのかも知れない、恥ずかしくて嘘をついているかも知れない、だから行動を見る……という話だったと思います。

Microsoftと同じ事をやるにはお金も手間もかかるのでそのままマネするのは難しいですが、そういう考え方は持っておいていいと思います。

セオリー

僕がここで述べた事は、多分UIのデザインのセオリーと言われるような事ばかりです。名前を挙げた自作のアドオンも、最初からそういう理屈を考えて作ったというよりも、試行錯誤してるうちに辿り着いた結果を後から分析してみたら案外セオリーに則っていた、という感じです。もっとちゃんと体系立ててUIのデザインの理論を勉強してから臨んでいたら、もっと少ない労力で答えに辿り着けたのかも知れないなあと思っています。

セオリーにはセオリーと呼ばれるだけの理由がちゃんとあると思いますので、我流で突っ走る前に一応は基本を抑えておくといいんじゃないでしょうか。

実装上の工夫やテクニック、コンセプトを具現化する時の注意点

プログラムとしての作りやすさに引きずられない

人にやさしい・使いやすいUIを実現するためには、プログラムとしては複雑な物になってしまいがちです。逆に、プログラムとして簡単な物にしようと思うと、エンドユーザにとっての使いやすさが犠牲になってしまいがちです。

「Now Loading…」系の物なんかは、その代表例ですよね。プログラムを作る側としては、必要なデータが全部揃うまで待ってから最後に一気に処理した方が、コードとしてはシンプルに書けます。しかし、これではエンドユーザは待たされている間何もできません。今では考えられない事でしょうが、昔のブラウザもまさにそういう設計でした。ページの内容を全部インターネット経由でダウンロードしてくるまで、ページの描画をしてくれなかったのです。

今のブラウザはそんなことは無いですよね。読み込みが少しずつ進行するに従って、ダイナミックに表示を更新して、現在までに読み込みが完了した部分から順次表示してくれます。多少作るのが面倒であっても、こういう風な設計を心がける事はとても大事だと思います。

ただ、そのようにユーザにとっての使いやすさを追求するために、プログラムとしてのコードの綺麗さを犠牲にしすぎるのも良くないです。コードの見通しが悪くなってしまうと、いざ挙動がおかしい所を見つけたとしても、どこをどのように直せば良いのか見当が付かなかったり、ある所を変更したせいで別の所に意図しない影響が発生してしまったりするため、それ以上コードに変更を加えられない(ちょっとでも変更したらぶっ壊れてしまう)、みたいな事になってしまいます。

ユーザにとっての使いやすさを大事にする事と、プログラムとしての見通しの良さを高く保ってメンテナンスしやすくしておく事は、頑張り次第で両立できます。そのためのノウハウを、ここで少しだけご紹介しようと思います。

Firefoxのアドオン開発における、避けるべきパターン

Firefoxのアドオン開発では、XMLとJavaScriptの組み合わせで「要素の振る舞い」を定義しておくXBLという技術によって「独自のタグ」のようなものを定義できます。しかし、メンテナンス性を高く保つという観点からは、XBLの利用はあまりお勧めできません。使い所をわきまえればXBLはそれなりに便利な技術ではあるのですが、「Firefoxのアドオン」の開発においては、便利さよりもデメリットの方が大きいと僕は思っています。

実際、僕は上述したアドオン「Fox Splitter」の旧バージョンをXBLを多用して開発してきましたが、XBLのせいで全体として見通しが悪くなってしまっていたり、開発時の構成に強く依存したコードがJavaScriptとXBLに散らばっていたせいで調べなければいけないコードの範囲が無駄に広がってしまったりしていたせいで、ドツボにハマってもはや自力ではメンテナンスできなくなってしまい、1年半もの間完全に放置することになってしまいました。

前述した話ともかぶりますが、不必要な多機能化も避けた方がいいです。ある機能Aと別の機能Bとで共通の処理があるから、AとBと共通の処理を1つのアドオンにまとめておこう、という風な考えに至るのはごく自然な発想だと思いますが、しかしAとBがそれぞれ全然関係の無い機能なのであれば、共通の処理を2回書く事になったとしても、AとBは別々のアドオンとして分けて開発する事を僕は強くお勧めします。

今はAとBで共通の処理を使っているとしても、Aの機能とBの機能のそれぞれのコンセプトを突き詰めていくと、共通の処理にできる部分はほとんどなくなってしまうかもしれません。にもかかわらず、「AとBとそれらの共通部分」という構成のコードがあると、この構成を維持する事に発想が囚われてしまって、AもBもコンセプト的に中途半端なままになってしまうのではないでしょうか。別々のアドオンに分けて開発していれば、そういう風に今ある実装に引きずられないで、コンセプトを突き詰めた開発をしやすいと僕は思っています。

他に思いつく事としては、ありきたりですが、プログラミングにおいて一般的なアンチパターン(これはマネしちゃいけない、という反面教師的なパターン)を避ける事がやはり大事だと思います。

例えば、1つのクラスに2つも3つも関係のない機能をまとめてしまうと、これは先ほど述べた「アドオンの多機能化」と同じような問題に繋がりかねません。それを避けるには、個々のクラスの実装が受け持つ機能の範囲を定める形で、実装を適切な粒度に分けておく事が大事です。

また、3項演算子や、論理演算子の優先順位を逆手に取ったプログラミングなどのトリッキーな書き方も、あまり多用するべきではないです。トリッキーなコードは芸術的で見ていて美しいものですが、あまりに芸術的すぎるコードは、非常に限定された条件下でしか正しく動かず、手を少し加えただけで動かなくなってしまう事もあったりして、その後の機能拡張やメンテナンスに対して脆弱になってしまいます。芸術品を作るのではなくて、実用品を作ろうとしているのだ、という事を常に念頭に置いておく事を僕はお勧めしたいです。

1年後の自分が読んでも意味が分かるようなコードにする事を心がける

1つのプログラムを1人で集中して開発している時は、プログラムの全体像が頭に入っていますから、多少読みにくいコードでも開発する事ができます。

しかし、誰かに手伝ってもらうとしたらどうでしょうか。あるいは、1年間そのプログラムの事を全く考えずにいて、1年後に急に開発を再開する事になったとしたら(1年後の自分なんて、はっきり言って他人も同然です)。読みにくいコードになっていると、「この関数は何のための物なんだろう……」とか「なんでこんな設計になっているんだろう……」といった感じで、全体像を把握できなくて何も手出しできなくなってしまいます。また、そういう状態で不用意に既存のコードを書き換えると、思わぬ副作用が発生して、今まで動いていたものが全く動かなくなってしまうかも知れません。これでは開発になりません。

前述した「1つのクラスに2つも3つも機能が入ってしまっているコード」や「あまりに芸術的すぎるコード」も、そういう問題を引き起こしがちです。そういった問題を避けるための、「1年後の自分が読んでも分かるようなコードにするテクニック」をいくつか紹介しましょう。

変数名やメソッド名、クラス名を分かりやすくする

変数やメソッド、クラスの名前は、それが何を表しているのか・何をするための物なのかをきちんと表す物にしましょう。例えば以下のようなコードは最悪ですね。

var bool = true; // 変数名が「真偽値である事」だけしか表していない

function f() { ... } // 関数に適切な名前が付いていない

これは、以下のような書き方をした方がいいです。(これはあくまで例です。表す内容がこれとは違う場面であれば、その都度適切な名前を付けましょう。)

var enabled = true; // 変数名から「何かの機能が有効か無効かを示すものだ」という事が分かる

function openTabAndInitialize() { ... } // 関数名が処理の内容を表している

ただ、名前に動詞や形容詞、前置詞などが2つも3つも入ってくるようだと、いくら処理の内容をきちんと言い表していても駄目です。関数や変数に簡潔明瞭な名前を付けられないのは、そもそも設計が悪いからと考えられます。きちんと設計してあれば、関数や変数には大抵の場合、ちゃんと簡潔明瞭な名前を付けられるのです。ですから、この例のopenTabAndInitialize()だと以下のように設計し直す事になるでしょう。

function openTab() { // 2つの小さな処理単位からなる、1つの大きな処理単位
  var tab = openNewTab();
  initializeTab(tab);
}

function openNewTab() { ... } // 新しいタブを開く、という1つの小さな処理単位

function initializeTab(aTab) { ... } // タブを初期化する、という1つの小さな処理単位

Rubyというプログラミング言語の開発者のMatz氏の言う「名前重要」というスローガンは、この事を指しています。変数や関数に名前を付ける時はちゃんと考えてから付けないと駄目で、名前付けに困る時は設計を見直す事も視野に入れるべき、という事ですね。

データに意味を持たせない。

データを表す時に、配列の1個目の要素が名前で、2個目の要素がデータの数を表して、3個目の要素がアイコンのサイズを表して……という風な作りにしてしまう事があります。

var data = ["foo", 11, 32];

こういうデータの設計はやってはいけません。「何番目のデータがこういう意味である」という風な、データの順番などがそのまま意味を表すような設計だと、順番をいちいち細かく覚えてられませんから、うっかりミスで間違えてしまいやすいです。また、こういうデータの設計だと、データ構造も変えにくいです(最後にどんどん新しい情報を付け足すというような、やっつけ仕事の解決策しか取れない)。

こういう物は、連想配列とかハッシュとか言われる形式でデータを表現する方がよいです。

var session = {
      title     : "foo",
      tabsCount : 11,
      size      : 32
    };

連想配列やハッシュであれば、ハッシュのキーがその値の意味を表すメタ情報になります

引数の多い関数を作らない

1つ前の話と同じ事なのですが、以下のように関数の引数が3つも4つもあるような関数は作るべきではないです。関数を呼び出す時に、何番目にどの情報を渡せば良いのかを間違えやすくなってしまいます。

function load(uri, title, size,
              referrer, ...)

こういうものは、ハッシュを1つだけ引数に取り、そのハッシュの値が個々のパラメータを表すという設計にしておきましょう。

load({
  title    : "foo",
  uri      : "http://...",
  size     : 32,
  referrer : null
})

このようになっていれば、引数の順番を意識しなくて済みます。

自動テストを作っておく

自動テストとは、ある関数や機能について「どういう呼び出し方をした時に、どういう結果が返ってくるか」という事を確認するためのプログラムです。具体的には、以下のような「テスト関数」が沢山連なったものが「自動テスト」というプログラムになります。

function test_getMessage() {
  // 実装を実際に呼び出してみる
  var result = getMessage();
  // 返り値は期待値と一致しているか?
  assert.equal('expected message', result);
}

ある機能Aがあって、そのAに依存するBという機能があって、Bに依存するCという機能がある時に、Cが正しく動かなかったら、さてどこに問題があると考えれば良いでしょうか。Aが壊れているのかも知れないし、Bが壊れているかも知れないし、Cが壊れているのかも知れない、このままだと何が原因なのかは分かりません。

しかし、機能AとBは自動テストでちゃんと期待通りの動作をする事を保証されていて、今まさにCを開発している場面なのだとしたら、これはCに問題がある可能性が高いと言えます。このように、自動テストがある事で複雑なプログラムであっても一歩一歩着実に開発を進められるのです。

また、自動テストは、その関数や機能が期待通りに動くかどうかを検証するものであると同時に、その機能はどのようにして使う物なのか、どういう結果が返ってくる物なのか、といった事の例にもなります。

遅延処理、非同期処理

プログラムは、上から順に1行ずつ読んで処理の流れを把握できるようになっている物ばかりではありません。ユーザの入力を待ってから次の処理を行うとか、読み込みが完了するまでの間別の処理を走らせておいて読み込みが完了したら画面を切り替えるとか、このような「人にやさしい挙動」を実現しようと思うと、上から順に1行ずつ読んだのでは処理の流れを追う事ができないような、分かりにくいコードになってしまう事を避けられません。

Firefoxのアドオン開発の場合は言語はJavaScriptを使う事になりますが、JavaScriptでは非同期処理や遅延処理が関係する場面だとコールバック関数(ある処理を呼び出す際に、その処理が終わった後で実行されるべき処理を関数として定義して渡すという物)を使わざるを得ません。そのような処理を2つも3つも連携させようとすると、コールバック関数を何十にも重ねる事になってしまいがちです。

例えば「新しいウィンドウを開いて、そのウィンドウの読み込みが完了したらコールバック関数を実行する」という例は以下のように書けます。

function openAndWait(aCallback) {
  var win = window.open(...);
  win.addEventListener('load', function() {
    win.removeEventListener('load', arguments.callee, false);
    aCallback(win);
  }, false);
}

これを使って「ウィンドウを1つずつ500ミリ秒おきに順番に3つ開いていく」という処理を書こうとすると、以下のようにコールバック関数をどんどんネストしていかないといけません。

openAndWait(function(aWindow) {
  aWindow.move(...);
  window.setTimeout(function() {
    openAndWait(function(aWindow) {
      aWindow.move(...);
      window.setTimeout(function() {
        openAndWait(function(aWindow) {
          aWindow.move(...);
          ...
        });
      }, 500);
    });
  }, 500);
});

2階層や3階層ならまだしも、これが10階層や20階層も重なると、インデント幅が増えすぎてワケが分からなくなってしまいます。また、開き括弧と閉じ括弧の間に沢山のコードが入るため、コード全体の見通しも悪くなります。

このような問題に対処するための機能が、jQueryにはdeferredという名前で搭載されていますし、同様の機能だけを提供するJSDeferredという軽量なライブラリもあります。ここではJSDeferredの使い方を少しだけ解説したいと思います。

JSDeferred

先の openAndWait() という関数は、ウィンドウの読み込みが終わった後に次の処理としてコールバック関数を実行する物でした。これをJSDeferredを使って書き換えてみた物が、以下の例です。

function openAndWait() {
  // (1) Deferredクラスのインスタンス(Deferredオブジェクト)を作る。
  var deferred = new Deferred();

  var win = window.open(...);
  win.addEventListener('load', function() {
    win.removeEventListener('load', arguments.callee, false);
    // (3) 読み込みが終わったら、返したDeferredオブジェクトの
    //     call()メソッドを呼ぶ。
    deferred.call(win);
  }, false);

  // (2) Deferredオブジェクトを返り値として返す。
  return deferred;
}

このように書き換えた関数は、以下のようにして「次の処理」を記述できるようになります。

openAndWait()
  .next(function(aWindow) {
    aWindow.moveTo(...);
  });

それどころか、さらにその先にもまだまだ「次の処理」を続けて記述できます。

openAndWait()
  .next(function(aWindow) {
    // 読み込みが終わったら実行
    aWindow.moveTo(...);
  })
  .wait(0.5) // 500ミリ秒待つ
  .next(function() {
    // 次のウィンドウを開く
    return openAndWait();
  })
  .next(function(aWindow) {
    // 読み込みが終わったら実行
    aWindow.moveTo();
  })
  .wait(0.5) // 500ミリ秒待つ
  ..

JSDeferredを使うと、何個も処理を重ねる場合でもコード上のネストがあまり深くなりません。また、コールバック関数を重ねる場合と異なり、コードを読む時に上と下を行ったり来たりする必要もありません。コールバック関数を1個目の引数に受け取るのか2個目の引数に受け取るのか、といったインターフェースの違いも意識しなくて済みます(全ての非同期処理を統一的なインターフェースで利用できるようになる、とも言えます)。

詳しい事はJSDeferred開発者のcho45氏自身による解説を読んで下さい。JSDeferredを使いこなせるようになると、表現の幅がぐっと広がります。

先に名前を挙げたアドオンFox Splitterも、JSDeferredに強く依存しています。Fox Splitterは新しいウィンドウを開いて位置や大きさを制御するという事をやっていますが、ウィンドウが開かれるのを待って次の処理に進んだり、ウィンドウの位置が確定するのを待って他のウィンドウの位置を調整したり、といった感じで「前の処理の完了を待ってから次の処理を行う」場面が非常に多いです。僕はJSDeferredのおかげで、そういった処理の前後関係を意識しないで複数の機能と機能を連携できるようになったために、Fox Splitterを無事完成させることができました。

前述した「ユーザの入力を一旦受け取って、入力が完了した後に次に進む」というような事も、JSDeferredを使えば比較的簡単に処理を記述できるでしょう。人にやさしいUIを作る上で、JSDeferredのようなライブラリは非常に役立ちます。

とりあえず作ってみるという事

UIのアイディアを思いついたら、あれこれ計画を練って検討するのもいいですが、さっさと実際にプロトタイプを作ってみることを僕はお勧めしたいです。

コンセプトを形にする事は重要です。形にして実際使ってみて初めて分かる事もあります。プランを練っている時には「素晴らしい」と思っていても、実際使ってみると「アレ?」って事はよくあります。手早くプロトタイプを形にして、コンセプトが正しかったかどうかを初期段階で確認して軌道修正をするのが、後で痛い目を見ないで済むようにするコツです。問題点の発覚が遅れれば遅れるほど、取り返しが付きにくいです。

ブラウザのアドオンは、そういう意味では格好の実験場だと僕は思っています。

これは、大学の卒業制作でMozillaの拡張機能として「こんなUIがあってもいいんじゃないか?」という物を作った時に考えた理屈なのですが、ブラウザのアドオンとしてプロトタイプを作る事にはいくつかのメリットがあります。

  • 既にあるソフトウェア資産を流用できる。いちから自分でブラウザを作るのは大変だが、アドオンとして作るのなら、ネットワークの通信だとかそういった部分を考えなくても済む。
  • ユーザに使ってもらう時の障壁を低くできる。今まで使ってきたWebブラウザの延長線上として、全く新しい別の物を使い始めるのに比べれば少ない学習コストで使ってもらえる。

Firefoxのアドオンの場合、ソースコードがオープンソースなライセンスで公開されている場合が多いというのもいい所です。分からない所があれば、やりたい事に近い事をやっているソフトウェアのソースコードをそのまま参考資料として参照できますし、ライセンスが定める条件に従ってさえいれば、そのままソースコードを流用する事すらできます。

ちなみに、「オープンソースの物を流用したら、その成果もいきなり全世界に公表しないといけないんでしょ? それじゃ秘密裏に実験的な事ができないじゃないか」という風に思う人がいるかもしれませんが、それは誤解です。例えばGPLなどのライセンスでは、ソースコードを流用して作ったソフトウェアのユーザに対してソースコードを開示する義務はあっても、ソフトウェアを渡されてもいなければ存在も知らないような人相手にまでソースコードを開示する義務はありません。安心して下さい。

デバイスの進歩について

質疑応答で少し話しましたが、ソフトウェアのUIとハードウェアの進歩は切っても切れない関係にあると思います。

「複雑なマウスジェスチャは覚えられないから使い物にならない、シンプルな動き以外はまともに使えない」という風な事を前述しましたが、MacやiPhone、iPadで可能な2本指・3本指でのジェスチャ(マルチタッチ)は、その制限を乗り越える技術です。指2本を開くような動き(ピンチアウト)で画面の拡大、指2本を閉じるような動き(ピンチイン)で画面の縮小、という風に、簡単でありながら表現力豊かなジェスチャ操作が可能です。これはハードウェア側のサポート無しには成り立たないUIです。

Panoramaはモーダルなせいでいまいち使いづらいですが、これはPCの画面が狭いという現在のデバイスの制約による所が大きいと僕は思っています。もしPCの画面が物凄く広ければ、あるいは、画面の外に空中に映像を投影するような技術があれば、Panoramaはモーダルにしないで常時表示しておけるかもしれません。

今あるハードウェアの限界の中で使いやすいUIを考える事も大切ですが、できない事はやっぱりできないので、そこは潔く諦めてハードウェアの進歩を待つといった判断も必要では無いかと僕は思います。あるいは、ハードウェアの制限に合わせる形でもっと別のUIを考えてみるとか。いずれにしても、今あるハードウェアの上では使いにくいと言わざるを得ない物を「理論的には使いやすいはずなんだ」みたいな感じでごり押しするような事はしないで、柔軟に考えるようにして下さい。

ターゲットユーザを誰にするのかという割り切り

僕の場合は、今は自分自身が第1のターゲットユーザだと考えています。自分自身が常用するものだからこそ、クオリティを維持して快適な状態を保ちたいと思える。というのが今の僕の考えです。

自分以外の人をターゲットユーザに想定するのもありだとは思いますが、僕の場合は既に20を超えるアドオンを開発していて、それぞれにバグ報告が来て修正のためにてんてこ舞いになっているというのが実情で、自分で使う物についてすら十分なメンテナンスをできていない状態にあります。自分自身を第1のターゲットユーザとして考えるというのは、コンセプトをブレさせないための方法論でもありますが、ユーザから寄せられる大量の要望から距離を置いて自分の身(精神)を守るための手段でもあるんですね。

誰をターゲットにする場合であっても、基本的な所はセオリー通りにやる事が大事なのだと僕は思っています。その上で、例えばお年寄りのための物にするなら文字を大きくするとか、使う言葉を平易にするとか、応用を組み合わせていく事になるのだ……と、僕は思っています。

道具を自分に合わせないと我慢できない人と、道具に自分を合わせるのが苦にならない人がいる(11時20分追記)

カスタマイズ性の高いブラウザだからみんなカスタマイズしたくなるかというと、そうとも言えません。統計として、Firefoxのユーザの全員がアドオンを使っている訳ではなく、また、アドオンを使っている人でもインストールしているアドオンの数は片手で数えられる程度である場合がほとんどだというデータが、過去のMozillaの調査で出ていました。カスタマイズ性の高い設計になっている事と、実際にカスタマイズして使われる事とは、あくまで別の事なんですね。(この調査結果は、Firefoxの初期状態が普通の人にそれなりに使いやすい形になっている事の顕れと言えるとも思います。)

僕自身は、ペンタブレット(ペン型の入力装置を使って、ペンで字や絵を描くのと同じ感覚で入力を行えるデバイス)を使う時に、指に当たって痛いなーと思ったらペンの軸に何か巻いてみたりプロテクターのような物を作って付けてみたりと、DIYで「カスタマイズ」して使っています。漫画家の人の中には、ペンの軸が長すぎるからとノコギリでぶった切って使っている人もいるそうです。

でも、そういう風にしない人もいるんですよね。使いやすいと思えるありものの製品を別に探したり、使いにくいから使うのをやめてしまったり。そもそも、自分が使いやすいと思うようにカスタマイズするという発想が無いという人もいるのだと思います。

僕自身、あまり拘りを持っていない分野ではそういう行動を取っている気がします。僕は料理をする事が好きで好きでたまらないという人ではないので、調理器具は買ってきた物をそのまま使っていますし、少々使いにくいと思っても面倒だからそのまま放置しています。カスタマイズしてでも使い続けるかどうかは、「なんでもカスタマイズしたがる性格」の有無以外にも、使いにくさを乗り越えてでもそれを使い続けるに足る動機があるのかどうか、どれだけそれを切実に必要としているのか、という事も影響しているのかもしれません。

そう考えると、カスタマイズ性を高くしておきさえすれば万事オッケーとは言えないのだと思います。僕自身、車や自転車にそれほど強い関心があるわけではないので、「タイヤをこれに替えるともっと快適だよ」と言われても「ふーん、そうなんだ。まあ面倒だから僕はそのまま使い続けますよ。」って思ってしまいますし、そのまま使い続けるのが辛いくらいに合わなければ、カスタマイズを検討する前に他の車や自転車に乗り換えてしまうのではないかと思います。同じように、Webを見る事に対してそれほど切実な動機を持っていない人に「カスタマイズすればもっと使いやすくなるよ」と言っても、「面倒だし別にいいよ」って多分言われてしまうでしょうし、その人が「なんかこれ使いにくい」って言ってる時に「カスタマイズすれば解消できるよ」と言っても、「自分で手を入れなきゃ使いやすくならないの? そうなんだったらもう最初から使わないでいいや……もっと別の物を探すよ」と言われてしまうと思います。

ほとんどの「ユーザ」はそういう物だ、と僕は考えるようにしています。だからこそ、デフォルト設定を使いやすくした方がいいとか、初見で使えるようにした方がいいとか、そういう事を言ってるんですね。

ブラウザのアドオン、である理由

今プログラマ的にアツい分野というとHTML5とかWebサービスとかクラウドとかっていう話になると思うんですが、僕がWeb開発じゃなくブラウザのアドオンの開発をやり続けてる理由は、インターフェースとして、より人に近い部分で動く物を作れるからなんだと思います。

ユーザの何気ない無意識での入力をトリガーにして適切な次の処理をサジェストするというのは、普通のWebページやWebアプリの枠を超えた部分の話です。サジェストされる選択肢の1つとしてWebサービスに誘導するのはもちろんアリだと思いますが、起点になるのは特定のWebサービスの画面ではなくて、ブラウザのUIだったりスマートフォンのホーム画面だったりという、もっとユーザに近い部分になるはずです。

そこの所への関心が強いから、僕はWebアプリよりもアドオンを作るのが好きなんでしょうね。

Page 26/248: « 22 23 24 25 26 27 28 29 30 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき