WWW WATCH

クリエイターの強い味方、レッドブルにシュガーフリーがでたよ

2012-01-27T12:50:59Z

アスリートの方々はもちろん、我々 Web 業界の中の人にも「仕事に集中したいときに一発キメるヤツ」としておなじみの「レッドブル・エナジードリンク（Red Bull® Energy Drink）」ですが、新たにシュガーフリーでゼロカロリーの「レッドブル・シュガーフリー（Red Bull® Sugar Free）」がラインナップに加わりました。容量は日本限定の 185ml サイズで、今年 1月17日から首都圏のコンビニで先行販売中です。

実はウチの会社ではレッドブルさんの日本における Web サイト運営や Web プロモーションのお手伝いをさせて頂いていますが、その関係で新しく発売されたレッドブル・シュガーフリーをたーくさん頂いちゃったんですよね。なのでお礼もかねて宣伝、宣伝というわけです。

ということで、ある日こんなにたくさんのレッドブル・シュガーフリーが会社に届きましたとさ。

早速、乾杯。手タレ出演は弊社の中の人達です。

レッドブル・エナジードリンクは、日本限定の 185ml サイズと、レギュラーサイズの 250ml サイズの 2種類、それに今回、レッドブル・シュガーフリーが加わったので、3種類の展開になりました。全部並べるとこんな感じ。シュガーフリーはさわやかな感じのスカイブルーが目印です。

プルトップにはおなじみ牛さんも...

成分的には通常のレッドブル・エナジードリンクと全く同じで、砂糖不使用のゼロカロリーってことなので、レッドブル好きなんだけどカロリーがねぇ～というそこのあなたにもオススメの一品となっております。

ちなみに味は通常のレッドブル・エナジードリンクほぼ同じでした。所謂ゼロカロリー飲料は甘味料の関係で後味がちょっと...ってことが多くて、個人的にはあまり好きじゃなかったんですけど、このレッドブル・シュガーフリーに関してはそれがあまり気にならなかった（とはいってもまったくないわけじゃないですが）のでゼロカロリーもいいねってなりました。

ま、その辺は個人差があるんでしょうから、コンビニ等で見かけたときはぜひ一度試してみてくださいね。

レッドブル・シュガーフリーは今のところ首都圏での販売のみになっていますが、2012年 4月3日からは全国での販売も開始予定とのことですので、首都圏以外にお住まいの方も、春には地元で買えるようになると思いますよ。それまでは東京のお友達にでもおねだりして送ってもらいましょう。

ということで、新発売されたレッドブル・シュガーフリーの紹介でした。

なお、今弊社に打ち合わせ、商談等でご来社頂くと、レッドブル・シュガーフリーがお茶の代わりにでてくる可能性がございますので、取引先各社様におかれましてはぜひこの機会にご来社頂き、レッドブルフリークの仲間入りをして頂ければ幸いです。

「いいね！」スタンプを作ってみた

2012-01-27T09:05:06Z

かなり前ですが、ロンドンのデザインオフィス「NATION」が冗談半分で作った、Facebook の「Like!」ボタンを模したスタンプが話題になりました。今では ThinkGeek などで「Like / Dislike Stamp Set」として売られていますが、日本語の「いいね！」バージョンが欲しかったのでこちらも冗談半分で作ってみました。で、さらについでだったんで「Like / Dislike」もあわせて作って 3つセットに。

「Like / Dislike」バージョンは ThinkGeek なら海外発送もしてくれるので日本にいても買えるんですが、セルフインクタイプじゃなくてインク台使うタイプのヤツが欲しかったってのがあって、でももうそのタイプは売ってないんですよね。だったら作っちゃえというのが動機。

スタンプ作ると言っても、今は便利な世の中。データをちゃちゃっと作って入稿すれば、お手頃な価格でオリジナルスタンプを作ってくれる業者さんはたくさんいます。今回お願いしたのは「大谷印舗」さん。「イラストゴム印」の作成サービスでオリジナルのスタンプを作ってくれます。

今回、大谷印舗さんを選んだのは価格とかも手頃でよかったんですけど、印鑑の「台木」っていうんですか、要するに持つところが、他の業者さんだとグリップ型のが選べるところが少なくて。大谷印舗さんはそれが選べたのでってのが大きかったです。で、仕上がりは写真の通りでかなりいい感じ。土曜の夜に頼んで、火曜日には発送の連絡が来ましたし、すんなり作ってくれちゃいました。感謝。ちなみに送料とかも込みで 1つあたり 1500円くらいで作れました（実際にはサイズで値段が決まるので全部同じ金額じゃないんですけどね）。

データは Illustrator で作って入稿。原寸で作ってあとは注文メールに添付すれば OK なので、今回みたいな単純なデザインなら簡単。手書きのイラストとかでも、指定のファイル形式にして送れば作ってくれるそうなのでオリジナルのスタンプが欲しい人にはいいかも。

ということで、完成品の写真。下の写真は大きさがわかりやすいように iPod shuffle を並べてみたの図。

いや、作ったからといってどこかで使うかっていうと使わないと思うんですけど、そこはお遊びってことで。

iPad / iPhone をテレビにするデジタル TV チューナー

2012-01-22T07:02:48Z

SoftBank Selection として発売されている「デジタル TV チューナー」（SB-TV02-WFPL）を買ったのでレビューなど。

ちょっと前から考えてたんですが、よくスポーツバーでずーっとサッカーとかが店内モニターに流れてたりする、あれを自分の仕事部屋でもやりたくて、でもテレビを普通に買うと大きくて邪魔だっていうのと、CS のアンテナ線がリビングにしかないっていう事情から配線とかメンドクサイ（リビングから仕事部屋までアンテナ線引っ張るのとか大変...）っていうのがあって半ば諦めていました。ところが、そんな時に「デジタル TV チューナー」（SB-TV02-WFPL）を知って早速衝動買いしちゃいました。

元々私が求めていた要件というか希望としては

テレビは買いたくない（でかいし邪魔。それに大きい画面がよければ居間で見るし）
アンテナ線を引き直したりとか面倒なことはしたくない（居間に置いとけば、ワイヤレスで接続できるチューナーとかないのかなぁって思ってた）
地上波だけじゃなくて、BS / CS も受信できる（だって CS でサッカーチャンネル見たいんだもの）
録画とかは別にできなくていい

っていうのがあって、その中でも（2）と（3）を同時に満たす製品がなくて、iPda や iPhone 向けの地デジ（ワンセグ）チューナーなら色々リリースされていますけど、それじゃ意味ない。そんなこと思っていたら発売されたのが今回の「SB-TV02-WFPL」だったわけ。

ただ、なんかすごい人気みたいで、SoftBank の公式オンラインショップでは長いこと品切れ状態（これを書いている現在）になっているようですが、Apple Store で普通に買えました。Amazon でも売っているみたいですが、値段が足元見過ぎですよ。

製品の写真など

公式に紹介動画が YouTube にアップされていますので下に貼っておきますが、どんな製品かはこれを見れば何となくわかるかと。

ということで、実際の製品はこんな感じ。

大きさは 15cm 四方の正方形で、厚さが 3.5cm。CD ケースより 2周りくらい大きい感じですかね。まぁそれなりにかさばりますが、壁掛けもできるようになっていたり、置き方は自由なのでそんなに気にはならないと思います。

裏面は、アンテナ接続用の端子が、地上波と BS / CS 用にそれぞれ 2系統。LAN ポート（10BASE-T / 100BASE-TX）と電源入力、B-CAS カードの差し込み口など。

B-CAS カードは mini B-CAS カードを使用します。

こんな感じにブッ刺す。

早速接続しますが、アンテナ線関連に関して注意が必要。製品の同梱品としては 70cm くらいのアンテナ線が入っていますが、これが 1本しか入っていませんので、地デジ、CS / BS を両方受信したい人はアンテナ線を自分でもう 1本用意する必要があります。

また、既存のテレビなどとの分配に、アンテナ分配機（私はこれを使用）や、我が家は違いましたけど、地デジと CS / BS が 1本のアンテナ線（混合アンテナ）できているお宅なんかだと分波器などが必要になる場合もありますので、その辺は自分で揃えておきましょうね。

接続自体はアンテナ線繋げて電源入れるだけですので簡単です。

本体の設定、そして視聴

チューナーの接続が終わって、電源を入れたら簡単な設定をする必要があります。そのためには iPad / iPhone に専用のアプリを入れておく必要がありますので、App Store で落としておきます。

App Store に「デジタルTV (StationTV i)」というアプリがありますが、それが専用アプリになります。ユニバーサルアプリなので、iPad、iPhone 両方に対応。

アプリを入れたら、 iPad / iPhone （以降は iPad を前提に話を進めます）を「SB-TV02-WFPL」に接続します。接続は、アプリからじゃなくて、無線 LAN のアクセスポイントとして接続するので、iPad の「設定」を開いて、「Wi-Fi」 → 「ネットワークを選択」で購入した「SB-TV02-WFPL」の SSID を探し、説明書に記載の手順で接続します。

接続したら、さっき入れたアプリを立ち上げてみましょう。

実はこのあと「簡単接続設定」というチュートリアルがでて、上で書いた Wi-Fi での接続方法などを説明してくれますので、それを見ながらやってもいいですね。

配線と、Wi-Fi での接続が問題なければ次に進むと、チューナーとアプリが接続します。

しばらく待っていると...

接続が完了しました。うまく行かない場合は設定や配線を見直しましょう。

次にチャンネルスキャンに進みます。

地域を選んで、「スキャン開始」をタップ。あとはしばらく待つ...

お茶でも飲みつつ気長に待つ...

スキャンが終わって、これで視聴準備完了。

「視聴へ」をタップすればテレビが映りますよ。

チャンネルの切り替えなどは上部のメニューもできますし、画面を横にフリックするとチャンネル切り替え画面になったりします。

その他、字幕や音声チャンネルの切り替えなども設定メニューから可能です。

当然ですが、CS や BS の有料放送は「SB-TV02-WFPL」に刺してある B-CAS カードの番号で視聴契約をしなければ見ることはできないので必要なら契約しておきましょうね。

接続モードの設定

