メソッドとfunctionの違い

　メソッドとfunctionってどう違うんだろう。両方とも日本語では「関数」。（ここでいうメソッドは高橋メソッドとかじゃなくて関数のことね。）
　初めてfunctionを知ったのはOracleのDeveloper2000だった。functionは戻り値があってprocedureは戻り値がない～ということで覚えた。でもprocedureでも引数使って戻り値返せるから実際はあんまり区別ないんだよね～と先輩に言われたけどそれは関係ない。絶滅してしまったprocedure。
　初めてメソッドを知ったのはいつだろう。覚えてない。いつの間にか関数＝メソッドになっていた。functionも関数だからメソッド＝関数＝function。イコールだ。
　でも改めて調べてみるとメソッドは「メンバ関数」のことで、「オブジェクト指向プログラミング言語において、あるクラスに所属するサブルーチンを指す」らしい。

メソッド (計算機科学) - Wikipedia

　へえ。初めて知った。そしてすぐに忘れそう。

現在のWebサイトに求められるUIとは？

　知り合いが最近、ブログに動画を貼るようになった。内容は海外のソフトの使い方の説明で、たしかに動画で見られると分かりやすい。
　ところで、彼が動画を貼るために使っている動画共有サイトは、YouTubeやAmebaVisionのような有名どころではなく、初めて見るような動画共有サイトだった。なぜそれを選んだのか訊くと、「再生画面が大きくて、画質もまあまあだから」とのこと。画質を重視するならなんでStage6とかにしないのかと聞くと、ブラウザだけで見られないのは（彼のブログでは）話にならないとのこと。このことから現在のWebサイトに求められるUIについて考えてみた。

メディアコンテンツの表示はもっと大きくていい
　現在動画の表示サイズは400×300程度、もっと小さいところもたくさんある。もちろん最大化機能が付いていることが多いが、一般ユーザーは最大化機能を使うことは少ない。
　現在使われているPCの表示サイズは半数弱が1024×768、約半数がそれ以上の多きさだ。サイトによってはそれより小さいサイズ（主に800×600）にも対応しなければいけない場合もあるが、動画や写真などのメディアコンテンツを扱うサイトでは小さいサイズを切り捨てることによるメリットの方が大きい。
　Webブラウザで見る以上、ツールバー・ステータスバーにより縦のサイズがかなり制限されるが、それでも思い切って600×450くらいでいいのではないだろうか。大きなメディアコンテンツの魅力は、DailymotionやFlickrを見れば一目瞭然だろう。
　ただし、同等の画質を維持したままサイズを大きくすると、必然的にメディアファイルのファイルサイズは大きくなり、ネットワーク負荷は高まり、レスポンス速度は遅くなる。このトレードオフについては慎重な検討が必要である。
　また、Gyaoの「CMだけ大きくて本編は小さい」は視聴者にガッカリー効果をもたらすのでやめた方がいい。

ユーザーは画/音質に寛容である
　サービス提供者やハードウェア/ソフトウェア制作者が執拗に画質・音質に拘るのに対して一般のユーザーはそれほど画質・音質に拘っていない。もちろん良いにこしたことはないが、画質・音質のみでキャズムを越える例は殆どない。有名な失敗例を挙げると、

• SACD（スーパーオーディオCD）、DVD-Audio
  　CDを上回る音質と喧伝されたがその価値が理解されずに全く普及しなった。CD以下の音質であるMP3が爆発的に普及したのとは対照的。
• ハイビジョン（HDTV）
  　一度見たらもう元の画質には戻れないはずのハイビジョンも、いまだに普及したとは言い難い。液晶TVは高くても売れるが、ハイビジョンは「あったらいいな」といったおまけ扱いである。
• PS3
  　（失敗というほど失敗ではないと思うけど。）
  

　もう一度書くが、画質・音質が良いにこしたことはない。他の条件が同じならば。ただし大抵の場合は利便性や価格などのデメリットを伴う。提供者側はそれを補うだけの画/音質だと自負するが、ユーザーが求めているのは少なくとも自負ではないのである。
　YouTubeが日本で紹介し始めた時、その画質の荒さにビックリしたが、それでも爆発的に普及したことにまたビックリした。ユーザーはそれでもいいかなと思うものである。

