2007年3月アーカイブ

私は私の意見を述べる。
それがよい意見だからではなく、私自身の意見だからだ
by　モンテーニュ

柔道の基本は受身
受身とはころぶ練習　まける練習
人の前でぶざまに恥をさらす稽古
受身が身につけば達人
まけることの尊さがわかるから
by　相田みつを

転んだ人を笑ってはいけない。彼は歩こうとしたのだ。
by　？？？（だれ？ｗ）

金がないから何もできないという人間は、
金があってもなにも出来ない人間である。
by　小林一茶

どんな馬鹿げた考えでも、行動を起こさないと世界は変わらない。
by　マイケル・ムーア

鶏口となるも、牛後となるなかれ
by　蘇秦

人はいつ死ぬと思う？
心臓をピストルで打ち抜かれた時。違う。
不治の病に冒された時。違う。
猛毒キノコスープを飲んだ時。違う。
人に・・・忘れられた時さ。
by　Dr.ヒルルク（ONE PIECE）

友人の果たすべき役割は、間違っているときにも味方すること。
正しいときにはだれだって味方になってくれる。
by　マーク・トウェーン

のび太くんを選んだ君の判断は正しかったと思うよ｡
あの青年は人の幸せを願い､
人の不幸を悲しむことのできる人だ｡
それが人間にとって大事なことなんだからね。
彼なら、まちがいなく君を幸せにしてくれると、僕は信じているよ｡
by　しずかちゃんのパパ（ドラえもん）

最も難しい三つのことは、
秘密を守ること、
他人から受けた危害を忘れること、
暇な時間を利用すること。
by　M.キケロ

名言集が完成されることはない。
by　ハミルトン

今日読んだマッシュアップに関する記事についてた見出しです。

『マッシュアップはUIの再定義でもある』

このたった１行の見出しに、なんだかすごく納得しちゃったよね・・・

ノンプログラマーなりのマッシュアップ

【マッシュアップはUIの再定義でもある】

出張JAWS（ジョーズ）
マッシュアップの王道ともいえる作品で、アイデア自体に新味はないが、Ajaxを使ったUIが非常に使いやすい。マッシュアップとは、ごちゃごちゃしていて視認性の悪いページや、遷移状態が分かりづらく使い勝手が悪いページ、そういったネット上のあちこちに散在しているサービスを、見やすく使いやすいUI でラップして提示することでもあるのかもしれないと思わせる。

引用元：いま見ておくべきマッシュアップの最先端事例

最近は多少のPHPを触るとは言え「システム」「デザイン」という分け方をするならば、俺は本来はデザイン側の人間。
そのためか、どうしても奇抜なことや新しいことをするためには、自分に足りないもの＝自動化や動的処理をしてくれるプログラミングのスキルが必要で、そのスキルがある前提でそれにアイディアを加えて、機能的に凝ったもの・工夫したものがマッシュアップだ、というある種の先入観に捕らわれていた気がする。
何ていうか、マッシュアップはプログラマーがやること！みたいな認識だったよね。

どうなんだろ？実際のところ、一般的に言われる「マッシュアップ」ってやっぱり機能重視？
それとも俺の視野が狭かっただけ？

少なくとも俺はこの記事のおかげで、今まで自分が考えていたものとは違った形のアプローチにも気づかされた感じ。

本来のサービスよりも、ユーザビリティ的に優れたものにしたり、もしくは、その国々に合わせてのローカライズ版UIを検討するっていうのは、本家サービスと機能的に大きな差異がなくとも、使うユーザーにとっては価値のあることだったりするんだな、っていう。

それってのは、本来デザイナーが力を発揮する分野なはずだよね？　いやさぁ、デザイナーのくせに「一に機能！二に機能！」と考えていた自分がちょっと恥ずかしいなぁーとか思ったりしたわけだよね。　灯台下暗しって言葉もあるし、しょうがないことなんだろうか？ｗ