「SB-TV02-WFPL」には 3つの接続モードがあります。下記のような感じですが、今回私は「ST モード」を選択しました。

AP モード

AP モードは「SB-TV02-WFPL」を LAN ケーブルでルーターなどと有線接続してインターネットに接続する方法。iPad / iPhone は「SB-TV02-WFPL」に Wi-Fi で接続します。

「SB-TV02-WFPL」自体が無線 LAN アクセスポイントの機能を提供してくれるので、無線 LAN でネットワークをこれから作りたいっていう人には便利。他のノート PC なども接続先を「SB-TV02-WFPL」にすれば、無線でインターネットに接続できます。

スタンドアロンモード

「SB-TV02-WFPL」自体はインターネットにつながないで、単なるワイヤレスのテレビチューナーとして使えればいいやっていう人はこれが楽。

AP モードと同じく、iPad / iPhone は「SB-TV02-WFPL」に Wi-Fi で接続しますが、「SB-TV02-WFPL」はインターネットに接続していない状態。要するに、「SB-TV02-WFPL」と接続している間は iPad / iPhone も Wi-Fi ではインターネットに接続されていない状態になります。

なので、iPhone はいいですけど、iPad だと 3G モデルでなければ、インターネットにつなぎたいとき、いちいち接続するアクセスポイントを変更しなければならないのと、アプリの機能として用意されている、テレビを見ながらインターネットできる「ながら見モード」が使えなくなりすので、Wi-Fi 版の iPad を使ってる人（私もそう）にはあまり便利ではないです。

ST モード

今回私が選択したモードがこれ。元々無線 LAN によるネットワークを構築済みという人にはこれが一番オススメだと思います。

この場合、上の 2つのモードとは異なり、iPad / iPhone は普段使っているアクセスポイントに Wi-Fi で接続します。で、「SB-TV02-WFPL」もそのアクセスポイントに Wi-Fi で接続します。つまり iPad / iPhone と「SB-TV02-WFPL」が同一のネットワーク上にある状態ですね。

これで、「SB-TV02-WFPL」からのテレビ放送データは、普段使っているアクセスポイントを経由して、iPad / iPhone に送られます。インターネット接続も普段通りなので、テレビを見ながらインターネットも使えると。うん、とっても便利。

気になった点など

3点ほど気になった点を。iPad （iPad 2 じゃない）でのみ使っての感想ですが。

「SB-TV02-WFPL」の SSID や暗号化キーが変更できない
チャンネル切り替え時にタイムラグがかなりある
番組表や、チャンネル切り替え時に番組情報が見られない

（1）は無線 LAN アクセスポイントとして考えるとちょっとね。ちなみに ST モードで使っている場合には「SB-TV02-WFPL」に対して無線接続できなくなるので気にしないことにしましたが。

（2）は私はチャンネルを頻繁に切り替える使い方をしないこともあってあまり気にならないんですが、ザッピングしたい人には結構ストレスかも。チャンネル切り替えごとに、だいたい 10秒程度は待たされる感じですかね。聞いた話では iPad 2 だともうちょっとサクサク動くらしいです。

あと、（3）ですが、番組表の表示機能はないのと、せめてチャンネルを選択する画面で、今そのチャンネルで放送されている番組名くらいがわかると便利な気がしますが、そういうことは今のところできないので、それば別のところで調べる必要があります。ま、これも私は別にいいかなって感じなんですが。それに、今後アプリのバージョンアップでもしかしたら変わるかもしれないですしね。

ちなみに、見ている番組の詳細情報は、上部に表示されている番組名をタップすれば表示されますよ。

最後に注意点として画面のキャプチャを検出すると視聴が終了してアプリの再起動を求められます。この辺は著作権管理上必要な処理なんでしょう。この記事書こうとしてキャプチャしたんで気付きました。普通に使っていたら関係ないと思いますけどね。

あと、1度に視聴できる iOS デバイスの数は 1台ですよ。

ということで、iPad などで手軽に BS / CS も含めたテレビを見たいなんて人にはこの「SB-TV02-WFPL」、オススメですよ。

Flickr が IE7 と Firefox 3.6 をサポート対象外に

2012-01-16T14:00:37Z

Instagram やら、その他ソーシャル系サービスに埋もれて忘れ去られた感のある Yahoo! が提供する写真共有サービス Flickr ですが、個人的には有料アカウント持って写真投稿に関してメインで使ってたりします。

その Flickr が新年早々に今年の取り組みとして新しい写真編集機能の提供開始（元々採用していた Picnik からの移行）、「Photo Session」や「FlickrClock」、「FlickrAuth」といった一部古く、あまり使われていない機能の提供終了などを発表していますが、その中で、今後提供される新機能においては IE7 と Firefox 3.6 をサポート対象とせず、両ブラウザで Flickr にアクセスすると、新しいブラウザへの移行の呼びかけとダウンロードリンクを表示するようになるよと案内しています。

Start the New Year Fresh! ： Flickr Blog

Internet Explorer 7 and Firefox 3.6

For both of the browsers we are seeing a very small percentage of people using them and as of today people with those browsers will see an "update" message to encourage the download of the latest browser versions. This does not mean that IE7 and Firefox 3.6 users will experience problems using the site today, but the features and experiences that we will be releasing this year may not be supported on these browsers. For many reasons, foremost security, we encourage everyone to use the latest browser version on their devices.

Start the New Year Fresh! ： Flickr Blog から引用

「今すぐ両ブラウザで Flickr が使えなくなるわけではないですよ」っていうのと、さらに、「今後リリースされる新機能でサポートされない可能性があるよ」っていう書き方ですので、いきなり IE7 などで Flickr サイトが使えなくなるわけではないようですが、特にこの 2つの旧式ブラウザを使い続ける理由も恐らくはないと思いますので、セキュリティの観点からも早いこと最新のブラウザにバージョンアップしてしまいましょう。

先日、米国で IE6 のシェアが 1% を切ったという話題を取り上げましたが、IE6 はその最新版だった時期の長さなどから、社内システム等の関係で新バージョンに移行できないという企業ユーザーさんなどが多く、よく問題になります。しかし一旦そこから抜け出せば、もうあとは最新版の IE を使っても OK っていう状況がほとんどだと思います。そんな関係で IE7 のシェアは元々 IE6 よりも低かったりする変な状況になっていたりするんですよね。ま、そのおかげで影響を受ける人は少ないとは思いますが。

ちなみに、Google は去年 8月の時点で、（Gmail や Google Docs などで）以降は各ブラウザの最新版とその 1つ前のバージョンのみサポートするよと発表してたりします。なので IE で言えば、現行バージョンの IE9 と、1つ前の IE8 だけサポートするという形になりますので、すでに IE7 はサポート対象から外れています。Firefox はもうバージョンいくつか忘れるくらい高速リリースのおかげで進んじゃってますので 3.6 とか当然ながらサポート対象外ですね。

For this reason, soon Google Apps will only support modern browsers. Beginning August 1st, we'll support the current and prior major release of Chrome, Firefox, Internet Explorer and Safari on a rolling basis. Each time a new version is released, we'll begin supporting the update and stop supporting the third-oldest version.

Our plans to support modern browsers across Google Apps ： Docs Blog から引用

Facebook も特定のブラウザをサポート対象外にするよと明言した公式なリリースはちょっと記憶（単に調べてない...）にないのですが、サポートページではそれぞれのブラウザの最新版を使えと書いていますし、

Facebookがサポートしているウェブブラウザは何ですか。： Facebook ヘルプセンター

Twitter も IE6 でアクセスするとモバイル版に強制的にリダイレクトされたり、IE7 ではモバイル版には飛ばされないものの最新の UI は使えず、旧デザインでの表示になるなど、基本的にはすでにサポートしていない状態といっていいでしょう。

ということで、Flickr は大手 Web サービスでは IE7 や Firefox 3.6 をサポート対象外にするのが遅かった部類に入るんですね。ま、Flickr 自体、ここ最近はリニューアルや新機能のリリースとかしていませんでしたし、基本的には写真をアップロードして表示するだけのサービス（とかいうと失礼か...）なのでそんなにブラウザに厳しくなかったっていうのもあるのかもしれませんね。

広告枠販売はじめました

2012-01-15T23:19:50Z

宣伝な感じで申し訳ございませんが、個人の Blog の広告とか、しかも運営者個人で販売したらどんな感じなのかが知りたいという理由で、この度、当サイトの広告枠販売をはじめました。

下記、「広告掲載について」のページに価格などをまとめましたのでご興味のある企業様（もちろん個人様でもいいんですけど）、いらっしゃいましたらお気軽にご連絡ください。

広告掲載について

うちはたかだか月間 10万 PV 程度の零細 Blog ですが、この規模の Blog が広告掲載を募集したときにどの程度の反響があるのかとか、広告販売の過程でどういうところを気を付けた方がいいのかとか、広告主からどういう要望がくるのかとか、その辺を実体験として知っておきたいってのが今回こんなことをはじめた動機でして、実はこれで儲かるかとかは実はどうでもいい感じだったり、Blog で食べていくことに決めましたとか、そんな話ではなかったりします。

ま、もし広告出してもいいよって人がいたら、それはそれでこちらも運営に気合いが入るのでいいかななんて思っておりますので広告予算が余ってるぜという裕福な皆様、よろしくお願いいたします。

アメリカも IE6 シェア 1% サークルに仲間入り

2012-01-04T07:21:22Z

Microsoft の公式 Blog、「Exploring IE」で、2011年12月時点のデータ（Net Applications）において、Internet Explorer 6 （IE6）の米国でのブラウザシェアが 1% を切ったことが発表されました。

Microsoft では去年の 3月に IE6 の消滅までをカウントダウンする特設サイト「Internet Explorer 6 Countdown」を立ち上げ、その中で「The countries already below 1%」として IE6 のシェアが 1% を切った国を紹介していますが、同じく 2011年12月に IE6 のシェアが 1% を切ったチェコ、ポルトガル、フィリピン、ウクライナ、メキシコに加え、すでに 1% を切っていたオーストリア、ポーランド、スウェーデン、デンマーク、フィンランド、ノルウェイと合わせて 12カ国目の IE6 のシェア、1%未満の国となりました。

