ブログマーケティングの考え方が変わるかもしれない。スプーのえかきうたで

　いま、ネットの話題独占といえば？？
　NHKおかあさんといっしょの「スプーのえかきうた」ですよね。

　これ
http://www.youtube.com/watch?v=R-fjqo3dNhg

　注意：

クリックすると、すぐに音が出てしまうので

　仕事中の人は、音が出ない（ミュートにするとか）ようにしてから、
　クリックするなら、してください
（音が出なくても、問題の箇所は意味が通じます）

　問題の箇所は、２分１２秒くらいから２５秒くらいまで。
　しょうこおねーさんの絵に注目！ありえませんぜ、だんな（＾＾；）

---

　でも、これが大ブレーク！
　８時４０分現在、gooのブログトレンドランキング１位で、ブログを中心に、いっきにおかあさんといっしょのしょうこおねーさんが有名になった！

　これで、「おお、おかあさんといっしょを見てみよう」という人も増えたんではないか？（ウィリアムのいたずらは、きょうは見そびれてしまったが、今度みたいと思っている）

　つまり、ブログでのマーケティング的には、NHK、大成功だったといえる！！

---

　最近、ブログを使ったマーケティングというと、

　いくらいくら、謝礼にはらうので、ブログにかいてください。
　その際、ここをリンクしてください

　というカタチが多い。この手のやつは、面白いわけではないので、内容が浅い。
　そのため、一時的にブログランキングで上位に行っても、すぐに落ちてしまうし、もともと無理やりネタにしているわけだから、他の人が、もりあげてくれない。

　そーじゃなくって、今回のおかあさんといっしょのように、ブログを書く人たちがとりあげそうな話題が、番組内に、はじめからあったほうが、ウケルということだろう。

　CMや番組作りも、今後そーいう方向（つまり、ブログを書く人がツッコミやすいような要素を、初めから入れる）で作っていくことが大切になってきたのかもしれない。

---

　ってことで、そういうことまで考慮して、NHKが、しょうこおねーさんを出して、絵をかかせているとしたら。。。おそるべしNHK？？

　というのは、３年前のスプーというのは
　これ
http://www.youtube.com/watch?v=3FT9b-0MA1I
なんだけど、
　注意：

クリックすると、すぐに音が出てしまうので

　仕事中の人は、音が出ない（ミュートにするとか）ようにしてから、
　クリックするなら、してください
（音が出なくても、問題の箇所は意味が通じます）

　これは、２分１８秒のところで、注意してみてほしい。

　絵を書いた面が、違わないか？

　しょうこお姉さん、描いた絵をもって回転してるよねえ、で、回転したまま絵を出してるよねえ。。＝＞裏にかいてある絵をだしている

　つまり、３年間の間に、NHKの放送の方針が変わり

３年前は、きれいなものを出したほうがいいという考え方
　→なので何回か練習して、うまくいったのを出したのであろう

でも、いまは、そのまま出したほうが、おもしろいし、話題になりそうという方針に変わり
　→そのまま、書いたままをだしたのであろう。。

　うん、たしかに、こっちのほうが、話題になっておもしろいもんね。


　とにかく、NHKが、そうおもっているかどうかは別として、マーケティングとブログの関係の曲がり角に来ているということは、いえそうだ。

iアプリによる「カーソル移動」？：入力不可にして、選択項目を変える

