社長BLOG

OpenPNE3.8に向けての段取り検討

OpenPNE3.7.0を先日リリースした。これまで開発状況を共有するため、月刊HOUOUという分かりやすいパッケージを提供して生きたが、今回正式にナンバリングされ、HOUOUプロジェクトとしての初の正式リリースとなる。

3.8.0までのリリース内容とそのスケジュールについて共有する。
確定したら、公式サイトからも告知する予定だ。

内容とスケジュール

3.7.0 ※リリース済み
3.6からの累積修正の取り込み。大量のバグ修正といくつかの機能拡張。ここではHOUOUらしさはまだ見えない。

3.8Beta1 4月6日(金)予定
HOUOUの成果を取り込み、スマートフォン対応はここで行われる。
ここで開発内容はFIXする。

データベース構造、設定ファイルの方式を固定化し、以後の変更は行われない。
※HOUOUシリーズでは、3.6からスムーズに移行するために、データベースの構造変更はもとから予定されていない。

3.8RC1 4月20日(金)予定
正式リリース一週間前に、バグを落ち着かせRC版をリリースする。
ここから、リリース時までに直すべき、優先度の高い追加のバグ修正を行う。
ドキュメント準備もこのシリーズで行う。

OpenPNE3.8.0 4月27日(金)予定
4月中のリリースを厳守。対応しきれなかったマイナーなバグはHOUOU安定版シリーズで修正を行う。

9面テーブルの進歩

OpenPNEでフレンドリストやコミュニティリストなどを表示する3×3のレイアウト、いわゆる「9面テーブル」のUI改善について考えている。
すでにOpenPNEのスマートフォン版UIでは、4×4の16面に移行している。

結論としては、PC版も将来的に16面に移行できないか?と模索している。

9面テーブルの歴史的価値

9面でSNSの参加者を表示する仕組みは、出始めた当初、これは画期的だと思った。

ホーム画面では、自分がひとりではなく誰かとつながっているんだ、という実感ができるし
メンバーページを覗いても、フレンドの写真を見ればその人の人となりがわかる気がする。
コミュニティでは、どんな人達が参加しているのか?雰囲気をつかむことができる。

2でも4でもなく3×3という奇数の配置も良かった。アナログの温かみのような印象も感じることができた。

自分なりに良さをまとめると

・仲間とつながっている事を確認できる
・写真が並ぶ、テキスト中心のソーシャルネットに華やかさ
・人が人っぽく見える
・複雑じゃない、自分も、他人も、コミュニティも同じレイアウトだという印象

これからの9面テーブル

当のmixiがホーム画面の9面テーブルをやめて、2×3の6面テーブルに移行している。
メンバーページ、コミュニティページでは9面のまま。たしかに、270ピクセル程度あるサイズは、かなり幅を取る。

2×3のテーブルは、スペース削減には役立っているが、反対にそもそもの良さをほとんど殺している気がする。
それならもっと別のレイアウトを発明したほうがいいと思う。

左列が写真がたくさんあって視覚的にリッチな状態は維持したいと思う。
まずは16面を試してみて、結果が良ければ採用し、さらに進歩させていきたい。

一ヶ月でOpenPNEをカスタマイズできる

来月、シンプルになったOpenPNE3.8をリリースする。

拡張をもっと身近に

これまでのOpenPNEはクソ難しかった。PHP&OSSらしからぬ難しさだ。symfonyを採用してらくできた部分も大きかったけど、難しさをこれまで改善できてこなかったのは、大きく反省すべきポイントだった。

サルでもわかる、カスタマイズができるOpenPNEをつくるために、徹底的にシンプルにする。

OpenPNE3.8はそんな取り組みが身を結び改善のスタートラインに立つバージョンにしたい。

具体的な目標値としては、OpenPNEを拡張するために必要な平均学習期間を30日以内に縮めること。

現在は、PHPを覚えて、symfonyの作法(モデル、ルーティング、バリデータ、フォームなどなど)を覚えて、それからOpenPNEの特殊部分を覚えてようやっと拡張ができる、という状態だった。

なんで簡単になるのか?

symfonyを覚えなくてもいい、JavaScriptでAPIを操作するだけで済むようになる。

特に自分はsfFormとバリデータは好かない。ありゃ面倒で、エレガントじゃない。好かないものは使いたくない。

これからはスマートフォンAPIを操作するだけで基本的な拡張ができるようにする。※ドキュメントはまだ書きかけ

Firefoxだって、拡張を書くのはわりと簡単だ。JavaScriptで拡張できる。
コアのコアまでめいっぱい拡張したい時までは、JavaScriptだけで済むように設計されている。

OpenPNEもこんなスタイルにしたい。
一般的なカスタマイズはJavaScript+APIで。本当にコアを変更したい時だけ、symfonyを触る、と。