The US Says Goodbye to IE6 ： Exploring IE

なお日本での IE6 シェアは Internet Explorer 6 Countdown 上の表記（基データは Net Applications）では「5.9%」。去年の 2月くらいだと 10% くらいだったので、それでもかなり減ってます。

ということで、お祝いの様子も公式サイトでは紹介されています。

喜ぶのはよろしいが、今後は HTML5 関連やその他最新の技術仕様に関して、IE の対応スピード強化をお願いしたいところ。

ちなみに、Microsoft では今年から IE6 / 7 ユーザーに向けた強制アップデート（事前に拒否も可能）を開始する計画だという発表が去年の年末にされています。

IE to Start Automatic Upgrades across Windows XP, Windows Vista, and Windows 7 ： Exploring IE

Dropbox にファイルを置くと自動で色々な処理を実行してくれる Dropbox Automator

2011-12-31T19:41:49Z

あけましておめでとうございます。新年初エントリーですが、TechCrunch 等で取り上げられていた、「Dropbox Automator」を試してみたので紹介。

Dropbox Automator は、Dropbox の指定したフォルダにファイルがアップロードされたときに、あらかじめ指定しておいた各種処理を自動的に実行できるサービス。例えば、画像をアップしたら自動的に Flickr にアップしてくれたり、文書ファイルをアップしたら、自動的に PDF に変換しておいてもらうといったことが可能になります。

簡単に使い方を。

まずは Dropbox Automator にログインしますが、Dropbox のアカウントに対してファイルへのアクセス許可を与えます。Dropbox Automator のサイトから、「Login with Dropbox」に進みましょう。承認画面が表示されますので、許可します。当然、Dropbox のアカウントが必要なので持っている前提ですよ。

次に処理のトリガーとなるフォルダを選択します。処理は複数登録できるので、ファイルをアップロードするフォルダごとに異なる処理を登録することも可能です。

フォルダを選択して「Next」で次に進むと、今度は処理（アクション）を選択する画面に。

例えば、「Convert to PDF」（PDFファイルへの変換）を選択すると、対応するファイルが表示されます。「Add Action」を押せば、処理を登録できます。

複数の処理を組み合わせて登録することもできますので、引き続き必要に応じて他の処理を選択するなどし、最後に「finished?」と表示されたボタンを押せば、登録完了です。

あとは、最初に決めた Dropbox フォルダに、登録した処理に合致するファイルをアップロードすれば処理が実行されます。

組み合わせ次第ですが、「Downscale」と「Upload to Flickr」を組み合わせるなどすれば、デジカメで撮影した写真を Dropbox にアップするだけで、リサイズ後、Flickr に自動でアップロード、なんてことが可能になります。使い方によっては便利かもしれませんね。

もうちょっとできる処理が増えたりすると面白いサービスかもしれません。

5分でわかる Tumblr の始め方（2012年改訂版）

2011-12-31T13:43:47Z

2011年も終わりですね。今年最後の投稿は過去記事の改訂版で締めます。

さて、もう 3年近く前の 2009年に今回の記事の元記事（5分でわかる Tumblr の始め方）を書いたわけですが、Firefox もバージョンアップして Greasemonkey 周りのスクリプトなどが色々面倒な感じになっていたりしますので、ここらで古くなった情報を更新しようと思います。

元の記事で情報として古くなっている「Tumblr をもっと便利に使う」の項目を中心に書き換えていますので、それ以外の部分は元記事を見てください。

元記事
5分でわかる Tumblr の始め方

Tumblr をもっと便利に使う

さて、しばらく使っていると、ダッシュボードをもっと快適に閲覧したいとか、簡単に Reblog したり、ネット徘徊中に気になった記事を簡単に投稿したいとか思い始めると思います。そしたら下記を試してみてください。

Firefox を使え

これが前提なんですけど、まだ使ったことない人も試してみることをオススメしますよ。Firefox のダウンロードはこちらから。今は Google Chrome なんかもアドオン含めていい感じですが、私は特に Firefox に大きな不満はないのと、アドオンなどを含めた使い慣れた環境を変えるのは面倒なので Firefox 前提で話を進めます。補足で Chrome 関連のことも書いておきます。

アドオン： Tombloo, AutoPagerize, Greasemonkey を入れる

Firefox を入れたら、まずは下記の 3つのアドオンだけでも入れてみましょう。

Tombloo

Tombloo は色々な Web サービスに色々なものを簡単に投稿することができるアドオン。Tumblr 専用ではないのですが、ページ内の文章、写真、リンクなど、右クリックから簡単に Tumblr に投稿できます。必ず Tumblr にログインした状態で使用しましょう。

Firefox を立ち上げたら、ページの適当なところで右クリックしてコンテキストメニューを表示すると、そこに「Tombloo」のメニューがありますので、そこから設定などは変更できます。Tombloo は数多くのサービスに対応していますが、使っているサービスだけ投稿先の候補にでるように整理しておくと煩わしくないかもしれません。

にしておくと投稿先候補には非表示
で初期状態は未選択だけど投稿先候補には表示
しておくと投稿先として選択された状態に

という感じですので、普段利用しているサービスに合わせて設定しましょう。ちなみに私の設定は下記のようにしてます。

※ Google+ への投稿は Tombloo の通常機能ではなく、パッチ（YungSang 氏の model.gplus.js）を当てて機能追加しているものです。

AutoPagerize

AutoPagerize は今見ている次のページを先読みして、ページ下部に継ぎ足していってくれるアドオン。ページ遷移をしなくてもどんどん下に次のページが継ぎ足されていきますので、Tumblr ダッシュボードみたいに、所定の数の投稿を表示したら「次のページへ」ってなっている形式のサイトをどんどん読んでいくにはとても便利。特に後で書く、Tumblr ダッシュボードを快適にするユーザースクリプトを使う場合はこれがないといちいちページ送りしなくてはいけないので意味がありません。

Tumblr の設定で「Enable endless scrolling」にチェックを入れれば同じようになるのですが、あっちだとちょっと先読みが遅いので私は使っていません。

元記事では Greasemonkey スクリプトとして入れようぜって書いていたのですが、前述した Greasemonkey 周りの色々な仕様変更によりアドオン版入れた方が今は楽ですので、こちらを使います。Tumblr ダッシュボードだけでなく、Google の検索結果にしても、AutoPagerize なしとかありえんっていうくらい便利な機能なので是非使ってみてください。

ちなみに、アドオン版の機能オン / オフはコンテキストメニューの「AutoPagerize」項目から行えます。また、AutoPagerize を実行しないページを設定画面から指定することができます。URL で指定しますが、ワイルドカードや正規表現が使えますので、例えば下記のように書くことで、検索結果画面だけ AutoPagerize を無効にしたり、サブドメインも含めて特定のドメイン上では AutoPagerize を無効にするといった指定も可能です。AutoPagerize が動作してしまうと色々問題が起こるページなどはこれで対処しておくといいかも。

example(wildcard): http://www.example.com/search?*
example(regexp): /[^.]+\.example\.com\//

あと、個人的には AutoPagerize を少しカスタマイズして使っています。

というのも、デフォルトではページ下部（というか次のページを継ぎ足す位置）まで 400px の高さまでスクロールした時に次のページを読み込みにいく設定になっていますが、これだと感度が悪くて毎回ページ読み込みで待たされる感じになるのと、縦に長い投稿があったときに先読みが動作しなくて使い勝手が悪かったりしますので、そこをもう少し早めに読み込みにいくようにします。

ここはスクリプトを直接いじる感じになりますが、Firefox のプロファイルフォルダ内にある AutoPagerize のフォルダから、「autopagerize.user.js」を探し出してテキストエディタなどで開き、19行目付近にある下記の記述を変更します。

var BASE_REMAIN_HEIGHT = 400

上の記述の「400」の部分を

var BASE_REMAIN_HEIGHT = 4800

上記のように大きな数字に変えます。変更したら上書き保存すれば OK。

大きな数字にすればするほどスクロールしなくてもどんどん先読みしていくことになりますが、あまり調子のり過ぎるとページを読み込んだ瞬間に数十ページ分一気に先読みを始めて非力な PC だと大変なことになったりしますのでご注意ください。

なお、Firefox のプロファイルフォルダは、ヘルプメニューから「トラブルシューティング情報」を開いて、「アプリケーション基本情報」内にある「プロファイルフォルダ」横の「フォルダを開く」を押せば開けます。

そこにある「extensions」フォルダが各プラグインの格納場所ですが、同じく先の「トラブルシューティング情報」内にある「拡張機能」 → 「AutoPagerize」 → 「ID」って項目に入ってる文字列と同じ名前が付いたフォルダが「extensions」フォルダ内にあるので、その中にある「resources」フォルダ内で

[Extension-ID]-autopagerize-data

ってフォルダを探すとそこに「autopagerize.user.js」があると思います。面倒ならプロファイルフォルダ内で検索かければいいんじゃないですかね。

Greasemonkey

Greasemonkey は JavaScript によるユーザーサイドスクリプトを任意の Web サイト等で実行できるようにするアドオンです。

ユーザースクリプト： Tumblr Life を入れる

次に Greasemonkey を使ってユーザースクリプトを追加しますが、下記がオススメ。

Tumblr Life for Greasemonkey

元記事では LDRize, Minibuffer, ReblogCommand の組み合わせを書いていたのですが、Greasemonkey のバージョンアップに伴い、LDRize とか素のままの Greasemonkey 上じゃ動かなくなってたりして色々メンドクサイので、その代わりに Tumblr Life ※ を使います。

インストールは Greasemonkey を入れていれば、スクリプトのページで「インストール」ボタンを押すだけ。簡単です。

Tumblr Life

Tumblr Life を入れることで、Tumblr ダッシュボード上で下記のキーボードショートカットが使えるようになります。

j	次のポストにフォーカス（つまり下移動）
k	前のポストにフォーカス（つまり上移動）
a	like, unlike
r	reblog
q	reblog (add to queue) - キュー（Queue）に入れる
w	reblog (private) - 非公開で Reblog
e	reblog manually - 手動でReblog（Reblog 投稿画面が開く）