当たり前になった利便性
　冒頭で挙げた動画共有サイトはマイナーなサイトだが、それでも以下のような機能を持っていた。

• 追加でソフトをインストールしなくても視聴できる
• 動画ファイルのダウンロードと並行して再生を開始する（プログレッシブダウンロード）
• スクリプトのコピー＆ペーストで、自分のブログに動画再生プレイヤーを表示できる

　これらのことは動画共有サイトとしては当たり前の機能である。しかし考えてみて欲しい。ほんの数年前まで我々は、Windows/IEでしか見れない動画やQuickTimeが必要な動画を見ていたのである。動画ファイルのダウンロードが完了するまで、再生できずに辛抱強く待っていたのである。ブログはおろか、企業のWebサイトでも動画を掲載するにはハードルが高かったのである。
　もはや「Webだから」という言い訳は通用しない。Webでも追求できる利便性があることを、ユーザーは知っている。
　ついでに言及しておくと、上記の機能は冒頭の彼が動画共有サイトを選択するさいの条件として挙がらなかった。実際にはこれらの機能が無いために選択肢から外した動画共有サイトがあるにも関わらず、である。なぜだろうか？それは、往々にしてユーザーは自分の欲しい機能を意識的に表現できないためである。
　ユーザーが言うとおりにデザインしてはいけない。その向こうにある要求を掘り出すことが必要だ。特に声の大きなユーザーには気を付けよう。むしろ、自分の考えに固執してそれとともに沈んだ方がいい。そこから何かを学び、説得力と将来的なチームへの貢献力を得られるのなら。

　つらつらと書いてみたら愚痴っぽくなりそうなのでここでやめる。ちなみに冒頭の彼はペルソナです。

「全方位かピンポイントか：成功と失敗に学ぶベンチャー創業6つの教訓」を読んで

全方位かピンポイントか：成功と失敗に学ぶベンチャー創業6つの教訓 - CNET Japan

1．分割して統治せよ、差別化か死か
　「MySpaceのような巨大なサイトは、今後は決して現れない」ってことは無いと思う。
　「細分化と、その後の専門化が必要」ってのは賛成。モバゲーもMySpaceも初めは狭い分野をターゲットにしていた。成功すれば大きくなれる（可能性がある）。

5．バカみたいな単純さ
　「他のすべての条件が同じなら、最も単純なものが最良のソリューションであることが多い」。素晴らしい。でもそれが難しいんだけど。使いやすくするために親切のつもりでいろいろ付けると気が付いたらもうゴチャゴチャになってたり。
　例えばEメールはシンプルな仕様だが、使う人によっては恐ろしく便利なツールだ。メモ帳、目覚まし時計、会議、データベース、etc。単純さゆえにユーザーが使い道を生み出してしまうと言うのが幸せな形なのだろう。

仕様をWebアプリ内に書き込めば分かりやすいかも

　この記事を読んで思った。

「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法：ITpro

　以前やった開発で、HTMLのモックアップをユーザーに見せながら決まった仕様をそのHTMLの下に書いていくというのをやったことがある。そこからさらに一歩進んでこんなのやってみたい。

• Webアプリを作りながら、各ページの下部に仕様メモを入力/表示する欄を作る


• 入力/表示欄はフレームワークで制御して開発中しか表示しない


• 仕様メモはTracのチケットと連動させる


• Flockみたいに画面内に付箋っぽいのを付けて説明するとさらに良い。（JavaScriptで制御？）

Tracでの管理と二重管理になっちゃうかな。でもユーザーには直感的で分かりやすそう。

「タグ」を使ってる人なんてほとんどいないのかも知れない

　タグクラウドも見慣れた昨今、タグなんてある程度の人が使いこなしていると思ってた。でもこれを見てびっくり。

ITmedia News：「タグ付け」経験者は28％――米調査

　アメリカですらこれなら、日本では10%とか3%とかそんなものかも。携帯がメインの人なんかタグなんて煩わしいもの使わなそうだし。
　記事をよく読むとタグと知らずにタグを使っている人が含まれていないのではと言う推察。Googleでの呼び名はラベルとタグが混在してるしね。