こればっかりは触っていただかないと、わからないかもしれない。
ただ、開発中のHOUOUチームの面々は、こりゃ楽だわーと、以前よりも楽しく開発している。

SNSの運営者がちょっと勉強すれば、思い通りのSNSに拡張できる。
使って楽しく、拡張して簡単。そんなソフトウエアにしたい。

地域SNSホスティング無償提供の骨子

先日、地域SNSに関しては無償で運用できるように支援をすると表明をしました。
具体的に手嶋屋のサービスと照らして、どのように受け入れるかの検討状況について共有します。

無償提供の背景と概要

これまで私たちは、地域SNSに対してはOpenPNEソフトウエアを提供することで貢献してきました。
オープンソースなので、自由にホスティングしてもらえればいいし、足りない機能は改造して付け加えてほしいなぁなんて思っていました。実際には、そのホスティングや、足りない機能の付け足しが、地域SNSの運営者にとって技術的な負担になっているようでした。

そこで、ソフトウエア提供だけでない、もう一歩踏み込んだ支援が必要だと判断しました。

地域SNSを成功させるためには4つの要素があります。

1.コミュニケーションの土台となるOpenPNE
2.OpenPNEを運用する環境(ホスティング)
3.地域SNSの運営に特化した機能
4.コミュニティ運営

今回のプロジェクトは2段階目の、運用環境を支援することを目的としています。