ということで、この Tumblr Life と AutoPagerize の組み合わせで、ページ送りを気にせず、キーボード操作で投稿を次々と移動（j, k）し、Reblog / Like （r, a）をガンガンしていけちゃいます。

Google Chrome の場合

AutoPagerize も Tumblr Life も Chrome 版がありますのでそのまま使えますし、Tombloo に関しては、Chrome 用で同様の機能を持った「Taberareloo」が公開されていますので、Chrome をメインで使っている人も同じような環境を作ることができます。

ということで 2012年も enjoy! tumblr.

※ 元々は Minibuffer, LDRize が動作に必要なスクリプトでしたが、現行バージョンでは単体で動作するようになっています。

Fullscreen API を簡単に試してみた

2011-11-24T02:18:15Z

ちょっと前、先月の話題になってしまうのですが、Web ページ内の任意の要素をフルスクリーン表示可能にする Fullscreen API に関連して、Mozilla が公開している Gecko:FullScreenAPI が更新されて Firefox Nightly で使えるようになったり、W3C からも Fullscreen （Editor's Draft）が公開されたりと色々動きが活発になってきましたので、いい機会ということで、お勉強ついでに簡単に試してみました。

例えば HTML5 で追加された video 要素は、今まで Flash などのアドオンに頼ってきた動画の Web ページへの埋め込み、再生を HTML 側で対応することを可能にしましたが、フルスクリーン（全画面）表示に関しては機能として含まれていませんでした。Fullscreen API は、JavaScript を使用して、video 要素や、canvas をはじめ、任意の要素内をフルスクリーン表示することを可能にしてくれます。

さて、ブラウザごとの対応状況ですが、Fullscreen API に関して、元々は Safari が 5.0 （+ iOS 4.2）で webkitEnterFullscreen() メソッドとして実装していましたが、その後、5.1 からは Mozilla の Gecko:FullScreenAPI をベースにした実装に変更されています。よって、Safari 5.1 以降では利用可能。

また、Firefox と Chrome に関しても対応が進んでいて、Chrome 15 以降ではすでに使用可能、Firefox は正式版ではまだ未対応ですが、先に書いたとおり Nightly 版の方では対応しているそうです（full-screen-api.enabled を true にする必要あり / 正式版での対応は Firefox 10 を予定）。

ただし、後述しますが、現時点では利用可能となっているブラウザでも、ベンダプレフィックスが必要な先行実装状態です。

で、この流れの中で、W3C からも Fullscreen API の仕様がドラフトとして公開されましたが、W3C から公開された Fullscreen （Editor's Draft）は、Gecko:FullScreenAPI とは少し内容が異なっているようで、例えばフルスクリーン解除時に使用するメソッドが違ったりします。

Fullscreen の基本的な仕様

今回は W3C の Fullscreen ドラフト仕様をベースに話を進めますが、仕様ではフルスクリーン表示のための API と、フルスクリーン時のスタイルを指定するための CSS セレクタがセットで用意されています。

まず API の方ですが、下記の 4つが。

requestFullscreen()
fullscreenEnabled
fullscreenElement
exitFullscreen()

CSS セレクタとしては下記の 2つの疑似クラスが用意されています。

:fullscreen
:fullscreen-ancestor

順に説明しますが、まずは基本的なフルスクリーン切り替えを行うための 2つの API と CSS セレクタから。

requestFullscreen()

フルスクリーン表示への切り替えを行います。現状では対応ブラウザで動作させる場合でもベンダプレフィックスが必要ですので Firefox は mozRequestFullScreen() 。Safari、Chrome は webkitRequestFullScreen() と記述する必要があります。

exitFullscreen()

フルスクリーン表示を終了します。現状ではベンダプレフィックスが必要な点は requestFullscreen() と同様ですが、Gecko:FullScreenAPI ではメソッド名が異なる cancelFullScreen() を使用しますので、Firefox の場合は mozRequestFullScreen() 。Safari、Chrome は webkitCancelFullScreen() と記述する必要があります。

この2つの API で、フルスクリーンの表示、解除の切り替えは可能です。最も単純に書くなら、下記のようになります。まず、HTML5 のサンプルソースを。

<div id="content">
 <video controls>
  <source src="sample.webm"></source>
  <source src="sample.mp4"></source>
 </video>
 <p>
  <button id="enterFullscreen" onclick="enterFullscreen()">フルスクリーンで見る</button>
  <button id="exitFullscreen" onclick="exitFullscreen()">フルスクリーンを解除</button>
 </p>
</div>

今回は video 要素の下部に配置されたボタンを押したときに、それらを包含する div#content をフルスクリーン表示、さらにフルスクリーン解除を操作するというのを考えてみますが、JavaScript の記述は例えばこんな感じになります。

<script>
//フルスクリーンに切り替え
function enterFullscreen() {
  var x = document.getElementById("content");
  if (x.webkitRequestFullScreen) {
    x.webkitRequestFullScreen();
  } else if (x.mozRequestFullScreen) {
  x.mozRequestFullScreen();
  } else {
    x.requestFullScreen();
  }
}
//フルスクリーンを解除
function exitFullscreen() {
  if (document.webkitCancelFullScreen) {
    document.webkitCancelFullScreen();
  } else if (document.mozCancelFullScreen) {
    document.mozCancelFullScreen();
  } else {
    document.exitFullscreen();
  }
}
</script>

また、CSS セレクタでフルスクリーン時のみ、異なるスタイルを適用することもできます。

:fullscreen

:fullscreen 疑似クラスを使うことで、フルスクリーン状態にした最も上位の要素にマッチします。上のサンプルなら div#content ですね。

なので、フルスクリーン時、div#content 内の video 要素の width も 100% にしたければ、下記のように記述しますが、これも Gecko:FullScreenAPI と W3C の仕様では名前が異なる（Gecko:FullScreenAPI では :full-screen 疑似クラス）のと、ベンダプレフィックスも必要ですので、全部書くと下記のような記述になります。

/* -webkit- */
:-webkit-full-screen video {
  width: 100%;
}
/* -moz- */
:-moz-full-screen video {
  width: 100%;
}
/* Mozilla Proposal (-)がつきます */
:full-screen video {
  width: 100%;
}
/* W3C Proposal (-)がつきません */
:fullscreen video {
  width: 100%;
}

:fullscreen-ancestor

:fullscreen 疑似クラスはフルスクリーン状態にした最も上位の要素（つまり今回のサンプルだと div#content）の先祖となる要素にマッチします。例えば、通常時にはフルスクリーン対象となる要素の外側にあるメニューに、フルスクリーン時だけ特別なスタイルを適用して表示させたいなんて時には使えると思います。

ちなみに、フルスクリーン時のブラウザデフォルトスタイルとしては下記の内容が適用されるように、仕様内ではルール決めされています。

/* A full-screen element that is not the root element should be stretched
   to cover the viewport. */
:full-screen:not(:root) {
  position:fixed;
  top:0;
  left:0;
  right:0;
  bottom:0;
  z-index:2147483647;
  background:black;
  /* override mapped width and height attributes */
  width:100% !important;
  height:100% !important;
}
/* W3C Fullscreen Editor's Draft 17 November 2011 */
:fullscreen {
  position:fixed;
  top:0;
  left:0;
  right:0;
  bottom:0;
  z-index:2147483647;
  box-sizing:border-box;
  margin:0;
  width:100%;
  height:100%;
}
/* If there is a full-screen element that is not the root then
   we should hide the viewport scrollbar. */
:root:full-screen-ancestor {
  overflow:hidden;
}
:full-screen-ancestor {
  /* Ancestors of a full-screen element should not induce stacking contexts
     that would prevent the full-screen element from being on top. */
  z-index:auto;
  /* Ancestors of a full-screen element should not be partially transparent,
     since that would apply to the full-screen element and make the page visible
     behind it. It would also create a pseudo-stacking-context that would let content
     draw on top of the full-screen element. */
  opacity:1;
  /* Ancestors of a full-screen element should not apply SVG masking, clipping, or
     filtering, since that would affect the full-screen element and create a pseudo-
     stacking context. */
  mask:none;
  clip:auto;
  filter:none;
/* W3C Fullscreen Editor's Draft 17 November 2011 */
  transform:none;
  transition:none;
}

あと、上で説明していなかった 2つの API ですが

fullscreenEnabled

ブラウザが Fullscreen API に対応しているかを調べます。

fullscreen Element

フルスクリーン化されている要素を返します。

Gecko:FullScreenAPI では上記以外にも API が用意されています。詳しくは Gecko:FullScreenAPI のページを見てください。

セキュリティ関連

8 Security and Privacy Considerations

User agents should ensure, e.g. by means of an overlay, that the end user is aware something is displayed fullscreen. User agents should provide a means of exiting fullscreen that always works and advertise this to the user. This is to prevent a site from spoofing the end user by recreating the user agent or even operating system environment when fullscreen. See also the definition of requestFullscreen().

To prevent embedded content from going fullscreen only embedded content specifically allowed via the allowfullscreen attribute of the HTML iframe element will be able to go fullscreen. This prevents untrusted content from going fullscreen.

Fullscreen から引用

悪用されないようにということで、そのサイトでフルスクリーンモードに最初にした場合は下記のように「フルスクリーンになってるけどいいの？」という確認が出るようになっています（Chrome の表示例）。また、フルスクリーン解除メニューは、制作者側で用意しなくても、ブラウザの UI として提供されるように推奨されています。

あと、iflame のフルスクリーン表示に関しては、allowfullscreen 属性（この属性も現在策定中なので、現状ではベンダプレフィックス付きの webkitallowfullscreen, mozallowfullscreen を使用）がないと有効になりません。

ということで、最後に上記サンプルをベースにしたデモを下記に置いておきますので、Chrome か Safari の最新版あたりで試してみてください。サンプルは本当に簡単に書いているので、あまり参考にならないかもしれませんが。

Fullscreen API 動作デモ