ちなみに、もちろんいくらUIを素晴らしいものに再構築できるからと言って、デザインスキルだけでマッシュアップサイトを作ったりするのは正直辛い。最低限WebAPIなりを扱える程度のプログラミングはできないと色々と限界があるだろうし、そもそも例に挙がってる出張JAWSでもAjaxやWebAPIをバンバン使っている。
だからプログラミングが必須なことには変わりはない。

この気づきを使うべきところは、アイディアを出す段階なのかな？
デザイン面からのアプローチも全然イケるってのに気づいてるか気づいていないかの違いって、実は結構大きい気がするなぁ。今みたいに、WebAPIが充実してるネット世界では、機能だけの差じゃ、差にならない事も少なくないだろうしね。

思い返してみれば、自分が今までやったこともそうだったりする。
どうしても先にPHPで機能を組んで、それからCSSなりを定義してた感じだった。
逆だってアリなのにね。

視野を広げるってのは、思ってるよりも難しいらしい。
そもそも自分の視野が狭いということに気づけてないんだから。

PHPSPOT開発日誌さんで紹介されてたので、活用法を考えてみますた。
JavaScriptで簡単に独自の右クリックメニューを作成するライブラリ「RightContext」

ユーザーとUIが仲良しなサイトへの導入が吉？

一般のWEBサイトよりもSNSとの相性が良さそうだなぁ～ってのが、このライブラリを見ての最初の感想かな。

テクノラティなんかで「RightContext」を検索してみてるとチョイチョイみつけれらると思うけど、
「右クリックを変えてしまうっていうのはユーザビリティ的にすごく危険なんじゃないか」
なんていう指摘も見られた。うん、たしかにそうかも。普段使いなれたブラウザ自体の挙動を制限しちゃうんだから不便に感じないはずがない。

んでも、逆に考えるんだ。「使う」か「使われる」かってのは、コレに限らず何にでもそうだと思うんだ。ってことで、たしかに考えるところは多いんだろうけど、何ともならないわけじゃないと思ったり。

そうこうして考えてみると、どうしても相性がいいのは訪問ユーザーの平均閲覧ページ数が多いWEBサイトになるんじゃないかと。つまりは、訪問ユーザーが2,3ページ見て帰るサイトよりも、訪問ユーザーが20ページも30ページも見てから帰るようなサイトに向いていると。

基本的にSNSのユーザーって、そのサイトに何度も何度もアクセスするし、訪問したらしたでちゃんとSNSを使ってるユーザーであれば、足跡ページを見て、フレンドの最新日記を見て、過去にコメントをつけた日記を見て、自分の日記についたコメントを見て・・・・・・という具合に、ページ上をあっちへこっちへと移動しまくる。

つまりは、そういう風にユーザーがそのWEBページを使い込んで、提供しているUIとどんどん仲良くなってくれる。だからこそ、こういうちょっと特殊なUIをもたらすライブラリとは相性がいいんじゃないかと。
たぶんアレだよ、右クリで独自メニューに慣れちゃったら、逆に無いと不便に感じるくらいじゃないかなー？とか。

そんなわけで、習うより慣れろの精神？で、具体的な活用法を考えてみたりする。

SNSにRightContextを活かす妄想

とりあえずうちでもOpenPNEでSNSを運営してるので、やるとしたらどんな感じのカスタムをするか考えてみる。

まず、通常はユーザーのプロフィールページにリンクされている「ユーザー名」にコンテキストメニューを割り当てる。右クリック時に展開されるメニューは以下のようなもの。

　・プロフィールを見る
　・最新日記を読む
　・メッセージ送信
　・お気に入りに追加
　・マイフレンド申請
　・マイフレンドに紹介
　・最新レビューを見る
　・この人のフレンドを見る
　・紹介文を書く

通常はユーザーごとのページに一度飛んでから行わないといけない挙動を飛ばずにやれちゃう感じ。
これらの動作であれば、メンバーIDさえ取得していれば行える。元々メンバーIDはアンカータグで使っているわけだから、新たにSQL等が必要になったりもしないと思われ。よって負荷なく拡張可能。

同様に「コミュニティ名」にも割り当て。こちらもコミュニティIDだけ持っていればリンクは生成できるので負荷はナシ。

