社長BLOG

またアドバンスドサクセス項目を思いついてしまった。

通知センターというのはiPhpone iOS5の用語で、
アプリ内のあらゆるサービスから飛んでくる通知情報をユーザーに取って気持ち良い形で表示してくれる仕組みのこと。
Androidにも同様の仕組みがある。

Facebookでもいろんなアプリやサービスから飛んでくる通知は、ある程度まとめて管理してくれる。
OpenPNEにもほしい。

メッセージボックス、日記コメント、フレンドリンク申請、コミュニティ参加依頼などなど、OpenPNEでもいろんな場面で通知が飛んでくる。通知の種類は二段階。

・ホーム画面に赤文字で表示
・登録されているメールアドレスにメール通知

OpenPNE3では、通知に関してうまくマネージされているとは言えない。
いろんなサービスを参考にして、通知管理モデルを確立しなければ。

HOUOU最初の成果をどこに置くか？

ソースコード的な進化というよりも、HOUOUとしてのスタートを印象づけるものとして設定したい。

開発段階としては
◆マイルストン１
・プラグイン全外し
・prototype=>jQueryへスイッチ
・ガジェットレイアウトの見直し
・インストールをネットワークレスに
・ゴルゴンハニーの分離提供

◆マイルストン２
・スマートフォン基盤対応（招待、画像投稿、認証、画面振り分け）
・スマートフォン用AJAX関数群の整備
・スマートフォンコアUI
・ゴルゴンハニーとの連携

こんな感じで進めたい。マイルストン１はほとんど何もせず、空っぽのOpenPNEからスタートするけど、
OpenPNEが軽やかになった感覚は持ってもらえるだろう。

OpenPNEにはパラメータの名前を考えなくてはならない箇所が複数ある。

SNS全体の設定値を格納するSNS_CONFIG
メンバーのパラメータを保存するMEMBER_CONFIG
プロフィール情報を扱うPROFILEなど。
symfonyタスクの実行名もパラメータでは無いが、名前を考える必要がある。

これらのパラメータの命名規則は、いよいよきっちり定めたい。

Javaのパッケージ命名規約は参考にしている。com.sun.java というやつ。運用実績が多いというのが選定ポイント。

ただ、ドメインが逆順というのがトリッキーで嫌いだ。ディレクトリであるパッケージと違って変数は、ツリー構造の管理が必要ないので、今回は逆順にしなくてもいいかもしれない。

OpenPNEであれば、someparam.pne.jp とする。
プラグイン作者であれば、自分のドメインを利用して
somepluginparam.cqc.jpなどと命名すれば、OpenPNE本体や他のプラグインと衝突する心配がない。
こうした命名規則は、プラグインで利用するタスクの名称や略称にも適用できるはずだ。

命名規則が役に立つと思われる項目は次のようなもの

・TwitterやFacebookなど外部OAuthのアクセストークン
他のプラグインやコアアプリケーション間で共用する可能性がある。

・認証プラグインで利用するキー名
認証プラグインのキーはかなり重要なので、特別に目立つ名前で管理したほうがいい。

・OpenPNE本体で扱うメールアドレス
いまpc_addressとなってるけど、響きがオフィシャルっぽくない

現在は規約がない状態なので、HOUOUのローカルルールとして運用し、うまくいくようなら標準化
という運びにする。

プラグインなしのセットアップ

認証プラグイン一本だけの状態でインストールするように、plugins.ymlを変更する。

77webさんのハックを参考に。
https://gist.github.com/1283287

この部分の関連作業は
・除外したときに完全動作するか？を軽くチェック
・初期インストール時にプラグインサーバを確認しないように
・インストールに必要なバンドルパッケージは提供ZIPに含める

除外を検討する機能の一覧

コアに含まれている、他のサービスで代替可能な機能を除外する。管理画面機能のほうが除外しやすいので、ミニマムサクセスでは管理画面機能を中心にリストアップする。フルでは、ユーザー機能に踏み込む。

バナー設定
Google DFPなどに置き換え可能。OpenPNEよりももっとバナーを使いそうなWordpressにないんだから、なんでついているの？って感じがする。テーマやテンプレートに直接書きこんでもらうスタイルのほうが使いやすいだろう。

ホーム画面レイアウト
まだ洗練されておらず、使いこなせない。ここはソースを弄ってもらったほうが使いやすいんじゃないか？

規約とプライバシーポリシー
フリーページ＋アルファで置き換え効かないか？一度変更したら二度と買えないのでフラットなテキストでもいいくらい。

APIキーの設定
Ver2ではこういう設定はconfig.phpファイルに書き込んでいた。
OpenPNE.ymlやProjectConfigrations.class.php線引きは？
こういう要素があるのであれば、SNSCONFIGを汎用的に設定できる管理項目をひとつだけ用意し、
Windowsのレジストリエディタのような扱いにすればいいんじゃないかな。

インタラクティブをスキップ

インストールプロセスで引数を指定できるようにして、インタラクティブをスキップ。

OpenPNE.yml と ProjectConfigrations.class.phpをプリセットできるか？

ここはセキュリティ上の問題がありそうなので、海老ちゃんに確認する。

OpenIDなどでパスワードを要求しない

opAuthOpenIDPluginではOpenPNEの内部構造上の制約で、パスワードを要求するが、
OpenIDでログインしているのにユーザーにパスワードを設定してもらうというのは、シンプルではない。

ユーザーにとっての複雑さが増す。IDがなくてパスワードだけがある状態というのは、通常よりもかえって覚えにくい。
※メールアドレスとパスワードのセットというのは、ユーザーが慣れているやり方だしね。他のサイトと同じパスワードを使い回していたりなんかして。