Web サイト側での実装例だと試用版として提供されている YouTube の HTML5 版は、対応しているブラウザに関してフルスクリーン表示をこれでやっているようなので、見てみるといいかもしれません。ちなみに、YouTube の iframe 版埋め込みコードにはすでに allowfullscreen 属性が含まれていたりしますが、これは上で書いたセキュリティ面の仕様に従ったものですね。

Google+ プロフィールバナー画像作成用 PNG ファイル

2011-11-23T08:16:14Z

Google+ のプロフィールページって、メインのプロフィール画像以外に最大 5つまでスクラップブック写真っていう画像を掲載することができるんですよね（プロフィールバナーと呼ばれているみたいですが）。で、ここに 1枚の画像を分割して掲載したかったので簡単にサイズ調べてスライス用のレイヤーを作ったんですが、折角なのでシェアしようかなと思います。

実際に設定するとこんな感じになります（画像クリックで実際のページが開きます）。下記はこの Blog の Google+ ページに設定してみた例です。

PNG でスライスレイヤーを設定済みですので、Fireworks で開いてもらって、スライスしたい画像に丸ごとコピペするなどしてもらえればあとは画像を書き出すだけです。

PNG ファイルのダウンロードは下記のリンクからどうぞ。

Google+ プロフィールバナー画像作成用 PNG ファイル（zip / 28KB）

実際に反映するには、Google+ でプロフィール画面を開いて編集画面に進み、「ここに写真を追加」をクリックしたら、左端に置きたい画像から順番に追加していき、5つの画像をすべてアップロードし終わったら「OK」を押せば完了です。

横長の写真の方が作りやすいので、使う写真は選ばないといけないかもしれませんが、パノラマ写真っぽいのを使ったりするといい感じになったりしますよ。下はサッカースタジアムで撮ったパノラマ写真を使ってみた例ですね。

Facebook でもプロフィール画像と上部の画像一覧を組み合わせてデザインっぽく作るなんてのが流行りましたが、Google+ も作り的には同じ感じなので、うまく画像を組み合わせてあげると、人とは少し違ったプロフィールページが作れるかもしれません。

特に Google+ ページの方は運営する団体や企業、Web サイトやサービスのイメージに合わせて少しオリジナリティを出したいというニーズもあると思いますのでうまくこのスペースを使ってみたらいいんじゃないでしょうか。

ちなみにこのプロフィールバナー画像の作成をオンラインでやってくれるサービスとしては「BannersPl.us」などがありますので、手軽に作りたいという人はそちらをどうぞ。

Google+ 「ページ」が公開。ページの作り方と注意点

HTML5 は SEO に有効なの？

2011-11-17T12:28:24Z

「HTML5 でコーディングしたら SEO （検索エンジン最適化）的に有利になりますか？」っていう質問、たまに聞かれるんですけどね。

個人的には "SEO のために" HTML5 にするか XHTML にするかなんて悩んでる暇があったら利用者に役に立つコンテンツの 1つでも考えた方がいいよと思うわけですし、聞かれたときはそのように答えているわけですが、折角なので簡単に考えをまとめて Blog に書いておいてみようかなと思ってダラダラと書き始めていたら、自分が書こうと思っていた内容をすべて言ってくれてしまっている記事が Impressive Webs で 10倍わかりやすく書かれていたので引用しつつ紹介してみようと思います。

原文
Is HTML5 Good for SEO? ： Impressive Webs

ということで、まずは記事冒頭から。

Also, when we use the term "HTML5", what exactly are we referring to? HTML5 covers a number of different features and technologies, some of which have nothing to do with SEO. So, generally speaking, when people ask this question, they're usually referring to HTML5's new semantic elements. So, I'll primarily focus on those here.

訳：
「HTML5」という用語が正確には何を指しているのか？ HTML5 はさまざまな機能や技術を含んでいて、中には SEO とは無関係なものもあります。なので一般的にこの質問（HTML5 は SEO に有効なの？）における「HTML5」とは、新しく追加されたセマンティックな要素を意味します。ここでは主に HTML5 で追加された新しい要素に焦点を当てたいと思います。

Is HTML5 Good for SEO? から引用

HTML5 とはっていう話はし始めると長くなるので適当に。要するに HTML5 で追加された要素がどういう風に解釈され、それによって SEO 的な効果が変わるのか？という点に絞って話を進めましょうと。この質問への回答例としていくつかのサイトで書かれた記事へのリンクが紹介されています。

で、それに対してですが、

To put it quite bluntly: They're wrong. No, they're not 100% wrong; I would never say that about any article. But there are things stated in those pieces that are somewhat misleading and presumptuous. Not to mention that a few of them have some blatant errors. The reason I point these ones out specifically is because they come up early in search results for HTML5 and SEO.

訳：
率直に言えば間違っています。100% 間違っているとは言いませんが、いくつかの誤解や目に余る間違いがあるのは確かです。この 3つの記事を例として上げたのは、HTML5 と SEO で検索したときに検索結果の上位に表示されるからです。

Is HTML5 Good for SEO? から引用

つまり、例として挙げられたサイトの内容は、HTML5 を選択すると SEO 的に優位に働くよという論調なわけですが、ちょっとまてと。

Will HTML5 Help Your Content Rank Higher?

Using HTML5 semantic elements in your pages today will not give your content higher search engine rankings. And I would venture to guess that the semantic elements will never have an effect on page rankings. In fact, it's almost ridiculous to think this would be the case.

Even if there were eventually some small benefit added to Google's ranking algorithm for the semantic tags, the difference would be so small that it probably wouldn't matter. Although we don't know, and probably will never know, how Google ranks pages, we do know that two of the most important factors are relevancy of content and quality backlinks. And that should never change. Trivial use of semantic tags should never affect SEO rankings, and they certainly don't do so as of this writing.

訳：

HTML5 はあなたのコンテンツの上位表示を助けてくれるのか？

今日、自分の Web ページに HTML5 の要素を使用したとしても、そのコンテンツが検索エンジンで上位に表示されることはありません。そして恐らくこの要素が表示順位に影響を与えることは決して無いだろうと想像します。実際にそんなことがあると考えることはばかげていると言ってもいいでしょう。

もし最終的に Google の検索順位決定アルゴリズムに HTML5 の新要素が多少プラスに働くとしても、その差はあまりにも小さくて大きな影響は与えないでしょう。Google がどのように Web ページの表示順位を決めているかは知らないし、今後も知ることはないと思いますが、検索順位に最も重要な 2つの要素はコンテンツの関連性と高品質な被リンクであることは重々承知しています。またこれが変わることはないでしょう。それに対して HTML5 の新要素の使用が大きな影響を与えるはずはなく、実際この記事を執筆している現時点でも、間違いなく効果は上げていません。

Is HTML5 Good for SEO? から引用

とまぁ手厳しいですが、これは HTML5 がどうこう以前から、当たり前のこととして言われていることではあります。で、続いてこの件に関する参考記事として Google Webmaster Central に投稿された下記の 2つの記事が紹介されます。

Although there may be some more up-to-date sources on this subject, here are a few relevant Google Webmaster Central posts that address this or related issues:

...中略...

The answers to each post are provided by Google employee John Mu, so unlike some of the overly-optimistic posts cited in the previous section, these are worthy of consideration.

You might also be interested in reading this article on HTML5 Doctor for further info on this subject.

訳：
この話題に関して書かれた Google Webmaster Central への投稿記事を挙げてみます。それぞれの投稿へは Google 社員の John Mu 氏により回答が寄せられています。最初に挙げたいくつかの記事に比べこれらは検討する価値があります。

また、HTML5 Doctor に掲載されているこの記事も興味深いかもしれません。

Is HTML5 Good for SEO? から引用

上で挙げた Google Webmaster Central への 2つの投稿は簡単に言えば、「HTML5 を Google のクローラーは正しく認識するの？」という質問ですが、それに対して Google の中の人は「HTML5 の要素をすべて正しく Google のクローラーが認識できるわけでもないし、どっちが有利とかはないから自分のところのコンテンツに適切だと思った HTML を使えよ」（超意訳）という回答をしています。

さらに、挙げられている HTML5 Doctor の記事は下記ですが、

HTML5 and Search Engine Optimisation (SEO) ： HTML5 Doctor

冒頭で下記のように書かれています。

