変化し続けるという安定
このところ、インプットモードになっていましたが、そろそろアウトプットで整理していきたいと思います。インプットした内容は、主に技術ではなく生き方が中心でした。が、自分にとってはデザインやビジネスチャンスにつながるヒントばかりだったので、それを少しずつまとめていきたいと思います。
- 個人によって安定と変化の定義が違う
- 変化し続けることが安定と感じる人種がいる
- 変化するにはぶれない軸が必要
安定とはそもそも何か？
ここ最近は、技術の勉強というよりは、人との交流を通じて人を知り、分析するという機会に恵まれていました。自分が考える展望があり、その裏付けを取るために、とにかく人と話すという時間を設けていました。
その中で、「安定」という言葉が常につきまといます。精神の安定、肉体の安定、様々ありますが今もって直面しているのは環境の安定を望む人がそこかしこにいるということです。青森は公務員が多い土地ですから、なおさら感じることではありますが、恒久的に変わらない環境、常に同じことの繰り返しによって続く日常を安定と考える人が多いようです。むしろ、それが一般的だろうと思います。
しかし、新しい知識や技術を望んで、飛びついて行く性分の人間(つまり自分)からすると、上記の安定は「停滞」と捉えます。どちらが良いか悪いかという話ではありません。すみ分けであり、割りきりであると考えています。
そして、安定の定義によって、変化が正の影響なのか、負の影響かが大きく分かれていきます。
キャズムの理論を人の生き方に適用する
ここのところ、パタンランゲージとしてのマーケティング理論に興味があり、キャズムを読んでいます。キャズムでは新たなテクノロジーに対する購買層をいくつかに分類していますが、これは人の生活様式をハイテクマーケティングという視点からとらえた理論だと私は思いました。
おそらく、技術者という職を選び、その中で自ら何かを生産しようと行動していくと、自然と環境の変化を観察し、その変化を自分の中に受け入れようという思考が働き出します。それは、新しい要素技術の習得であったり、勉強会への参加であったり、ブログでの発信だったり、手法は様々だと思います。
結果、「今日の自分は、昨日の自分とは違う」ことを実感していきます。これが私にとっての変化です。時代とともに価値観が多様化し、昨日までの常識がくつがえされるという事態が、技術の世界以外でも断続的に発生していることを目の当たりにするにつれ、その状況に対応できるか否かが真価であると、自分の価値観が構築されていく感覚がありました。
対応し、変化し続けているという事実の維持が、私にとっての安定なのだと強く思うようになってきています。それが上昇なのか下降なのかはわかりませんが、前進しているということに疑いはありません。
慣れるのは武器
だからといって、もう自分は大丈夫だとか、この先を食っていけるなんていう気分にはさらさらなれません。明日の自分を保証するものは何もなく、私にとって保証されているのは、明日の自分を保証するのは自分しかいないという事実だけです。
ですが、人間とは素晴らしい生き物で、その不安にすら慣れていき、受け入れることができるようです。システムのUI設計においてもそうです。初心者が新たなUIに慣れていき中級者となることで、次の不満なり、新しい発見がでてきます。それらに解答を出すために、また機能追加や再設計、修正といった何らかの行動を起こします。
同じサイクルが人の生活様式にも起こりうるということなのでしょう。
このサイクルを少しずつ大きくしたり、加速させていくことが成長という変化であると思います。
別に新しい話でも何でもありませんし、今更の内容ではあります。しかし、このサイクルを体現できているということ、サイクルの成長に必要なものは何かを自覚していることこそが大事だと考えています。
cygwinからmanage.pyを起動できない
だいぶブログがご無沙汰でした。コーディングでのインプットと人と会うことがメイン業務でブログをまた怠け・・・なんでもないです。
現在、とあるWEBアプリのプロトをDjangoで開発中。といっても、Djangoに慣れようとしているところ。そもそもPythonが初めてですが、Rubyやった後だと違和感少ないですね。
現象
>python manage.py validate
Traceback (most recent call last):
File "manage.py", line 2, in ?
from django.core.management import execute_manager
ImportError: No module named django.core.management
原因
cygwinでインストールしたPythonとWindowsバイナリとしてインストールしたPythonどちらを呼び出すべきかわからなくなっていた
解決策
WindowsバイナリのPythonを利用することにし、cygwinからPythonをアンインストール
初歩的なミスを・・・
WHDAレギュラーミーティング#004いってきました
6/21にWDHAレギュラーミーティング#004が開催されました。前回に引き続き、また発表をさせてもらいました。
- ワークショップ＋座談会＋和室これ最強
- 懇親会への会場移動がないと発表中のテンションのまま話せて盛り上がる
- 今後は学校や他コミュニティと合同で開催してみる
第1部は私で「UI設計の基礎トレ」と題して発表しました。ここのところ「自覚的デザインシリーズ」と称してUIについて当たり前と思っていることを自分なりに考えてみているのですが、現段階での結論についてと、まだブログ上では踏み込んでいないところについても話しました。
IWDDで話した内容とフィードバックを交えつつですが、各UIの実例のラベルづけをもう少し考えたいなと思うところ。
また、SKK情報ビジネス専門学校から参加されていた方から、「学生相手にやってみない？」とのお声。WEBデザインやプログラマ向けのコースの授業でと。であれば尚更、このスライドは練りこんでいく必要がありますね。
というわけでSlideShare初体験。やっぱりいいですねこのサービス。(スライド下のViewのリンク先からダウンロードできます)
スライドでの発表後に、この内容を踏まえてワークショップ形式でサイトデザインをしました。流れとしては、
- 要件説明。今回はWDHAのサイトをデザインすると仮定。
- WDHAのサイトに最も重要だと思うことを、コンテンツ・機能・ビジュアルについてそれぞれ1行で書く
- ワイヤーフレームを書く
- 自分のデザインの根拠を3行で書く
- グループ分け(2つ)
- グループ内でそれぞれの意見を持ち寄ってデザイン
- お互いにプレゼンする
実は最初の要件で大きな縛りを設けていました。予算がないので1ページに収める。無茶苦茶かもしれませんが、そのぐらいの制約があった方が良いアイディアも出るというものです。
そんな制約お構いなしにビジュアル重視で作りこむグループと制約を守って機能重視で作りこむグループと対照的な結果になったのは良かったと思います。
ビジュアル重視のグループは、アンカーリンクで1ページに収める手法をとり、アンカーリンク移動の煩わしさを船のイカリが下りていく動きになぞらえることで移動の様子に意味を持たせようとアプローチ。
機能重視のグループはAjaxによってページ遷移をなくすることで、1ページに収めたように見せかける手法を取っていました。
それぞれの成果物とメンバ構成を見てわかったのは、プログラマの存在でアプローチが変わってくるようです。プログラマが入ると、どっかでCGIが動いていることが前提になっているように見受けられます。
WDHAは業種が割とWEBデザイナ多めに偏っているので、制約を練りこんで、わざと偏ったメンバでワークショップを行った方が、おもしろい成果が出そうです。
第2部はOQUGAR-DESIGNさんによるWordPress入門でした。実際のソースを交えながら、テンプレートの使い方や実際に使った時のはまり所などについて。
個人的にWordPressは非常によくできてるなと思いますし、いざとなったらPHPでゴリゴリしちゃえばいいし(邪道)という逃げ道があるので好きです。
あとはOQUGARさんから、うまく動かないのですがこれはどう書けば？という話が出たので、その場で修正。無料です。
会の最後に、今後のWDHAの方向性について話していたのですが、県内の専門学校などを開催場所にして、学生を交えつつやってみるとか、岩手・秋田と合同でやってみるか？とか、活動範囲が広がっていきそうです。
実は東北という単位でみると、こういったコミュニティが多いのだとか。コミュニティを越えて設計合宿やったりして、自分たちで何かサービスを立ち上げたりするところまで行きたいというのは個人的に考えているところです。
話は変わりますが、Ruby勉強会@青森を開催しよう！ということで水面下で進行中です。
RubyKaigi2008やRejectKaigi2008が開催され盛り上がりを見せているRubyですが、青森にもその波が。業務でRubyもRailsも使っている者として、新たな出会いや情報がありそうで楽しみです。
といいつつ、Google App EngineでDjangoにひかれてて、とりあえず仮サービス立ち上げたいし、そっちもいいよなとか思ったり。勉強したいことが溢れるほどあるというのは幸せなことですね。
お仕事の道具を晒してみる
最近、ひたすら頭フル回転でエントリ書いてたので、ちょっと箸休め的なものにしました。自分の思考をまとめるためとはいえ、脳みそが焦げ付きそう。
最近、GTDの考え方をもっと取り入れて行こうと思ったのをきっかけに、身の回りの道具を見直してみました。
私はスーツの時とカジュアルの時で持ち歩く鞄を変えていて、カジュアルの時に使う鞄は軽くていいのですが、収納力がかなり低い・・・けど、見た目以上の収納力と軽さが気に入ってまして。欠点はスーツに似合わないことぐらい。
持ち歩くのは基本的にmacbookと筆記用具とかメモをすぐに取れるA4用紙とかアイディア帳とか、意外と小物が多いんですよね。すると、鞄を使い分けると道具を集約してないがために面倒なことに・・・
というわけで、ブリーフケースを購入。これが良い！基本的な道具は全部ここに入ってるからいいやと、どこにおいたっけ？とかがなくなってスッキリ。大きさもたっぷりだし、中身が見えて道具を取り出しやすいしと、個人的にかなり気に入ってます。
これが350円ぐらいで買えたのだから、すごくコストパフォーマンスいいなと。それと、ついでにインデックス付きのクリアファイルも350円ほどで購入して、そのブリーフケースに入れてます。これも便利！最後尾には白紙のA4用紙入れて、打ち合わせで絵を描きながら進めたい時には重宝するし、ファイリングもできて一石二鳥。
自覚的デザインを目指す その2
前回のエントリではModelからViewへの写像と、視線誘導における前提知識みたいなことをまとめてみました。今回は、視線誘導の形にどういった種類があるか考えてみようと思います。また、分析に加えてUIとして個人的に思うところも書いていきたいと思います。
- 視線はZ、N、L、ランダムとリンクの組み合わせで構成される
- 視線移動のヒントを視界の一部に捉えさせる工夫が必要
- 視線の開始位置を基点に次を予測できるようにレイアウトを決めて行く
始点が左上か右上かで視線の方向は決まる
まず、ごく基本的な視線の動きを考えてみます。文章で考える場合、文章は文字列という1次元のModelです。それを最大の横幅が決まっている領域を持つViewに対して写像すると、「折り返し」が発生します。つまりX軸とY軸の2次元への写像となります。これを考慮して代表的な形式を考えてみます。
- 欧文(横書き)
- Zの動き。左から右に向かって進み、折り返した後に、上から下に向かって文章の最後まで左から右に進む動きを繰り返す。
- 邦文(縦書き)
- Nの動き。上から下に向かって進み、折り返した後に、左から右に向かって文章の最後まで上から下に進む動きを繰り返す。
- 折り込みチラシ
- ランダムに視線を移動する。各情報の優先順位や重み付けがあまり無いので、どこから見始めても良いし、次に見る場所が制限されていない。
- Windowsエクスローラ
- Lもしくは逆Lの動き。任意の列を上から下に向かって進み、目的の情報が見つかるか、関連があると思われる情報の位置に来た所で、左右どちらかの方向へ動く。
基本の動きを組み合わせてみる
では、上記のようなパターンを組み合わせてみます。個人的にUIが優れていると思っている実例をあげます。分析してて自分で思ったのは、新聞というUIは非常によく考えられているということでした。以後、逆Nという言葉が出てきますが、これはNを左右反転させたものを意味します。
- 新聞
- Z + N + ランダムの動き。遠目から見ると、ランダムに記事が配置されているように見えるが、基本は右上からNの動きとなる。しかし、見出しの強調によって、ランダムに視線を動かすことがほとんど。
その代わり、見出し周辺の文章を縦書き、もしくは横書きでブロックになるよう構成し、見出しにフォーカスした後にどう読み進めるべきか誘導している。 - wikipedia
- 逆N + Z + リンクの動き。左上を始点として、基本はZの動き。ただし、左側にグローバルメニューとなるサイドバーがあるため、逆Nの視線移動となる。装飾は最小限に抑えられ、リンク色もデフォルトのままとしているので、予想外の動きがなく違和感無く読み進めることができる。
- iTunesのグループ表示
- 逆N + Z + L + ジャンプの動き。かなり複雑な組み合わせだが、あくまで基本の視線移動の組み合わせ。サイドメニューから任意のプレイリストや項目を選択した後に、右側の一覧へ逆Nの動き。次にブラウズをZの動きで見ながら絞り込み。検索結果に対し、アートワークを基準に縦方向に探すLの動き、もしくはすでにアルバムまで特定している場合には、楽曲一覧に対してZまたはLの動きで見て行く。
また、希望の情報が見つからない場合には、Finderに向かって一気に視線をジャンプさせる。これはFinderが検索結果を変化させることができるという前提の植え付けによって行われる。
サイドメニューは左なのか？右なのか？
図で説明すれば簡単なんですが、あえて言葉にしています。疲れます。でも自分にとっては文章にするのが大事なんです。続けます。
さて、上記の実例のうち、wikipediaとiTunesに共通していることがあります。それはサイドメニューの位置が両方とも左であるということです。
いつからか、WEBの世界では右にグローバルメニューという考え方がでていました。個人的には違和感があります。結論としてはケースバイケースですが、情報の優先度や流れを自覚できているかどうかが大事と考えています。
頻繁に使われるものは、視線移動の開始位置が左上であれば、やはり左から始まる方が自然と考えます。加えて、ユーザが利用する機能の流れと一致していることが大事です。WEB以外で考えた場合、Visual Studioの画面作成モードでは、まずコントロールを選択する場所が左。実際に配置する画面が中央、そして配置したコントロールに対するプロパティは右と処理の流れにそっています。
逆に疑問を持つ例として私が真っ先にあげるのはブログの3カラムと右側にグローバルメニューを配置した場合です。ブログに関してはここのところ、3カラムでメインが左で右2カラムに残りをというレイアウトも見られます。これらについては、そのコンテンツの特性を考えれば答えは出せると思います。
ブログはその特性として、「トップに最新」「ユーザは最新の記事を基本的に追う」という2点があると思います。そうすると、真っ先に見たい情報はトップにあります。そしてZの動きで文章を読むとすれば、ブログの記事自体は左というのが自然と思います。その反対におくのは、記事よりも優先度の低いもの、もしくは記事を読んだ後に進むべきものとします。
ユーザを大きくリピータと初見に分けるなら、リピータにとっては視線移動の開始位置に記事があるというのは余計な視線移動がなく好都合と考えてくれると思います。初見については、Googleから検索してたどり着くか、リンクをたどってきたとして、他の記事も読みたいと思ったときに初めて、今見ている記事以外のコンテンツについて視線を移動すると思います。その場合、右にメニューがあるのはZの動きで考えると自然に動かせるでしょう。
ただし、スクロールによってサイドメニューが見えなくなっている場合には、逆Nの動きで画面ごと上部に戻って、右へ視線を動かす事になります。それを考えると、記事を読み終わった時にフッタで他の記事への誘導を見せるというのも余計な視線移動がなく、自然だと思います。
予測できる=解りやすい
様々なUIを見て思うのは、自分が行おうとしている動きについて予測しやすいというのは、非常にストレスが少ないという事です。おそらく、自分で思うようにコントロールできるという意識を植え付けるからです。
予測しにくいものでおもしろさをという場面は間違いなくありますが、日常的に使うもの、使用頻度が高いものについてはストレスにしかなりません。予想外がおもしろいのは最初だけ、つまりインパクト勝負になってしまいます。
私がUI設計の時に心がけているのは、複数回使うことを前提に、使うほど便利になっていくようにすることです。その場合、「予測しやすい」というのは短時間で慣れ、作業速度を上げて行くことに一役買います。もちろんここには、操作デバイスという概念ははずせないのですが、今は視覚に絞って進めて行きます。
ここまでで、ようやく外枠の部分が決まりました。次はより細部について考えて行きたいと思います。「予測しやすい」という側面で考えてきましたが、最も利用者の多い方法は常識となる - つまり、「デファクト」に従うことも必要ということについて考えてみます。
自覚的デザインを目指す その1
IWDDミーティング#23でUI設計を人間の視覚で考えるという手法について発表しました。が、前回のエントリで割愛した内容について補足しながらまとめて行きたいと思います。
- 現代的にModel設計はプログラマの仕事、View設計はデザイナの仕事
- Modelは不変でViewは可変
- 人間の脳は立体(3次元)で情報を捉えて平面(2次元)に写像している
ModelからViewへ写像するのがデザイン
Modelというのは複数の次元からなる情報のカタマリをここでは指します。バブルマップを私が解釈すると
- X軸：内容
- Y軸：達成度(進捗)
- Z軸：優先度(期限、ストレス)
となります。この3次元で構成されるModelだという解釈ですね。なぜこういう解釈にできるのか？と言われると、これがいわゆるプログラマと呼ばれる人たちにとっての「設計」にあたる部分なので一言では語れません。分析的思考は経験則によるところも大きいですし。そもそもModelの次元は3とは限りません。ですが、人間が一度に処理できる情報に限界があるため、様々な制約を利用して次元を絞っているという側面があると思います。
よって、Modelはn次元と考えることにします。
では、Modelができたところで、人間が見る・使うとしてどういうUIにするか？という話になります。ここでViewという概念が出てきます。ViewというのはModelを人が視認できるように平面に結び付けた結果です。ここが、いわゆるデザイナと呼ばれる人たちの本業となる所だと考えています。
あえてプログラマとデザイナという分け方をしましたが、実際のところは責任範囲を分けず、どちらも考えられるのが一番よいと思います。そして、Model設計というのが最近のWEBデザイナに求められる分野かなと思っています。
ModelとViewの違いについて考えると、Modelは不変に近く変更が難しいです。これについては歴史的経緯とかデファクトスタンダードとかが概念として絡んできます。これに対し、Viewは視覚化に対する解釈の違いなので変更が簡単です。カレンダーで考えてもらえればわかると思いますが、「年月日」というほぼ普遍のModelに対し、日めくりや月めくり、年間カレンダーや週間カレンダーと様々なViewがあります。
このModelからViewへの遷移を写像と呼ぶことにします。
人間の眼は平面でしか見ることができない
導入としてModelからViewへの写像について書きましたが、あえて「平面に結び付けた結果」としたのは、人間の視覚が2次元でしか見ることができないという前提があるからです。ここからは遠近法についての話になってきます。人の眼は物体の位置関係を大きさと角度を利用して把握しているとされています。
先のリンクで透視図についても触れていますので説明はそちらに任せるとして、結局のところは立体に見えるように錯覚しているだけということです。
では、n次元から平面への写像を行います。ここで視線誘導という考え方がでてきます。この視線誘導については、人間が一度に視認する情報量という側面から考えていくことになります。
先ほどのカレンダーは視認する情報量を変えることによって、その機能を実現していると考えられます。年間全体を通して把握するのか、月なのか、週間なのか、今日だけなのか。
これは、年月日というModelについて一度に把握できる日数、つまりViewを変えることで、UIを実現していると考えられます。現在把握できる年月日が過ぎたらめくるという機能しか実はありません。が、視認できる情報量からViewを変えることによって、UIとしては全く別物に変わっているのです。
では、視線誘導としてどんな手法がとれるのか？これを次回のエントリで触れていきます。
IWDDミーティング#23いってきました
いきなり話は飛びますが、人間の視認能力の限界は思いのほか低いそうです。なので、サマリを頭に３行でつけるというのを今後やって行こうかなと。というか、自分で書いたエントリを読み直して長いしまとまってないしで云々とりあえず改善したいということです。
- 地震の影響でRails祭りは次回以降に持ち越し
- Visual Web Developer 2008 便利すぎ
- ワークショップのいい所は全員が発表者になれる
100% Railsで開発するならサーバ屋になるしか？
当日はRails勉強会@東北からの参加予定もあったのですが、地震によって不参加確定。これに関してはまた機会があるでしょうし、仙台での開催に一度、足を運ぶ方が早いのかもしれません。
開発よりの話もそうですが、Railsはようやくmod_railsが出てきて、共用サーバでRailsが動く日が来そうですが、まだそれは先の事でしょう。
Railsは今のところ、専用サーバでしか使えませんが、Rails勉強会@東北から参加される方々は、100% Railsで開発というチャレンジャー。「Rails屋」なんてどうやったら・・・？と思ったら、自分たちでホスティングしているとのこと。ですよね。
短納期、低予算、高機能という要求が来た場合、今のところ運用費として専用サーバだけは我慢してもらってRailsでスパイラルモデルというのが私としては現実解です。共用サーバで動かせるという要件を満たすために、PHPでRailsもどきを作り、簡易ActiveRecordも作りましたが、何か努力の方向が間違っている気がしてなりません。
ですが、Railsの肝とも言うべきActiveRecordを追って、自分なりの解釈で作ったのはいい勉強になりましたけどね。
そのうちDreamweaverもAptanaもいらなくなるかもしれない
私はAptanaをIDEとして使用しています。理由は
- Railsの開発も同時にできる
- SVNがIDEに組み込み済み
- 複数ブラウザチェックが楽
といったところでしょうか。ですが、Visual Web Developer 2008がかなり良さそうです。
- Microsoftの補完はさすがの一言
- IE以外のブラウザチェックも可能
- Javascript補完もOK
- GUIベースのHTML作成もできる
Microsoft製のIDEは使い慣れてますから、フィールがなじんでいるというのも大きいです。惜しむらくは、バージョン管理のプラグインは有料である事、AjaxベースのJavascriptデバッグは無理(当たり前だけど)。デバッグはFirebugがありますが、IE上のデバッグはその仕様上いかんともしがたいので今後に期待。
少なくとも、私にとってDreamweaverを使う理由はなくなりました。が、RailsでのというかCGI関連の開発を考えると、SVNでソース管理をしているので、しばらくはAptanaになりそうです。
人間の視線誘導とUIの関係について議論中
そして、オープンUI設計をしてみるという名目のもと、バブルマップアプリについてアイディア募集してみました。というのは実は後付けでして。
発表者はもう１人一緒にいったプロジェクトメンバだったのですが、ここの所の情報を次元で考えるという議論について、私たちが出した今の結論を発表させてもらいました。
これは、このブログでの公開用にもうちょっと手を加えて作り直したい所。ModelをViewに対してどう写像するか。つまり、n次元の情報を2次元で表示するとしてどういった手法がとれるか？という点を欧文・邦文の書体や新聞、はたまたiTunesのUIを例に分析するという内容です。
実はこの内容も割愛した点が非常に多く・・・本当は遠近法におけるフォーカスの話や時間軸を4次元目としていれた場合の人間の情報認知などもあります。が、ここら辺は内部で議論中のところもあるので、またの機会にとしました。というか、このブログでも書いて行きます。
TODO管理の手法は業種によって様々。だがそれがいい。
バブルマップアプリは、もともとはTODO管理に気持ちよさとソフトウェアならではの利便性を追加という名目でしたが、IWDDの方々の意見で大きくその仕様を変えようと思いました。
やはり皆さんの日々の業務と直接関わる所ですから、アンケート形式で意見をもらいながら初めて見ると、アイディアがもうこれでもかと出てきました。そもそも、TODO管理はやってないです。という方の意見も非常に参考になりました。
これも別エントリとしてまとめたいと思います。ただ、時間軸を足すという方向性は合っているようです。あとはその実装の仕方ですね。
ひさびさにブレインストーミングをやった
大まかな流れとしては
- 白紙に問題提起をして、解決方法に文章を置き換え
- 付箋に１分〜３分で数セットのアイディアだし
- デザイナとプログラマを混ぜてグループ分け
- 模造紙に付箋を貼って整理
- ホワイトボードにワイヤーフレーム作成
- お互いのグループに向けてプレゼンテーション
その最中に若手育成の心遣いがあったりと、久々のワークショップ形式を楽しみつつ参加しました。IWDDのサイトリニューアルをという名目で、「IWDDのサイトの存在感を出すには？」という大テーマは出されていました。個人的に思ったのは、ブレインストーミングでもマインドマップでもいいのですが、この手のはテーマの具体性と参加者の背景共有がポイントで、事前のテーマについてのミーティングがなかったように見受けられたので、自分もですが、ややアイディアが散漫かなと思いました。
とはいえ、そこはIWDDの方々が自分で作ったサイトな分、理解度の高さで補えているようでした。あと興味深かったのは、私がいたグループはデザインの指向が王道的だったので、ちょっと破壊的なアイディアを出す立ち位置を振る舞ってみました。こちらのグループは機能中心で、向こうのグループはコンテンツとレイアウト中心という印象を受けました。
今後のリニューアル結果が楽しみです。
情報の往来と共育
最後に全体を通じての雑感を。IWDDは23回という開催回数をこなしているだけあって、既に様々なミーティング手法を試しており、そのノウハウは貴重です。加えて、青森と比べるとより情報の往来が多いと感じました。参加者比率が良い意味でバラバラなんですよね。
こういうのは意見が固まらないことが大事だと思うので、アイディア出ししてる時の楽しさは心地よいものした。たくさんの刺激に感謝です。こういった交流を通じて、教え育てるのではなく「共に育つ」関係でありたいと思っています。
あと、開発者の悩みがあまりにも身に染みる話でやたらと親近感わきました。
どこいっても大差ない気がしてなりません。だからこそ、LifeHack系の日々を楽しくして行く方法に目が向いているというのもあります。技術は利用目的に合わせて身につけていくし、そのための勉強は当然ですから、「やって覚えればいいだろ」ぐらいに考えてます。
どちらかというと、ノウハウやアイディア出し惜しみしない土壌を作っていきたいですね。このアイディアを出したら誰かに先を越されるかも・・・！と思うよりは、作ったのは誰であれ自分の考えが世に出た事にもなったぐらいに考えて行きたいですね。
またモチベーションがあがった1日でした。
iPhoneの話をとめどなく広げてみる
「iPhone 日本 売れない」とググると、このところのソフトバンクiPhone発売決定に合わせて、それぞれの思うところが書かれているようです。私もつらつらと書いてみようと思った次第です。多分、脱線しますけど。簡単に要約すると
- 日本で必須のサービス(着うた、モバゲーなど)が使えない
- 月額の通信料がばかにならない(最大15MBで9,800円が現状)
この２点につきるようです。日本は世界的に見ても、独自の携帯文化を持っているのは間違いありません。もはや携帯電話は「家電製品」で持っているのが当たり前になっています。こんなことは今更いうまでもないことです。
ですが、上記２点をのぞいてデバイスとしてのiPhoneはおおむね好評のようです。といっても、フル機能を使える人、その恩恵にあずかる人は利用しているPCに１つでもMacがあり、そしてMacがメイン端末の人だけだと思います。
PDAへの現代的解答とでもいいましょうか。結局は「通話機能つき手乗りPC」が欲しいのだと思います。電話もしたいし、ブラウザも使いたいし、ドキュメントも読みたいしと。日本人はオールインワンが好きと考えてますが、「人間はオールインワンが好き」でいいのかもしれません。
結局、PCを日常的に使う人にとって、その生活はもはやPCに依存しているといって過言ではありません。それを場所を選ばず使えるようにしておきたいという願いに対して、ノートPCを持って歩くにはかさばる、通信環境が保証できないとなると、現代的にもっとも満足度の高い解法は携帯電話に採用されている環境であったのは自明の理だったのでしょう。
ソフトウェアとハードとユーザの追いかけっこ
思ったのは、ソフトウェアの進化と環境の開きが大きくなっていることです。これはいいことですし、当然です。ソフトウェアの発想は人間の脳の中で行われるのですから、可能性はその時点で無限です。
これに対し、ハードウェアつまりデバイスの進化はそれに遅れます。しかし、これも割と時の流れで解決していっていると思います。日本の通信環境はPCにとってかなり遅れていますが、携帯電話が山奥でもつながる時代ですから、その時点で解消される問題は多いと思います。
実際、PCスペックが高くなったからこそできた技術(例えばAjaxなどクライアントサイドで負荷を担う事が重要なもの)が現代を賑わせているのがいい証拠でしょう。
タイトルで私がいっている環境とは、人の環境です。iPhoneはおそらく、必要にかられて使う人というよりは、流行を追う人のシンボルとしての側面によるところが大きいと思います。それもいいと思います。
ですが、そこは表面的なものにしかすぎません。求めているのは、どうやったら人間が使いたくなるのか、使って便利だと思うのかということです。それに結論を出すために、人間の行動の中から普遍的なものを抜粋し、現在の生活に適したものとして具現化するという工程を繰り返しています。
人間が生み出した技術は人間のためにあるというのが特に最近、個人的に思うところです。Inflame Casting #123でもWEBという媒体を中心にして同じようなテーマを話していて、個人的にはこの回がお気に入りです。
人間の情報処理は3次元という仮説？
ごく小さな範囲の話をあえてしますが、私の祖母は韓国ドラマをずっと見続けています。その中で、ビデオテープではなくDVDで閲覧するとなると、DVDプレーヤーの操作方法を覚えなければいけないわけです。そこで、祖母が使い始める前からあった多機能プレーヤーは非常にインターフェースが複雑で、やっぱりビデオでいいと最初はいっていました。そのビデオデッキは以前からあるもので、再生と録画の必要最低限の機能しかないものです。
そこで、再生専用DVDプレーヤーを安く購入し、ビデオデッキとほぼ似た感覚で最小限の手順で操作できるようになると、このDVDプレーヤーはいいものだと絶賛した訳です。現代の流行は複合機に向かっているのにも関わらずです。加えて、市場の価値はかなり低いものにも関わらずです。
ああ、技術ってそういうことだなと私の中ではすべてつながってしまったし、自分が突き詰めて行くものが何なのかが見えました。大事なのはコンテンツ・制約(要求)・インターフェースなのでしょう。
ですが、これだと足りません。当たり前すぎるのです。今、情報の次元というものを考える機会が多く、およその情報は3次元で表す事ができると勝手に思っています。これは、人間が扱う情報はという前置きがつきます。いわく、人間の情報処理能力は、というか脳は３次元までしかわからないそうです。今度ちゃんと調べてみますが。
情報処理を4次元にこだわって考えてみる
Inflame Casting#123では、高齢者向けWEBサービスの可能性について少し触れています。私の祖母についていえば、
- コンテンツ=韓国ドラマ
- 制約=DVDでしか見れない
- インターフェース=再生、停止、一時停止、早送り、巻き戻し
確かに3次元だと思います。が、ここにもうひとつあって、そもそも韓国ドラマは、私の母の勧めで見るようになったのです。先に母が韓国ドラマにはまり、祖母にも勧めて・・・という経緯があったのです。これが新たな次元と仮定します。人が使いたいと思い、使って便利と思うまでの過程に4次元の情報があったと仮定するのです。
何と言うラベルを付ければいいのか分かりませんが、特定の信頼関係はブランドになるようです。facebookはこのブランドをサービスとして取り入れており興味深いです。Amazonなどの、この商品を買った人はこんなものも買っていますの先にというか、別ベクトルなのかわかりませんが、同じ根元です。
ああ、とりとめがなくなってきました。つらつらし過ぎです。バブルマップアプリのテーマも4次元です。というか今後のデザインや開発も当分は4次元がテーマです。実証されるのか、不発に終わるかは分かりません。
自分にとってのブログは発信じゃなくて、文章化による思考の整理と発展のようです。内容が変わってきたので、別エントリでまた触れたいと思います。
アバウトミーを構成する4要素を考えてみる
niftyによりアバウトミーというサービスが公開されています。登録ユーザがアンケートに答えていくことで、他の人がどういう傾向があるか、自分がどういう傾向があるかに気づくという内容ですが、おもしろいのはユーザ自身もアンケートを作成できて、他のユーザが答えてくれたり、コメントがついたりという点です。「今どき」のWEBサービスではありますが、これも「うまいなー」と思わせる要素があります。
サービスを構成する要素を考えてみる
まず、WEBに限らず世にあるサービス(ゲームやギャンブルも含む)を構成する要素はなんだろう？とプロジェクトメンバで話していた時に、以下の4つがあるだろうという話になりました。主に娯楽サービスが根拠となっています。
- ランダム
- 毎回、問題や結果が変わる。次を予測しにくい。
- 蓄積
- アクションの結果をカテゴライズしながら蓄積していける。後から蓄積結果を参照できる。
- 単位時間
- メインのサービスを一通り利用するために要する時間。
- 即時性
- 自分が起こしたアクションに対してすぐに結果が反映される。
この4つで構成されて、かつバランスが現代の時流や生活に合っているものが成功しやすいと考えました。中でも、単位時間と即時性の関係が大事だと思われます。
アバウトミーに照らし合わせてみる
では、実際にそれぞれの要素についてアバウトミーではどうなっているかを見てみます。
- ランダム
- 毎回アンケート(質問)が変わる。ただし、「人気の質問」といった簡単な制限を加えられる。
- 蓄積
- これまでに答えた質問、作った質問の履歴を参照可能。また、回答数と作成数のランキングもある。蓄積された情報すべてについて、性別・年代で絞り込みを行うことが可能。
- 単位時間
- 複数の選択肢から1つを選ぶのみなので数秒。問題作成についても、選択肢にテキストをどんどん入力するだけで作れるという簡単さ。いつでも止められるが、中毒性も高く、延々と答え続けられる。
- 即時性
- 自分がアンケートを作成した直後から、すでに回答がある場合もある。(アンケート数の増加によってこの速度は落ちていくと思われる)
4つの要素を満たすのは最低条件
では4つの要素を満たせば、すべてのサービスは成功するのか？といえばそうではないと思います。少なくとも、ここまで来てスタートラインでしょう。次に考えるのは「サービスのローカライズ」です。
少なくとも、日本人向けのサービスであれば「匿名性」「帰属意識」という要素が必須となると思います。根拠を話せば長くなりますが、実例は枚挙にいとまがありません。(匿名掲示板、SNS・・・etc)
ですが、これを考えてもまだブレークスルーとなるサービスにたどりつけるかどうかは別問題です。ここからは、やはり人間行動を分析して分析して・・・という積み重ねによって生まれた視点が決め手となると思います。
少なくとも、アバウトミーの場合は日本人の帰属意識という本質をうまくついていると思います。また、アンケート作成後にすぐレスポンスがあるという即時性は落ちていくと述べましたが、アンケートの多様化によってカバーされていくと思います。「企業からのアンケート」「アンケート作成者のアイドル化」「特定分野アンケートの増加」・・・ひらたく言えば、ニコニコ動画と同じ道でしょう。そこでどういった想定外の効果が生まれるか楽しみでもあります。
ここ最近は、技術的な話から普遍的真理や人間の行動を分析する機会が多くなってきました。だから、新しい人と会うのが、人と話すのが楽しいのかもしれません。というわけで宣伝ではありませんが、話を変えます。
IWDDミーティング #23に参加します。かつ第3部のプレゼンテータまでやることになりました。テーマはオープンUI設計をしてみるです。先日のバブルマップアプリについて、基本的な構想はできてきました。ここらで、その内容を共有して参加者でUI設計してしまおうかなと目論んでいます。
発表ネタになって、かつ様々な人のフィードバックをその場で受けれてと一石二鳥かなと。今から楽しみです。
Rails 2.1のnamed_scopeが良すぎる件
いつの間にかRuby on Rails 2.1がリリースされていました。
これは試さねばと、gem update rails -yと実行するとrails 2.1.0がお目見え。とりあえず、他のリリースノートを見ていくと、named_scopeという新機能。・・・こ、これは！
さようならbuild_condition
私の場合、これまでは検索条件は各コントローラでbuild_conditionというメソッドを用意し、そこで管理するという実装ポリシーでした。例えばこんな感じ。
def build_condition
conditions = Array.new
if (params['price'] && params['price'] != '')
conditions << "products.price < '#{params['price']}'"
end
conditions.join(' and ')
end
まぁ、複数条件を指定したい場合や、修正箇所を1か所にできるなどを考えて、美しくないと思いながらもこのような実装をしていました。このコードは例えば任意の価格未満の商品を探すといったものです。
しかし、実際は10,000円未満の商品は？といった探し方、つまり価格帯で探すのが、世のオンラインショッピングにおけるUIパターンの基本です。
10,000円未満の商品が欲しい
この要望をnamed_scopeによって実現します。まずは、model/product.rb
named_scope :below_10000, :conditions => ["products.price < 10000"]
#controllers/products_controller.rbでの呼び出し
@products = Product.below_10000
商品名でキーワード検索したい
named_scope :by_keyword, lambda {|*args|
{:conditions => ["products.name like ?", '%' + args.first + '%']}}
#controllers/products_controller.rbでの呼び出し
@products = Product.by_keyword("Rails")
デフォルトの並びは商品の新着順にしておきたい
named_scope :order_default, :order => "products.created_at desc"
#controllers/products_controller.rbでの呼び出し
@products = Product.order_default
10,000円未満の商品を新着順に並べたい
@products = Product.below_10000.order_default
す、スマートすぎる・・・MVCアーキテクチャにおいて、知りあい関係をどう分担するかが肝となりますが、RailsにおけるModelはO/RマッピングにおけるEntityつまりDB上の1テーブルに対する実態とDAOの基本機能という存在でした。
結局のところ、検索・登録・更新・削除といった基本メソッドをもったところで、サービスの中心である「検索条件」という点についてはコントローラ側の役割と私は解釈していました。
しかし、これでControllerの役割であるユーザ入力からModelへのデータ引き渡しという本来の姿により近くなることができました。Modelの役割が増えたと考えるか、DAOとしての機能がModelに収まるので分業化が楽と考えるかはMVCアーキテクチャに対する解釈によりけりでしょうね。
ただ、実装側からすれば、より直観的な方法で実装できる分、嬉しいですね。
#2008/06/06 追記
orderに関する記述とconditionsに関する記述の順番が入れ替わっても平気だった
@products = Product.order_default.below_10000
ここはLinqより頭いいです。素晴らしい。
#2008/06/08 追記
:includeと:conditionsが併用できました。申し分ありません。
named_scope :by_genre, lambda {|*args|
{:include => [:genres], :conditions => ["genres.uri = ?", args.first]}}
ほぼ完全にSQLをcontrollerに記述しなくてよいです。modelはDAOとvalidationがメインということで大分すっきりしました。