mixiアプリ/日記12
国内のソーシャルアプリプラットフォームの進む道
日本国内向けのソーシャルアプリのプラットフォームにはmixiアプリに続いてモバゲーのDeNA、そしてGREEが参入の発表を行いました。モバゲーだってGREEだって元々「ゲーム」というコンテンツを持っていたわけですが、そこからアプリのプラットフォームをさらに公開するという流れには自社内や旧来のサードパーティから何らかの抵抗があったんじゃないかと思います。それでも、ソーシャルアプリに踏み切る決断をしたというのは、単にFacebookの躍進を目の当たりにしてしまったからなんでしょうか。だとしたら、必ずどこかで「日本語」がネックになってくる段階があるんじゃないかと、今、ふと思いました。日本語を使える人で、PCを定期的に使う人が国内のSNSのターゲットだと思うのですが、Facebookのターゲットはもっと広そうですよね。
ターゲットは絞った方が質のよいサービスが展開できます。そして、日本人は質のよいサービスに慣れているので自分の好みから外れるものには見向きもしなくなりそうです。そんな前提条件を並べてみると国内のSNSを足がかりに海外展開するのは、途中で道に迷いそうな予感がします。どういう戦略を持っているのか結構気になりますね。
ソーシャルアプリのデベロッパーが増えているというのは、いろんなメディアや評判を通して耳によく入ってきます。先日も友人の知人がソーシャルアプリの作り手を探しているなんて話を聞きました。きっと潜在的なデベロッパーをいっぱいいるんでしょうね。ソーシャルアプリを専門に開発する会社の求人なんかもよくみかけるようになりました。そして、ソーシャルアプリデベロッパー向けのファンドや広告代理店というのも出てきました。多分、まだ試行錯誤の繰り返しだと思いますが、アプリのマネタイズをバックアップしてくれるサービスというのは心強いですね。さらには、ノウハウの蓄積が一程度に達したら、一つのアプリを複数のプラットフォームに同時展開してくれるサービスまで始まりました。mixiアプリを作ったら、GREEやFacebookのユーザにも同時に提供されるってことでしょうか。確かに技術的にはそんなこともできそうですね。でも、mixiやモバゲーのユーザ層って乖離はないんでしょうか？多分、「mixiでは難易度は下げよう」とか「mixiではゲームの雰囲気を落ち着いた感じにしよう」とか、現状ではプラットフォーム別に細かな設定に変化をつける必要があると思います。そういった差別化についてもプラットフォームごとに提言してくれるんでしょうか。
mixiであることの意味って？
自分がmixiアプリの開発を始めたのは、mixiが最初に始めたというのももちろんありますが、やはり自分や自分の知り合いが普段使っているサイトだった点が大きいです。少なくとも知り合いに見せられるというのは開発のモチベーションとしては十分でした。そして、mixiの持っているサイト内の雰囲気というのも何となく理解しているので、PCの向こうにいるユーザのことを何となく想像できるというのが開発を楽にしてくれました。最近、Facebookのアカウントをもらったのですが、少し触っただけではFacebook向けのアプリのアイディアがちっとも頭に浮かびませんでした。アメリカ人に対して持っているイメージばかりが先行して変なアプリは少し考えたのですが、アメリカ人の利用者が必ずしも一番多いわけでもないですしね。
mixiには、PCの操作に不慣れな人もたくさんいて、そんな人たちのことも考えながらアプリを作る必要がありそうです。誰でも違和感なく操作できるというのはソフトウェアのUIとしては秀逸ですので、同じ機能でも何度か作り直したりもしました。mixiじゃなければこんな苦労もなかったといえるかもしれません。それでもやっぱりmixiでアプリを作っているのには、きっと何か理由があるんですよ、多分。
少し考えてみたところ、mixiの運営方針がソーシャルグラフをすごい大事にしていると度々気付かされたことを思い出しました。マイミクのつながりとコミュニティのつながりは大事だけど、名も知らない人とのアプリを通してだけのつながりは、mixi的に多分そんなに大事じゃないというニュアンスが多分に伝わってきます。個人間の距離感を大事にしているというイメージなんです。うまく説明できませんが、誰でもマイミクになれるというのはソーシャルグラフの形成という観点からは不健全なんです。憶測ですけど。最近追加された「同級生」というつながりはまだ様子見段階かもしれませんが、多分mixi的には「あり」で、今後も機能が充実していくんじゃないかと予想します。今日、初めて同級生機能経由で旧友とマイミクになったのですが、結構「あり」ですよ、この感じ。社会人になってしばらくすると旧友との交流を復活させる余裕も生まれるかもしれませんね。マイミク追加時に「過去の日記を読ませない」という項目があるあたりでも、mixiはそういうところを大事にしているという好印象を抱きました。
自分はmixiの雰囲気が結構気に入ってるんでしょうね。それでmixiアプリもコツコツ続けられているんだと思います。知らない人との交流も楽しいかもしれませんが、距離感を適切に設定してあげられるよう心がけたいです。
アプリにFlashを表示する
さて、mixiアプリのほとんどが限られたスペースをFlashコンテンツで埋めていることは、ユーザならご存知のことと思います。opensocialではリッチコンテンツの埋め込み用のAPIも提供されているので、それを使えば簡単にFlashを埋め込むことが可能です。
まずは、アプリを定義するxmlファイルのModulePrefsタグの中に以下のような指定を追加しておきます。flashを呼び出すモジュールを読み込ませる指定ですね。
<ModulePrefs>
<Require feature="flash" />
</ModulePrefs>
あとは、Flashを呼び出したいタイミングでgadgets.flash.embedFlashを呼び出すだけです。デベロッパーセンターのサンプルを少し改変して引数を説明します。
gadgets.flash.embedFlash("http://your.server.host/flash/content.swf",document.getElementById("target"),6,{width:690,height:600});
最初の引数には、表示するFlashのSWFファイルのURLを指定します。
第二引数はアプリのDOM上でFlashを表示させたい場所を指定します。サンプルでは「
」みたいな要素がアプリ内に存在することを前提にidが"target"な要素の中にFlashを配置します。第三引数は表示するFlashが必要とするFlashPlayerのバージョンの数値です。私が一番最初に作ったアプリは、Flash内で自作のフィルタを使用するものだったので、最低バージョンを「10」に指定したのですが、どうも10を指定するとこのメソッドの動作がおかしくなるようなのです。とりあえず、その場は「9」と書いて、説明書きに「FlashPlayer10が必要です」と書いておいたら、無事に審査も通過したのですが、メソッド内のバージョンチェック機構が無意味になってしまうので、どうにかならないものでしょうか？ちなみにこの問題が解決したかどうか確認できていないのですが、まさか16進法で「"a"」と指定するべきなんてことはないですよね。今度10.1が正式に登場した場合は小数点つきで指定してもいいのでしょうか？
第四引数にはFlashのコンテナとなる要素にプロパティを指定できます。サンプルではFlashの幅と高さを指定していますが、その他にも「allowScriptAccess」や「id」なんかも指定したくなるときもあると思います。「FlashVars」でFlashに引数を渡すこともよく使いそうですね。そして興味深いのが「wmode」の設定についてです。これはFlashの背景色を透過させるかどうかを決定するプロパティで「transparent」や「opaque」を指定するとFlashが描画しない部分は裏の要素が透けてみえるようになります。この設定が、どうもいつの頃からかデフォルトで透過するようにmixi側で設定しているようなのです。
デベロッパーセンターによると、Flashを透過させないと、マイミクを招待させるダイアログがFlashの後ろに隠れて表示されないケースがあるんだそうです。特定のブラウザで起こる環境依存の問題なので、開発者側で確認できないケースも多く、それでmixiが標準的にFlashは透過させる措置をとったのだと思いますが、Flashを透過させるといろんな副作用が発生してしまうのでした。
具体的には、Firefoxでは透過Flash内のテキスト入力欄に日本語を入力しようとすると文字化けが発生することがあります。（今後のバージョンで直る可能性も十分にありますが）
また、マウスホイールが発生するイベントを透過Flashは受け取れないことがあります。グリグリした操作感を得るには、背景透過はご法度なのです。
そして、自分を悩ませた最大の副作用は、背景透過はCPUのパワーをえらく消費するという点でした。ある時を境にIEでだけ発生した現象なのですが、アプリを開くとFlashが重すぎて、ブラウザの操作が困難になり、原因もわからず途方にくれ、せっかくアプリを登録してくれた人も操作を諦めてしまうという、結構悲惨な状況が続きました。
突然起こったこの事態に狼狽しつつ、PCのCPU利用度をモニタリングして、IEのプロセスがパンパンに膨れ上がっているのをみて、さてはアドオンの何かが悪さを？とか見当違いな方法をあれこれ試したものでした。wmodeの設定は消していたので、透過はされていないはずと思い込んでいたのですが、まさか標準で透過になっていたとは・・・。{wmode:''}の指定を加えたところ、今までが嘘のようにFlashが軽快に走りだしました。
ただし、透過をオフにした場合、前述の招待用のダイアログが隠れてしまうことがあるらしいので、招待時にはFlashを隠す処理を加えるのが望ましいとのことでもありました。そんなものいくらでも隠しますから、透過を強制しないでよ〜と思った次第です。
Last-Modified