具体的には2012年4月末にリニューアル予定の、「OpenPNEホスティングサービス」(http://pne.jp ) の特別サービスとして提供します。地域SNS通常10人程度の無料利用枠を、1,000人程度まで拡大します。このサービスが続く限り無期限に提供する計画です。

OpenPNE Ver3.8以降での提供になりますので、移転の際にはバージョンアップを行うことになります。

対象となる地域SNS

営利企業、非営利企業の運営を問わず、地域SNSを運営しているコミュニティを対象にします。応募者が多い場合は、なるべく多くの地域SNSを支援するために、選択と調整を行います。今回合計10,000人分のSNS枠を無償提供を予定しています。

対象となる地域SNSの例
・個人や有志、NPOなどの資金拠出で運営されていたSNS
・プロジェクトの終了に伴い、事情で次の運営母体が作れないSNS
・営利企業が運営しているが、内実ボランティア的な状態の地域SNS

応募方法・期間

手嶋 Twitter @tejima
にご連絡ください。

細かい補足などは、Facebook上地域SNS研究会 http://www.facebook.com/groups/localsns/

こちらで調整しています。覗いてみてください。

まずは3月末までにご連絡ください。応募が多く10,000人枠をオーバーする場合には、サーバを増強して追加対応を検討します。

地域SNSの今後

これまでいわゆる「地域SNS」と呼ばれていたものの半分くらいは、ひょっとしたらFacebookで事足りてしまうのかもしれません。

それでも残りの半分には、もっと地域に特化した、世間のSNSではできないような場所が必要だと思います。
暖かい人がいる、ここだけの話ができる、ほっとできる居場所、そんな独自の地域SNSを提供していきたいです。

それは、

3.地域SNSの運営に特化した機能
4.コミュニティ運営

この段階で、少しずつ実現していこうと思います。

OpenPNEのWEB全体公開機能をなくす

OpenPNEの公開範囲設定について考えている。

OpenPNE3からは、Web全体に公開というオプションを付け、
ユーザーの選択で認証なしでもコンテンツを公開できる機構を取り込んだ。

良かれと思ってつけた機能だが、メリットよりもデメリットのほうが目立っている。

デメリット

秘密の安心感がなくなる

仲間にしか見えない、という安心感が失われている。ひょっとしたらこのコンテンツはネットで公開されるかもしれない。
心配だ、という気にさせる。

デザインがダサい

ネットに公開するレイアウトと、内向きのコミュニティで使うレイアウトは用途が違うので別物になる。
外向きのサイトは、SEOや一覧性、かっこよさなどが重視される。
内向きのさいとでは、コミュニケーションしやすさや、編集や削除などの管理ボタンが多く搭載されているか?
などが重視される。
要するに、内部のデータやレイアウトを無加工でネット公開するとダサくなるのだ。

システム上の複雑さ

公開範囲制限は、SNSソフトウエアの中で一番管理が難しい。つくるのも、テストするのも大変だ。
パフォーマンスに与える影響も大きい。

それでも公開したい

WEBに公開したいケースを考えてみたが、SNSの運営者が公開に前向きという事情がある。
ユーザー個人としては、ネットに公開したい情報は自分のブログに掲載したほうが、一般的に価値が高い。

SNSとしては公開機能をなくすが、プラグインを導入するなどし、非常に簡単な方法でWEB公開するような仕掛けを考える。

あくまでもOpenPNE本体としては、WEB全体公開の機能をなくしたい。

信長とネオロマンスは混ぜるな危険

コーエーテクモ、「my GAMECITY」のリニューアル発表会開催。ゲームとSNSが融合した新しいタイプのコミュニティサイトに – GAME Watch.

コーエーテクモが自社のゲームのユーザー向けのSNSを展開している。

専門家として、中に入らせてもらって、いくつか思うところがあった。

SNSの背景画面が白い

これはよくありがち。メーカーが運営するSNSは、各ゲームの特徴によらないニュートラルなもの作る必要があり、必然的に、色がなくなる。ゲームのコミュニティに入るたびに背景色を変えてあげるという配慮が必要だな。

たとえばディズニーランドも、入り口や広場はニュートラルだけど、スターツアーズやカリブの海賊など、アトラクションに入ればそれぞれのカラーにガラッと変わる。そのなかではミッキーマウスも出てこない。

信長ファンとネオロマンスファンが同居


ファン層が全く異なるユーザーが同じ一覧の中に同居している。

それぞれのファンはコーエーが好き、というよりは、そのタイトルが好きで集まっているので、同居するのはまずいと思う。
両ファンを引きあわせ、化学反応を起こそうとしているなら、なかなかすごい。

信長や無双については、特に問題は感じないが、
ネオロマンスファンは、自分の本性を出しにくくなるのではないか?というのが危惧するところである。

どうしたらいいか?

ディズニーランドと同じ方式にすれば良い。

メーカー(=ディズニーランド事務局)は個人情報、課金、共通ポイントなどを管理する。

各ゲーム(=スターツアーズ、カリブの海賊)は、専用の入口を作って、没入体験ができるようにする。

既存ツールとのブリッジがOpenPNEに必要だ

これまで自分は大きな勘違いをしていたことがある。うすうす気づいてはいたが、ようやくはっきりした。

自分は世界のソーシャル化(世界中の組織や個人の生活や交流をSNS上で行えるようにする)を目指していた。
そのためにOpenPNEを便利にしていこうとせっせとつくっていた。

だって、mixiやTwitterやFacebookこれらのメガSNSは楽しいし便利だし、これがプライベートな仲間や組織でも使えたら、
もっと便利になる。自分が目指している世界のソーシャル化につながるじゃないか?と考えていたから。

ただ、SNSの中の機能だけをいくら開発しても、根本的にダメなんじゃないかと思うようになってきた。

OpenPNEの利用者は、学校だったり、既存の企業だったり、SNSに関係がない人達も参加している。
忙しく勉強したり働いている人全員に向かって、「君たちみんなSNSを使ってくれ」というのは少し横暴だとおもう。

メガSNSを使うのは、程度の差はあれどみんながSNSに興味を持ってるし、SNSを使おうと思う意欲のある人達だ。
そうじゃない人たちはそもそもアクセスしなくなるしね。

一方で、われわれが取り組んでいるOpenPNEは、SNSが好きか嫌いかに関わらずその組織の全メンバーを巻き込もうとしている。

SNSにはアクセスしないけどSNSにとって重要な人をカバーすることは、メガSNSに無いOpenPNEだけの使命だということに気がついた。

既存ツールとのブリッジ

SNSにはアクセスしないけど、既存の情報ツールにアクセスしてくれる人たちが、ツールを変えなくてもOpenPNEとかかわりを持つような、ブリッジ機能を持たせることが必要だ。

簡単な例をひとつあげる。

電子メールしか使わないひとには、SNSの中の人たちとのやりとりをメールを使ってできるようにする。

SNSの中の人たちには、掲示板やタイムラインとして表示させてあげれば、たとえSNSを使わなくても、実質的にSNSに参加しているのと同じことになる。

FAXがコミュニケーションの基板であれば、FAXインターフェースにしてあげればいい。

こうした既存ツールとのブリッジをしてあげることが、プライベートな組織参加者全員をソーシャル化するという、OpenPNEらしい進歩につながる。

今後、OpenPNEは、現実世界の住人と、サイバー世界の住人をブリッジさせるための接着剤、GLUEとして、発展させていきたい。

OpenPNE3.8の見通し

3.8の形が見えてきた。シンプル、スピード、スマートフォンの3つを指針に取り組んできた。

シンプル

OpenPNEは難しすぎる。サルでも扱えるソフトウエアを目指さなくては、多忙な運営者の負担になってしまうよ。

・インストールが複雑
・管理画面が複雑
・プラグインや機能が多くて複雑

この3つをシンプルにする。インストールは簡単にできる。管理画面の複雑な設定項目は隠す。
プラグインは一旦全部外してから組み立てる。

スピード

今回ソフトウエア自体のスピードアップには、あまり取り組めていない。
プラグインを外したことによって、幾分スピードアップが期待できる。

その代わりに進歩できそうなのが、ユーザー体験としてのスピードアップ。
スマートフォンUIを開発する際には、画面遷移を伴わないAJAXを効果的に使っているため、
実体験としての速度は向上している。

タイムライン機能とメッセージ機能は素晴らしく改善する。
タイムラインはチャットレベルのスピードに、メッセージ機能はIMレベルのスピードになる。

スマートフォン

スマートフォンは、コアと2つのプラグインに対してバッチリ対応する。
その他のプラグインについては、OpenPNE本体リリースのあとに、個別で対応していく。

小さくなって分かりやすく、使いやすくシンプルなOpenPNE
ユーザー体験がスピードアップするOpenPNE
スマートフォンに完全対応するOpenPNE

3つの方向性はこんな感じ。

スケジュール

3月中にベータ、4月上旬にリリースを目指す!

アットプッシュ「@PUSH」を国際標準に

アットプッシュとは今作った言葉。

Twitterで @tejima 形式で相手にプッシュすることができる。
@を送られた、相手はMentionとして通常のタイムラインより目立つ所に表示される。

Twitterの設定によっては、iPhoneのアプリバッジを光らせたり、携帯メールで通知してくれたりする。

分かりやすく、とても素晴らしい機能だ。

アットマークプッシュとは?

この素晴らしさを、もっと拡張できないだろうか?
@の数を一つではなく、2,3と増やしていくことでプッシュの強さを高めていくしかけだ。

@tejima は1プッシュ。これはメンション扱い。
@@tejima は2プッシュ。これは携帯メールやSMSなどモバイルデバイスレベルにプッシュ。
@@@tejima は3プッシュ。軽帯電話を鳴らして強いプッシュを実現する。

@4つ以上は、まだ定義していないがどんどん強くなる。
その人の周りにいる人にプッシュを送り、伝言を頼む、なんて機能はソーシャルっぽくて面白いかもしれない。

国際標準に

今日、デモンストレーションで、@@@プッシュで電話がかかるデモをしてきたが、なかなか評判が良かった。
既存の仕様と地続きであり、世界中のユーザーにとって説明なしで利用できるところが受けた。

国際標準になると、素敵なんじゃないか?なんて話を、XOOPSコミュニティの人たちと雑談した。
これは共通仕様になるかも!

スマートフォンレイアウトの単体テスト


◆テストガジェット配置イメージ

HOUOUで開発しているスマートフォンUIでは
LOGIN、HOME、MEMBER、COMMUNITY、SNSの5つの基本レイアウトがある。
これらのUIが正しく動作するか?ガジェットを格納できるか?ガジェットを格納したときにも、基本UI部分は正しく動作するか?
などの、テストを自動的に行いたい。

課題

スマートフォンUIでは、JavaScriptを多用しているため、ふたつの課題がある。

1.symfony limeを利用できない
2.テストプロセスの自動化ができない

limeはJavaScriptテストができるQUnitとAPI通信を偽装するモックをつくってくれるmockjaxを利用することでカバーできそうだ。

テストプロセスの自動化については、まだ良い解決策が見つかっていない。
Travis-ciでHEADLESSテストが実行出来るという記述があるので、これに期待している。
※PHP5.4ではWEBサーバモードがあるらしいので、この組み合わせでうまくいかないだろうか?

テストのやり方

要するに図のとおり。

テスト専用のガジェットを作り、その中にテストを記述する。
5つの基本レイアウトにそれぞれテストガジェットを一つづつ配置。
layoutHOME なら HOMETestGadgetとなる。

まずは他のガジェットを設置しない状態(ガジェットコンテナにテストガジェットしかない状態)で単独でテストを行う。
これに通過したら、基本レイアウト単体での動作は正しいとする。

レイアウトに他のガジェットが入った時も、そのガジェットとテストガジェットの両方を設置した上で組み合わせ検証を行う。

テスト用のfixtureには、テストガジェットを配置するように記述する。

レイアウト単体のUI動作試験が行いたいので、APIとの接続についてはmockjaxを利用してダミーのモック相手のテストとする。これが本番のAPIサーバ相手に通信すると、結合テストになってしまうからね。信頼性が上がらない。

これでレイアウト単体の動作確認は行うことができるはずだ。

OpenPNE�~�蓈���񋟃T�[�r�X�̂��m�点

  • ��K�̓z�X�e�B���O
  • �Z�p�T�|�[�g
  • �J�X�^�}�C�Y
  • OpenPNE Manager
  • ���q���܃T�|�[�g

ページの先頭に戻る