　iアプリにおける、複数画面の作成法のつづきです。
（前回と同じ言葉）
画面を表示する場合
（１）アプリ自身のクラス(iApplicationから継承）
（２）１画面分のクラス(PanelまたはCanvas＋リスナー）
にわけ、（１）をここで説明しました
　そして、（２）のpanelのケースについて、２のクラスは、Panelを継承し、必要なリスナーをすべてimplimentしたクラスを作ったうえで、以下のメソッドが必要であると書きました。
　(2-1)コンストラクタ
　(2-2)各種リスナー（複数のメソッドあり）
　(2-3)カーソル移動のためのクラス（いくつかのメソッドに分かれる）

そして、２－３については、２とおり考えられますと、ここで書きました
（あ）キー入力に応じて、カーソルを移動させる
（い）入力できるところを入力可、そうでないところを不可にする

　前回は（あ）を説明したので、今回は（い）です。

---

■入力不可にして、選択項目を変えるのに必要なこと
　これは、そんなにありません。ボタンを押されたら、入力可能項目を変えようとしているのですが、その場合、

・ボタンが押されたら、入力不可・可能を切り替えるメソッドをよぶ
・そのメソッドで、各項目の入力可能・不可をsetEnabledメソッドで切り替える

というだけです。

　以下、それぞれについて説明します。
　なお、ソースコードは、ここにあります。

---

■ボタンが押されたら、入力不可・可能を切り替えるメソッドをよぶ
　これは、componentActionで行います。
　引数のtypeがComponentListener.BUTTON_PRESSEDのとき、フェーズごとに
　　・次のフェーズにして
　　・次のフェーズの入力不可・可能を切り替えるメソッド（setEnableItem）をよぶか
　　　最後のフェースの場合には、終了します（setNextPanel(0)）。

ソースは、こんな感じになります

	public void componentAction( Component source, int type, int param)
	{
		//==============================//
		//	ボタンが押された　　　//
		//==============================//
		if (type == ComponentListener.BUTTON_PRESSED)
		{
			switch(phaseNo)
			{
			case	0:		//	
				phaseNo	=	1;
				setEnableItem(phaseNo);
				return;
			case	1:
				phaseNo	=	2;
				setEnableItem(phaseNo);
				return;
			case	2:
				app.setNextPanel(0);
				return;
			}
			return;
		}		

	}

（上記の＜　＞　￥　は本当は半角です)

---

■そのメソッドで、各項目の入力可能・不可をsetEnabledメソッドで切り替える
　setEnableItemっていうメソッドでやってます。
　フェーズ番号ごとに、
　　そのフェーズで入力可にするなら、setEnabled(true)に、
　　そのフェーズで入力不可にするなら、setEnabled(false)にすると
　入力可のものだけ、フォーカスをあてることができ、はじめに、入力可のなかで
　一番先頭の項目にフォーカス（カーソル）があたります。

　ただ、そんだけです。
ソースは、こんな感じになります

	public void setEnableItem(int phNo)
	{
		switch(phNo)
		{
		case	0:	//	挑戦する
			button1.setEnabled(true);
			textbox1.setEnabled(false);
			button2.setEnabled(false);
			button3.setEnabled(false);
			break;
		case	1:	//	入力
			button1.setEnabled(false);
			textbox1.setEnabled(true);
			button2.setEnabled(true);
			button3.setEnabled(false);
			break;
		default:	//	終了
			button1.setEnabled(false);
			textbox1.setEnabled(false);
			button2.setEnabled(false);
			button3.setEnabled(true);
			break;
		}
	}

（上記の＜　＞　￥　は本当は半角です)

---

ってことで、ＢＲＥＷと同じところまで説明したので、
このシリーズの次回はＢＲＥＷのほうに戻って、項目の入力・出力についてです。
いつやるか未定（まだ材料となるプログラムができていないんで）

動画を２値データで送り、変化した点の色が予測不能なときだけカラーにすると大幅圧縮できるから？

人間の目って、カラーで判断できる部分って、あんまり無くて、多くは、２値（白黒）しか判断できないじゃないですか！

　あれって、いままで、なぜなのかなあ？全部カラーのほうが、便利ジャン！って思ってたんだけど、昨日、気付いた！！

　そっか、カラーで全部送ったら、伝送量も、処理量も、メモリー量も全部カラーでたいへんじゃん！

・データを２値でおくり、
・白黒画像と前に保持しているカラー画像から、動きの無いとこ、予測できるところは補完し、
・予測不能な必要なところだけ、カラーで送ってもらえば

伝送量も、処理量、メモリー量も少なくてすむじゃん！と

---

つまり、こんなかんじ

　　２値で処理する　　　　カラー情報を送る
　　　　↓　　　　　　　　↑　　　↓
　　カラー化に必要なデータの　　　↓
　　ところを、送るように指示する　↓
　　　　↓　　２値データ　　　　　↓
　　２値データと、カラー情報から、カラー化
　　　　↓　　カラーデータ
　　それを表示する

で、このとき、「カラー化に必要なデータのところを送るように指示する」際に

１．２値データを判断して、
　　　動きが無いもの
　　　動きが予想つくもの（アフィン変換すると、その形になる）
　　は送らないでよい

２．予想がつかず、カラー情報が無いものだけ、色を送ってもらうようにする
　　→そのとき、視線を動かすように指令する
　　　（目の中心付近しか、カラーを認識する細胞が無いので）


　ってすると、送る転送量も少ないし、２値なので、処理量も少ないと。。

　そーすると、目の中心にしか細胞が無くても、必要なところだけ目を動かせば見れるわけだし。。

---

　また、２値のバッファ、カラーバッファとあるので、ダブルバッファリングみたいな感じになって、部分部分を並列処理しても、脳に送られる信号は、出来上がった画像を送ることで、あたかも１つの絵みたいにみえるのかな。

　で、この画像作成中も動きを予測して、補完してれば。。
　残像みたいなこともありえるのねと。。

　これは、推測（妄想？）だけど、実際、そーなってるのかにゃー？？

　だとしたら、人間って、すんげー速さで、補完処理をしてるってことで、すごすぎ。
　って、意外と補完処理（アンチエイリアスや補正とか）って、簡単なのかな（＾＾；）
　ウィリアムのいたずらが知らないだけ。。

---

　でも、この白黒で送信＋必要なところだけカラー＆白黒データから色予測＋補完

　っていうのは、圧縮・転送技術的におもしろいのかなあ？？

　って、考えただけで、ほんとうにそーなってるかどうか、わかんないんだけどね。
（目は白黒判断する細胞が多く、中心付近にしか、カラー判断細胞しかないのは、推測でなく、どっかで習った気がする）