　・コミュニティのホームへ
　・トピック一覧を見る
　・メンバーズレビューを見る
　・コミュニティに参加する
　・コミュをフレに紹介する
　・コミュをやめる

こうして、間接的にメニューを増やしてあげることで、「ユーザーホーム」や「コミュニティホーム」を経由する必要がなくなるために、無駄に開かれるページは減り、結果的にサーバへの負荷軽減に繋がるんじゃなかろうか？
小規模SNSだとそんな小さな負荷云々まで考えずに一般なやり方でかまわないんだろうけど、大規模になればなるほど、そういった小さな負荷が積もり積もって大きな負荷に化ける気がする。

なんなら、設計次第では上にずらっと並んでるメニューだって必要最小限にできるかもしれない。そうなればUIをガラっと変えられる。
ユーザーが思っていた動作ができないくてストレスを感じないように、どこかしらかにこの機能のオンオフ設定があってもいいのかもしれない。
ということで、どうせ使うなら使い倒したい感じですね。

「SNSのUIはmixi型（OpenPNE型）が最高ではない！」と思ってる開発者の方とかは、まぁひとつの参考としてどうぞ。

平たく言うと、「オススメPingサーバ一覧」な記事ですね。
ブログが流行してしばらく経つし、実はGoogle先生に聞くとかなりの数のページがひっかかるから、わざわざうちでまとめることもないんだけども、まぁ、オススメというか・・・少なくとも俺がこのブログで設定してるPing送信先を晒してみようかな、っていうだけですね。

Pingを設定するメリット・デメリット

Ｐｉｎｇを設定するメリットってなにかというと、設定しとくとことでブログを更新したときに「更新したよ」って通知みたいなもんが自動的に各所に飛んでくわけですよ。
たくさん設定するメリットは、『被リンクが増える』ことと、『自分のブログへの入り口が増える』ことかなぁ？前者はSEO的なうまみ。後者は単純にアクセスアップに繋がる（カモ）。せっせとブログ書いても書かれたこと自体に気づいてもらえないんじゃしょうがないからね。そういう意味じゃ必須なのかも。

逆にデメリットは、大抵の場合、記事の再構築時の負荷が増えことかな。少なくともMovableTypeでは遅くなるよね、いちいち送ってるので、時間かかったりする。だから送信先を増やしすぎるとブログ本体を設置してるサーバの性能によっては、再構築に失敗したりってのも考えられますな（まぁほとんどないとは思うけど）。せっかちな人には間違いなくオススメできんねｗｗｗｗ

そんなわけで、本当は自分でどこに送るかを選んで使うのがいいんでしょうねぇ～。
うちのはこれじゃ多いくらいかもしれないけど、まぁ別にハイスピードな再構築は望んでないので被リンクの恩恵を重視かな。

Ping送ってもエラー等が跳ね返ってくる可能性もあるね。とりあえずこのリスト使うにしても、ご利用は計画的かつ自己責任でどぞん（　＾ω＾）

ブログ用Ｐｉｎｇ送信先

http://api.my.yahoo.co.jp/RPC2

http://blogsearch.google.com/ping/RPC2

http://blogstyle.jp/xmlrpc/

http://blog.goo.ne.jp/XMLRPC

http://bulkfeeds.net/rpc

http://coreblog.org/ping/

http://ping.blo.gs/

http://ping.bloggers.jp/rpc/

http://ping.blogmura.jp/rpc/

http://ping.blogoon.net/

http://ping.cocolog-nifty.com/xmlrpc

http://ping.gpost.info/xmlrpc

http://ping.myblog.jp/

http://ping.rss.drecom.jp

http://rpc.blogrolling.com/pinger/

http://rpc.pingomatic.com/

http://rpc.technorati.jp/rpc/ping

http://rpc.weblogs.com/RPC2

http://www.blogoole.com/ping/

http://www.blogoon.net/ping/

http://www.blogpeople.net/servlet/weblogUpdates

ちなみに、どうでもいいですけど、「ピング」って読み方を良く聞きまが、一応これはGは発音されず「ピン」が正しいようです。