何よりも重要なのは、プラグインを除外してスタートすること。
コア機能の除外は後のステップでいいな。

コミュニティよりもグループの方が全利用者にとって理解しやすいのではないか？

コミュニティとは、狭義の意味でSNSの中に設置されているコミュニティを指す。
ただ、今やこれはmixiから由来する日本の方言になりつつある。

OpenPNEの場合、SNS自体が、”ゲーム好きコミュニティ”や”◯◯顧客コミュニティ”であるため、狭義のコミュニティとの誤解がおこりやすい。

名称変更の実装はわりと簡単だが、実際に入れ替えるとなると、手続きがかなりややこしいので、項目としてはアドバンスドサクセスに積んでおく。

グループ関連の余談。

FacebookはFacebookでファンページやらグループやらともだちリストやらFacebookページやら、似たような概念が多くて、分かりにくい。
Twitterの”リスト”機能はソーシャル・ネットワーク的には失敗と判断している。参考にしない。
ハッシュタグもグルーピングの一種ではあるが、もっとうまく運用することができそうな気がする。Twiterの発明としては@tejima とRTが最高だが、ハッシュタグはもっと改良の余地がある。

Twitterが登場したときフォローという概念はとっても凄いと思った。
だが、最近はその考えが変わってきている。

フォローはそのリンクを貼るために相手側の許可を必要としない接続であってRSSリーダーにおける”購読”と同じ意味である。だったら、購読という要素を付け加えれば、フォローっていらないんじゃない？と思うようになってきた。

ダイレクトメッセージについての挙動についても気になる点がある。
Twitterでは、相手をフォローすると、その人からダイレクトメッセージを受けることができる。
一方こちらから送るには、相手からフォローしてもらわないとならない。
これは結構複雑で、
ダイレクトメッセージを送ったのに、フォローし忘れで相手が返事を出せないという事故がよくおきる。
通常のソーシャルネットワークと同じように、相互リンクした時だけメッセージを送りあえる。という仕様の方がよほどシンプルだ。

相互リンクがない相手に通知するには、@tejima 型のメンションである程度カバーできる。
単方向リンクで片側だけダイレクトメッセージが送れるという仕様は、混乱を増やすだけで、あまり価値がない。

通常のUXの世界で大事なのは、スピーディーに使いやすいこと、年齢を問わず誰にでも分かりやすいこと、などなどある。

ソーシャルネットワークのUXではこれに加えて、「コミュニケーションしている相手を感じられるか？」という要素が加わる。

以前ミッキーマウスは一人だけ効果という記事を書いたけど、
どちらのUIのほうが、ユーザー体験として、よりコミュニケーション相手を意識するか？ということを考える。

ゴルゴンハニー(opTimelinePlugin)でもできる限り相手を感じるUIにしたい。

今のタイムラインのスタンダードであるこんなUIは、ミッキーマウスひとりだけ理論に反しているんだけど、

スタンダードだし、みんな慣れてるよね。
相手からのコメントの場合写真を反対側にすると、なんとなく会話している雰囲気は増す。

フキダシにするとスペース効率が悪くなったような印象を与える。
フキダシっぽい丸みを出すとその分テキストの領域が少なくなる。ほとんど四角で角だけ丸いフキダシがいいだろう。

なんてことを考えながら、UIを洗練させていく。

※2011/11/15 追記
休日のうちにモックアップをいくつか追加した。

HOUOU本体は、シンプル、スピード、スマートフォンにフォーカスし、ソーシャル・メディアをつくるためのミドルウエアとしてOpenPNE3を洗練させること。

これだけでは洗練されていても、どうやって使うの？というアプリになってしまう。

エンドユーザー向けのキラー機能は、１つのプラグインで提供する。
opTimelinePluginがキラープラグインだ。

TwitterやFacebook、Yammer、Chatterなど、今のソーシャル・メディアの主力機能であるタイムライン機能を実現するプラグインだ。

相談しながら柏木くんがメインで作っている、コードネームは「ゴルゴンハニー」。

HOUOUは洗練されたミドルウエアになる。生地がとっても美味しいプレーンなピザ、というイメージだ。

このプレーンなピザに、ゴルゴンゾーラとはちみつを合わせるだけで、素晴らしく美味しい料理になる。
opTimelinePlugin もそんな小さくすてきなトッピングを目指すよ、という意味で「ゴルゴンハニー」と名付けた。

これはOpenPNE3.6でも動作するようにつくるので、既存のOpenPNE3ユーザーにとってもメリットがある。

OpenPNE3の設定ファイルは
OpenPNE.yml
projectconfiguration.class.php
自動的に作られるdatabases.ymlの３つある。

３つは多すぎる。シンプルでない。

ひとつしかだめだ。できることならゼロにしたい。

最低でもMySQLの接続アカウントを格納する必要があるので、ゼロにはできないんじゃないか、なんて思うのだが、
SQLiteならパスワードいらないから、ゼロまでできるかも。

設定ファイルをひとつにできないか考える。

HOUOUでプラグインをどんなふうに組み合わてUIをつくるか？という研究。

HOUOUでは、シンプルにすること、スピード早く、スマートフォンに対応ということだけ決まっていて、
UIについてはまだ明確なゴールが無い。ここで勉強している。

https://tejimaya.mybalsamiq.com/projects/op37/grid

プロジェクトは誰でも変更可能なので、新しいUI UXをつくる興味がある人は遊んでみてね。

今のところは全部ラフであり、未来への妄想なので、完成版はもっとOpenPNE3.6に近いUIになる予定。