Through our handy Ask The Doctor service, we get a lot of e-mails asking us about HTML5's effect on Search Engine Optimisation (SEO). While we can't answer in great detail (Messrs Google, Yahoo, Bing, and their friends haven't sent us in-depth details of their algorithms), we've rounded up some useful facts from Google, the world's most dominant search engine.

At the moment, Google indexes HTML5 microdata (more about microdata) but does not reward you for using the new HTML5 structural elements, but neither does it penalise you:

HTML5 and Search Engine Optimisation (SEO) から引用

後半の部分ですが、「現時点で、HTML5 の Microdata を使ったからといって特にプラスに働くこともないし、逆にマイナスになることもない」ということで、ここでも過度な期待はしないようにねという感じですね。

話を Impressive Webs の記事に戻しますが、

HTML5 Can Help Categorize Content

At this point, the only HTML5 technologies that can provide any SEO-related benefits are HTML5 Microdata or schema.org vocabularies (which are based on Microdata).

But even in this case, Microdata will not boost your SEO ranking; it will simply make specific parts of your content have more semantic value, making it easier for search results pages to compartmentalize and display your content to users. You can get more details on this subject on this schema.org FAQ. This concept is similar to Google's rich snippets, but schema.org seems to be a more powerful replacement for rich snippets.

訳：

HTML5 はコンテンツの分類を助けます。

現時点で、HTML5 の技術が SEO に関してメリットをもたらすとすれば、それは唯一、HTML5 Microdata または schema.org の語彙（これは Microdata をベースにしています）です。

しかし、この場合においても、Microdata はあなたの SEO ランクを押し上げてはくれません。単にあなたのコンテンツの特定部分に今以上にセマンティックな意味を持たせてコンテンツを分類し、より細分化された検索結果をユーザーに提供するだけです。本件に関しての詳細は schema.org の FAQ で見ることができます。このコンセプトは Google のリッチスニペットに似ていますが、schema.org はこれに代わるさらに強力なもののようです。

Is HTML5 Good for SEO? から引用

Microdata をうまく使えば、検索結果におけるコンテンツマッチの正確性を上げることはできそうですねと。これは検索ユーザーにとってはとてもいいことですが、言っていること自体は以前、XHTML で未来の検索はもっと便利になるよ。って言ってたころから変わっていないので、特に目新しくもないお話。そういう意味では HTML5 で正しく構造化された文書が増えることはいいことです。

ということで記事は結論へ。

Don't get too excited about any potential SEO benefits to using new semantic tags in HTML5. The fact is, a website built with HTML tables that has relevant content and quality backlinks will easily outrank any site structured with HTML5 semantics that has poor content and few backlinks.

So be realistic about HTML5's benefits. Semantic tags are not a magic bullet for higher Google rankings, and probably never will be.

HTML5 の新しいセマンティックな要素を使用することによる SEO 的なメリットに期待しすぎてはいけません。関連したコンテンツや高品質の被リンクを持つ table 要素で組まれた HTML ページの方が、コンテンツが貧弱な上、被リンクをほとんど持たない HTML5 で制作された Web サイトよりも上位に表示されるのが現実です。

HTML5 の恩恵に対して現実的になりましょう。セマンティックな要素は Google でより上位に表示されるための魔法ではないし、今後もそうなることはないでしょう。

Is HTML5 Good for SEO? から引用

ということで、最後に私なりにまとめますが、

SEO 的にどっちが有利ですか？なんていう質問で挙がってくるような項目は、検索結果の順位を決める上ではほんの上澄みくらいの価値しかないような部分がほとんどです。HTML5 がいいの？とか階層が深いとだめ？とかドメイン名がどうのとか... etc。そんなことを気にしている暇があったら、ユーザーの検索行動と自分のところのコンテンツ内容がきちんとマッチしているのかとか、内容的に多くの人が参照してくれるような内容なのか、さらにそれが多くの人の目につくためのプロモーションがされているのかなどに頭と時間を使った方がいいでしょう。

利用者のことを考えずに SEO に関する小手先の部分ばかりを気にするのは、スポーツで基本的なトレーニングもしていないのに「やる気」や「根性」があれば試合に勝てると考えるようなものです。メンタル面は最後のところでの差にはなるでしょうが、根本的な能力差を覆す程にはなりませんから。（話がちょっとずれましたが...）

HTML5 は単純な HTML のマークアップに関して言えば現時点で十分実用的ですし、ソースコードも簡素にできるし、策定中の仕様だというところだけ注意して使ってあげれば、Web サイト制作現場での採用メリットは大きいと思います。なのでフロントエンドの技術選定時に HTML5 を選択したら一番いいよねってことなら積極的に使ったらいいと思いますが、くれぐれも「SEO のためにもこれからは HTML5 ですよ。HTML5 で全部作り直さないと検索結果の順位が悪くなっちゃうよ」みたいな話にはならないようにお気をつけください。

ただし、これはまだ先の話かもしれませんが、Google さんなり、検索に関するデータ処理の技術がどんどん進化して、HTML5 + Microdata, RDFa ... （よりも進んだ技術が開発されているかもしれませんが）などで意味づけされた文書を正しく理解し、それによって検索結果をより正確に、利便性の高いものに変えていったとき、正しく要素が選択されマークアップされている HTML5 文書と、そうでない HTML5 文書でユーザーへのリーチ率が変わってくるなんてことになる可能性はあります。

また、その時、要素の選択肢が多い HTML5 の方が、文書への意味づけをより明確に行える分、旧来の HTML と比べて有利に働くこともあるかもしれませんし、逆に要素の選択肢が多いことで、間違ったマークアップをしてしまった結果、マイナスに作用するなんてこともなきにしもあらず...

HTML5 を選択するにしても、何となく HTML5 を選択するのではなく、正しく文書構造を作るということに注力しないといけないのは当たり前ですが、マークアップの質が検索結果に与える影響が今以上に大きくなるという可能性は今後長い目でみれば考えられますので、作る側としては気を付けないといけないかもしれませんね。

参考リンク

Google+ 「ページ」が公開。ページの作り方と注意点

2011-11-08T06:27:20Z

すでに色々なところで書かれてるので完全に乗り遅れた感はありますが、Google+ に追加された「ページ」機能で早速、会社とこの Blog のページを作ってみましたよ。

ということで、Google+ ページの作り方と、その時にやっておいた方がいい設定について簡単に解説してみます。

実際に作ったページは下記。

まずは Google+ ページに関して簡単に。Google オフィシャル Blog 等で案内されています。あと下記は YouTube の Google+ ページ、プロモーション用ビデオ。

「Google+ ページ」を開設するには、個人で Google+ のアカウントを作成したうえで、plus.google.com/pages/create にアクセスしてください。「Google+ ページ」はとても簡単に作ることができます。多くの方のご参加をお待ちしています。

「Google+ ページ」で、新しいつながりを： Google Japan Blog から引用

ということで、仕組み的には Facebook のページとほぼ同じですね。個人のアカウントに紐付いた形で、作成した「ページ」を管理できるようになります。

特徴的な機能としては Google 検索との連動でしょう。

Google 検索からのダイレクトコネクト

Google では 1 日に何十億回もの検索が行われていますが、多くの方は企業やブランドを探しています。本日から作成された「Google+ ページ」は、Google の検索結果に随時表示されます。

また、ダイレクトコネクトという新しい機能により、Google で検索するキーワードの先頭に「+」を付けるだけで、関連する「Google+ ページ」が表示されます。

...中略...

現在のところ、ダイレクトコネクトが機能するのは google.com での検索のみですが、近日中に google.co.jp でもお使いいただけるようになる予定です。また、現在は一部の企業やブランドのみ表示されますが、今後より多くのページに対応していきます。ダイレクトコネクトの詳細は、ヘルプセンターにてご確認いただけます。

「Google+ ページ」で、新しいつながりを： Google Japan Blog から引用

まだ、日本語版 Google 検索では機能していませんが、上記の通り、近日中に使用できるようになるようです。ちなみに、この「+」を使ったダイレクトコネクト提供の結果、今まであった「+」演算子は、検索キーワードを「二重引用符（"）」で囲む方法に変更されています。

Google+ ページの作り方

では早速作ってみますが、手順はとても簡単で、2，3分もあれば作れてしまいます。自分のアカウントで Google+ にログインし、「Google+ ページの作成画面」に進みます。まずはこれから作るページのカテゴリを選択しましょう。

ここでは会社のページを作った時の手順で説明しますので、「会社、機関、組織」を選択して次に進みます。例えば、Blog のページなら「その他」を選択すればいいと思います。すると、各情報を入れる画面になります。カテゴリで「会社」を選んでいると業種の選択が出ますが、その他だと出なかったり、カテゴリによって多少違うみたい。

次のページで簡単な説明（キャッチフレーズ）、プロフィール写真の登録が行えます。適当に。

次に進むと、今作ったページをメインのアカウント名義で共有できますが、ここは飛ばしても問題なし。あとでやる場合は「完了」を押して終わらせてしまいましょう。

これでページが作成され、初期画面に進みます。早速投稿することもできますが、先に 1つやっておくことがあります。

ダイレクトコネクトを機能させるために必要な設定

Google+ ページの特徴的な機能が Google 検索でそのサイトと Google+ ページを紐付けてくれる「ダイレクトコネクト（Google+ Direct Connect）」ですが、ただ Google+ ページを作っただけではこれが有効に働きません。そこで次の手順が必要です。まず、「ウェブサイトを接続」の部分から、「バッジを取得」に進みます。

「Google+ ページをサイトにリンク」というページがでますので、ここで表示されたコードを取得します。

バッジのサイズや使うか使わないかはご自由にですが、ダイレクトコネクトを有効にするには、下記の 2つの条件が必要です。

Web サイトから Google+ ページにリンクがされている
Google+ ページのプロフィールから Web サイトにリンクがされている

つまり、Google+ ページと Web サイトが相互リンクの状態になっている必要があるわけですね。Google+ からのリンクは、「プロフィール」の「基本情報」のところで Web サイトを登録する箇所がありますので、そこに URL を入れるだけ。逆に Web サイトからのリンクに関しては、上記で取得できるソースコードが参考になりますが、2つの方法があります。

1つ目は、head 要素内に link 要素を追加する方法。生成されたソースコードにもありますが、下記のような記述を追加します。

<!-- 次のタグをドキュメントの head 要素内に貼り付けてください-->
<link href="https://plus.google.com/[yourpageID]/" rel="publisher" />

もし、何らかの事情で head 要素内にソースコードを追加できない場合は、下記のように、a要素を使ってのリンクに「rel="publisher"」を指定する方法でも代替できるようです（Google+ ページヘルプ参照）。

<a rel="publisher" href="https://plus.google.com/[yourpageID]/">
 Google+
</a>

これで、ダイレクトコネクトが日本でも有効になった際には、Google 検索から Google+ ページを探し出してもらうことができるはず。

あとは、プロフィールに細かい情報を入れたりして Google+ ページを完成させたら、お知り合いに教えてサークルに追加してもらいましょう。Google+ ページはこちらから能動的に他の人をサークルに追加していくってことができないようになっています。とりあえず大量にサークル登録して、登録しかえしてもらうのを狙うちょっぴりスパム的な人集めができないようになっている点では良い仕組みなんじゃないですかね。

ちなみに、ページ作成後は、アカウントアイコンの下部のプルダウンから簡単に所有しているページに移動できますよ。

会社のページは弊社のような企業さんが相手の会社だとイマイチ使い道がわからなくて困るんですが、とりあえず作っただけで放置になりそうで反省。この Blog のページに関しては、以前から運用している Facebook ページと同様の運用になりそうですが、単に管理するページが増えて面倒な点も... 特に個人のアカウントと Blog での活動がほぼかぶってる場合はムリに Blog 専用のページとか作らなくてもいいかもしれませんね。

5分でわかる Facebook ページへのタブ追加

HTML5：ジャーナリスト、アナリストのための覚書

2011-09-28T05:17:25Z

ちょっといつもと趣が異なる記事として、HTML5 Doctor で「HTML5: briefing notes for journalists and analysts」という記事が上がっていましたのでまたまた稚拙ではありますが翻訳など。

今回の記事は、ジャーナリスト、アナリスト（つまり、あまり技術的な話に精通していない人）向けに、よくある質問とその答えをまとめたものです。技術者以外の人に「HTML5 って何？」って聞かれたときの参考になるかも。

原文
HTML5: briefing notes for journalists and analysts : HTML5 Doctor

HTML5とは何ですか？

あなたが何を求めるかによりますが... 「HTML5」という言葉には 3つの異なる用途があります。

HTML5 仕様

HTML5 の最も正確な意味は、W3C と WHATWG によって策定されている HTML5 の主要な仕様を指します。これは Web ページを記述する言語にとって待望の進化であり、Web アプリケーション（動的な対話型 Web ページ）を開発するために設計されています。1990年代後半から続く HTML5 の前身である HTML 4 は、Web ページのための言語でした（静的でハイパーリンクが張られたテキストドキュメント、画像、フォーム）。

重要な事実

HTML5 は、ブラウザ間で相互運用可能（クロスブラウザ）な Web ページを作るように設計されています。最近ではみんなが複数のブラウザを使用する（例えば、仕事ではIE、携帯電話で Safari や Opera、家では Firefox とか）ので、Web サイトが動かない環境があるってのは愚かだし迷惑です。
すべてのブラウザベンダ - Opera、Mozilla (Firefox)、Apple (Safari)、Microsoft (IE)、Google (Chrome) - が共同で作業しており、その他の組織や個人も協力してくれています（Netflix、Adobe、IBM、HP、BBC など）。
HTML5 は既存の Web ページを壊すことなく、Web の機能を拡張するために設計されています。
HTML5 は、Microsoft Silverlight や Adobe Flash のようなプラグインと競合しています。

HTML5 と仲間達

HTML5 のコア仕様に加えて、WHATWG は Web Workers、Web Sockets、Web Database のような他の規格も策定しました。これらは多くのアプリケーションやゲームで有用な機能です。（これらの規格の多くは、元々 HTML5 のコア仕様の一部でしたが、手続き上や、組織的な理由で分離されました。これらすべてを含む仕様のまとまりを「Web Applications 1.0」と呼びます。）

新しい、エキサイティングな Web テクノロジ

ほとんどの非開発者（または多くの知識に乏しい開発者）が「HTML5」と言う場合、非常に多くのテクノロジーを意味しており、HTML5 のコア仕様やその仲間とは無関係な技術のことを指します。位置情報、Device Orientation （訳者注：デバイスの物理的な向き、傾きや動きの情報）、タッチイベント、CSS Animations （とてもシンプルな Flash アニメーションの代替になる）、SVG （拡大してもギザギザにならない - ベクターグラフィックを描写する仕組み）や新参者の WebGL （ブラウザで 3D グラフィックスなどを表示するための仕様）など。

これら多くは W3C によって策定され、WebGL は Khronos Group によって管理されています。

多くの、いわゆる「HTML5 デモ」と呼ばれるものが HTML5 とは何も関係ないことに注意しなければなりません。例えば多くの「Google Doodles」（訳者注：Google がロゴでやるお遊び）は DHTML -前世紀から続く HTML 4 の技術- を使用しています。

どうしてHTML5が開発されたの？

HTML4 は新種のアプリケーションの狭間で悲鳴を上げていました（訳者注：つまり HTML 4 はもう限界だったってこと）。いくつかは HTML 4 だけでは解決できず、Adobe Flash や Microsoft Silverlight などを使用する必要がありました。その他についても、裏技的な Hack を駆使する必要があり、オーナーに利益をもたらすべき Web サイトの確固たる基盤ではありませんでした。

HTML5 に準拠したブラウザはどれくらいあるの？

「HTML5 への準拠」をどのように定義するかで答えは変わりますが、HTML5 は HTML 4 を拡張するものなので、ある意味ですべてのブラウザは HTML5 の機能をすでに備えています。

一方で、すべてのコア HTML5 仕様に準拠したブラウザを知りたければ、それは存在しません。現状のブラウザは、仕様全体（これは 700 ページ以上あります）の一部を実装していますが、すべてを実装したものはありません。

すべての誇大広告を無視してください。最新バージョンブラウザにおける実装レベルはほぼ同じです（各ブラウザが仕様を実装する時期や順番がユーザーのニーズによってずれていたとしても）。

誰が HTML5 を推進しているの？

HTML5 は 2004年に Opera で Ian Hickson 氏をエディターとしてスタートし、徐々に全ブラウザベンダも参加しました。Hickson 氏は Opera から Google に移り、仕様の策定を続けています。

ブラウザベンダが W3C や他の多くの組織や個人と共同して HTML5 の仕様を進めていくと言うことは最も公平な方法です。最終的に HTML5 の策定は Web 開発者のニーズによって進められています。

誰が HTML5 を使っているの？

多くの人々 - ハイテク企業だけでなく、Boston Globe Newspaper（訳者注：ボストン・グローブ紙）、Nationwide Building Society（訳者注：イギリス全国建築学会）、Yell.com （訳者注：電話帳）をはじめ多くの Web サイトが利用しています。 HTML5gallery.com は、多くの HTML5 を用いた Web サイトを紹介しています。

いつ HTML5 は準備が整うの？

おそらく 2012年。おそらく 2022年...でもそれは重要ではありません。重要なのは HTML5 仕様の多くが現在のブラウザに実装されていることで、それは現時点でも利用できるということです。

「HTML5 の策定が終わっていないから HTML5 を利用できない」と言うのは、「英語が完成していないから我々は英語を話すことができない」と言うようなものです。（訳者注：要するに細けぇことはいいんだよ。使いたいやつは今すぐ使え。ってことですね）

Internet Explorer では使えないんでしょ？

違うよ。IE9 は HTML5 をいい感じにサポートしています。一部の API に関しては JavaScript で polyfilling（訳者注：文末※1）と呼ばれる技法を使うか、Flash や Silverlight などのプラグインで代替できます。

<canvas> に関しても、IE8 以前のバージョンに対しては疑似的に再現できます。古いブラウザでは遅い JavaScript エンジンによって問題が起こるとこもありますが、ビデオ再生に関しては、古いバージョンのブラウザに対して Flash による代替処置をとることもできます。

HTML5 に含まれる機能の多くは、Microsoft によって生み出され、IE5 に実装されていたものです（contenteditable （訳者注：コンテンツの編集を可能にする属性）や Drag and Drop API など）。

HTML5は、単に携帯電話に関することなのですか？

とんでもない。HTML5 の設計に関する原理原則（Design Principles）の中でも「Universal Access」について述べています。

各機能は、誰もが同じように利用できる（ユニバーサルアクセス）よう設計する必要があります。... 各機能は可能な限り異なるプラットフォーム、デバイス、メディアで動作する必要があります。

ここではモバイルにとって有用ないくつかの機能があることも述べられています。もしあなたが "本物の" HTML5 を見ているなら、オフラインでも Web サイトの操作を可能にする「Application Cache ("Appcache") 」などは便利な機能の1つに挙げられます。

あなたが Adbe Flash を利用できないデバイス上で、HTML5 <canvas> を使用してアニメーションを実現できるという事実は有益だと思います。

「新しい、エキサイティングな Web テクノロジ」と定義した HTML5 （訳者注：上記「HTML5とは何ですか？」で触れた点です）においては、位置情報はとても重要な機能です。

HTML5 は Adobe Flash を殺すのか？

いいえ - またはそうでないことを願います。何年もの間、Web ページにビデオを掲載する手段は Flash だけでしたが、今は HTML5 があります。この競争が意味するのは、両方がより良いものになっていくということで、開発者にとっては喜ばしいことです。

Apple が iOS デバイスに Flash を搭載しないと決めたことで、HTML5 video が急速に広がりました。しかし重要なのは、iOS の HTML5 マルチメディアが完璧なプラットフォームとは言えないということです。

アダプティブビットレートストリーミングを使用するビデオやデジタル著作権管理（DRM）にとって、Flash は有用、かつクロスブラウザなツールであり続けるでしょう。

また、Flash は単純なビデオを扱うためだけのものでないことに気付く必要があります。簡単なゲームのようなものは HTML5 <canvas> に奪われてしまい、かつて Flash が使われていたような、ちょっとしたアニメーションの類（例えば何かがくるくる回る動作など）は CSS 3 に移行しました。しかし、ゲームやアニメのような洗練されたコンテンツの制作に利用しやすいのは Flash です。Adobe の制作環境は多数のツール（トゥイーンやタイムライン）がそろっているので制作者が作業しやすく、ビジュアル開発者にとっても使いやすいです。企業が <canvas> に適した制作環境を開発していくにつれ変わっていくかもしれませんが、今はそのような状態にはなっていません。

（Adobe は最近、「Adobe Edge」と呼ばれるタイムラインを中心とした Flash ではないアニメーション制作環境のプレビュー版を発表しました。しかしこれが HTML5 だという主張は無視します。現在は開発初期の状態で、ただ単に HTML 4 の <div> を JavaScript で動かしているだけです。）

HTML5 は携帯電話アプリを殺すのか？

HTML5 （もっとも広い意味においては "新しい、エキサイティングな Web テクノロジ"）が、Web の可能性を著しく高めています。2年前、GPS （Global Positioning System）に電話からアクセスするには、プラットフォームに応じて C++、Java 、.NET、Objective C でネイティブアプリケーションを書かないといけませんでした。今では利用者がアプリをダウンロードするかわりに URL にアクセスすることで、全てのプラットフォ―ムで JavaScript から位置情報データにアクセスできます。

オープンな Web テクノロジーによって、デバイスのカメラや Orientation （訳者注：縦横の向き）、システムのアドレス帳、peer-to-peer （P2P）のブラウザ内ビデオ会議、デバイスのファイルシステムなど多くのものにアクセスできるようになりました。

JavaScript エンジンはネイティブコードと同じくらい速くなり、最先端のスマートフォン向けネイティブアプリケーションとの技術上の差は存在するものの、徐々に少なくなってきています。高速な JavaScript や、フルブラウザを実行できないデバイスにおいては、ネイティブアプリは今でも重要です。

アプリには技術とは関係ない理由もあります。経営者がアプリを好むのは、販売網をコントロールすることができ、購入者と販売者の両方から料金を取ることができるからです。ところが一部の消費者は評価しているものの、多くの人は融通のきかないアプリストアやアプリ承認プロセスを嫌っています。アプリストアはキュレーションを提供しています。アプリは審査されていて、電話を壊したり、個人情報を盗んでいかがわしいサイトにばらまいたりすることはないと消費者は思っています。

特定のデバイスのためにつくられたアプリは、デバイス側で決めたユーザーインターフェイスやユーザーエクスペリエンスと高度に統合することが可能です。一部の人々はこれを魅力的な利点だと考えます。しかし、Web サイト制作者が Linux、Mac 、Windows 用にそれぞれ違うサイトを作るのではなく、1つしか作らないことから考えても、Web に移行することに大きな影響はないように見えます。

さらに踏み込んだ質問？

わからないことは俺（Bruce Lawson 氏）に聞け（訳者超意訳）

ということで、終わり。ちょっと言い回しが私には難しくて翻訳がおかしい部分もあるかもしれませんが、間違いがあったら指摘してください。

※1 polyfilling
いわゆる「Regressive Enhancement」という考え方ですね。最新の技術に対応している環境を前提にコードを書きつつ、未対応の環境には対しても同等の機能をあらゆる手段を用いて提供するという考え方。「Progressive Enhancement」も「Graceful Degradation」もどこかに線を引いてそれ以外には妥協してもらうっていうアプローチですけど、「Regressive Enhancement」はそこを気合いでエミュレートして差異をなくすっていうアプローチ。

参考リンク

HTML5 でやりがちな間違い（本記事と同様 HTML5 Doctor の記事を翻訳）

新著「逆引き HTML+CSS デザイン事典」が9月27日発売

2011-09-26T12:42:04Z

明日ですが、9月27日に新しい著書、「できるクリエイター逆引きHTML+CSSデザイン事典 Webクリエイターの現場で必要な基本と最新動向」がインプレスさんより発売されます。今回も CSS HappyLife の中の人と共著です。

今回の書籍は、主にWebサイト制作、初級～中級の人向け。タイトルの「逆引き」からもわかるように、「困ったこと」や「やりたいこと」からその解決策を逆引きできる感じの書籍になってます。頭から体系立てて学んでいくような書籍ではないので、手元に置いておいて、「あれどうすんだっけ？」という時に開いてもらえたらいいなっていう感じの内容と作りになっています。

...前段略...

本書は、そのような状況で、幅広い知識を求められる制作者の方々に向けて書かれた逆引き事典です。こういうときはどうしたらいいのだろう？と疑問に思ったときに、さっと開いて確認いただけるよう、制作の現場でよくある質問をジャンル別にまとめ、それぞれに解決策とわかりやすい解説を加えています。

解説は、これからHTML、CSSを学びたいとお考えの初心者の方々にもわかりやすく書かれており、同時に基本的な知識をお持ちの中級者の方々にも手元に置いて使っていただける実践的な内容にも触れています。

本書を制作の現場で日常的にご使用いただき、少しでも皆様の「困った」を解消するお役に立てれば幸いです。

できるクリエイター逆引きHTML+CSSデザイン事典 Webクリエイターの現場で必要な基本と最新動向 P3「はじめに」から一部引用

具体的な内容ですが、HTML、CSS を中心に、jQuery でちょっとした小技だとか、あとはサイト制作の現場で知っとくといいよっていうことなんかを全部で 309 個の Q&A 形式でまとめています。HTML や CSS は本当に基礎的なところから書いていますので、これから勉強するって人にも役に立つかも。また、CSS3 や HTML5 あたりにも後半で触れていますし、スマートフォン向けサイトの制作に関わる内容も同じく後半部分で書いています。

もし本屋さんなどで見かけた場合は、お手にとって頂ければ幸いです。

Amazon さんでは「なか見！検索」の対象になるらしいので、発売日以降、興味のある方は見てみてください。ここでもぼちぼち中身を紹介するかもしれません。

その他の著書（共著）

管理者権限不要の Google Chrome Frame が安定版に

2011-08-31T07:57:21Z

この Blog でも何度か取り上げていますが、Internet Explorer （IE）の中身だけ Google Chrome にしてしまおうというコンセプトで発表された「Google Chrome Frame」の管理者権限不要でインストール可能バージョンが安定版になりました。

Non-Admin Chrome Frame Reaches Stable Channel : Chromium Blog

過去にここで取り上げた記事も参考まで。上から新しい順です。

If you have installed the developer or beta channel version and wish to switch to the stable version, you'll need to uninstall Chrome Frame and then install via the above link. Note that the uninstall experience is smoothest if you close all Internet Explorer windows prior to uninstalling Chrome Frame.

In addition to Non-Admin Chrome Frame moving to the stable channel, we are rolling out a change to the default Chrome Frame installer; it will now run at Admin level by default and will fall back to Non-Admin mode if the user does not have the necessary permissions on their machine. This will allow all users to download a single installer that just works. This installer is available at the Chrome Frame download page.

Chromium Blog: Non-Admin Chrome Frame Reaches Stable Channel から引用

開発者バージョンが入ってるなら一度アンインストールしてから今回の安定版を入れてねっていうのと、インストーラの挙動としては、インストールしようとしたユーザーが管理者権限を持っている場合は通常版の Chrome Frame として。管理者権限がない場合は、管理者権限不要版（Non-Admin） Chrome Frame としてそれぞれ自動的にインストールされるよとのことです。単一のインストーラで、ユーザーの状況に応じて両方を自動的に振り分けてくれるわけですね。

以前の記事にも書いていますが、Google Chrome Frame の動作環境としては、Windows 7, Vista, XP（Service Pack 2）以降で動作する Internet Explorer 6 以降が対応します。

また、Chrome Frame はインストールされているだけだと勝手には動作せず普通の IE のままです。Web サイト側から Chrome Frame が入ってるならそっちでレンダリングしてねという指定をしてあげる場合は、下記の meta タグを Web ページに記述しておきます。

<meta http-equiv="X-UA-Compatible" content="chrome=1">

また、レジストリがいじれるなら（というかそれができるなら IE 以外のブラウザ入れろよって話ですけど）、下記のような値をレジストリにセットすることで、完全に IE の皮を被った Google Chrome にしてしまうことも可能です。

HKCU
  Software
    Google
      ChromeFrame
        IsDefaultRenderer  [0=All documents are by default rendered by the host browser (default).  1=All documents are rendered by GCF]

URL ごとにセットしたいなら「RenderInGcfUrls」を使って

HKCU
  Software
    Google
      ChromeFrame
        RenderInGcfUrls
          *google.com*      [string value name is the pattern to match, assigned value is not used]
          *yahoo.com/mail*  [use simple pattern, no regexp matching]
          *                 ['*' means load everything!]

とかしてあげればいいらしいです。詳しくは「Chrome Frame: Developer Guide」で説明されているので興味のある方は見ておくといいと思いますよ。

WWW WATCH

クリエイターの強い味方、レッドブルにシュガーフリーがでたよ

「いいね！」 スタンプを作ってみた

iPad / iPhone をテレビにするデジタル TV チューナー

製品の写真など

本体の設定、そして視聴

接続モードの設定

AP モード

スタンドアロンモード

ST モード

気になった点など

Flickr が IE7 と Firefox 3.6 をサポート対象外に

関連エントリー

広告枠販売はじめました

アメリカも IE6 シェア 1% サークルに仲間入り

関連リンク

Dropbox にファイルを置くと自動で色々な処理を実行してくれる Dropbox Automator

関連リンク

5分でわかる Tumblr の始め方 （2012年改訂版）

Tumblr をもっと便利に使う

Firefox を使え

アドオン ： Tombloo, AutoPagerize, Greasemonkey を入れる

Tombloo

AutoPagerize

Greasemonkey

ユーザースクリプト ： Tumblr Life を入れる

Tumblr Life

Google Chrome の場合

関連リンク

Fullscreen API を簡単に試してみた

Fullscreen の基本的な仕様

requestFullscreen()

exitFullscreen()

:fullscreen

:fullscreen-ancestor

fullscreenEnabled

fullscreen Element

セキュリティ関連

8 Security and Privacy Considerations

関連リンク

Google+ プロフィールバナー画像作成用 PNG ファイル

関連記事

HTML5 は SEO に有効なの？

Will HTML5 Help Your Content Rank Higher?

HTML5 はあなたのコンテンツの上位表示を助けてくれるのか？

HTML5 Can Help Categorize Content

HTML5 はコンテンツの分類を助けます。

参考リンク

Google+ 「ページ」 が公開。ページの作り方と注意点

Google+ ページの作り方

ダイレクトコネクトを機能させるために必要な設定

関連記事

HTML5： ジャーナリスト、アナリストのための覚書

HTML5とは何ですか？

HTML5 仕様

重要な事実

HTML5 と仲間達

新しい、エキサイティングな Web テクノロジ

どうしてHTML5が開発されたの？

HTML5 に準拠したブラウザはどれくらいあるの？

誰が HTML5 を推進しているの？

誰が HTML5 を使っているの？

いつ HTML5 は準備が整うの？

Internet Explorer では使えないんでしょ？

HTML5は、単に携帯電話に関することなのですか？

HTML5 は Adobe Flash を殺すのか？

HTML5 は携帯電話アプリを殺すのか？

さらに踏み込んだ質問？

参考リンク

新著 「逆引き HTML+CSS デザイン事典」 が9月27日発売

その他の著書 （共著）

管理者権限不要の Google Chrome Frame が安定版に

「いいね！」スタンプを作ってみた

5分でわかる Tumblr の始め方（2012年改訂版）

アドオン： Tombloo, AutoPagerize, Greasemonkey を入れる

ユーザースクリプト： Tumblr Life を入れる

Google+ 「ページ」が公開。ページの作り方と注意点

HTML5：ジャーナリスト、アナリストのための覚書

新著「逆引き HTML+CSS デザイン事典」が9月27日発売

その他の著書（共著）