longdesc属性が復活しそうなので思うところを書いてみた。その２ HTML5との関係な話
昨日のつづき。今日はHTML(5)とかその辺にlongdescがどう影響をあたえるかとか、実際の制作でどうなるんだろねーみたいなことをまたダラダラと考えてみようと思います。
HTMLの現状を含めて考えてみる
HTML5というか、広い意味でHTML。longdescによる画像の詳細説明というのがHTMLひいては将来のWeb関連技術にどう影響するか、ちょっと考えてみたい。
基本的にメジャーなブラウザでlongdescがサポートされたらWeb制作において画像のアクセシビリティを高めるための選択肢がひとつ増えることになる。これはHTML仕様がよりアクセシブルになったと言い換えてもいいことだと思う。
RIAやWebサイトを制作する上でも面白いことができるかもしれない。ここで深くは考えないけど、例えばlongdesc属性値のURLに非同期にアクセスして説明文を取得しておき、ユーザーの操作に応じてツールチップ的に表示するとか、UXを向上させる目的でも使えそうだ。
今どっかの会社がつくってるメガネでもしWebアプリが動いたら「OK glass, show description of this photo.」などと言うとメガネはlongdesc属性値のURLを辿って説明文を表示するとか。マシンリーダブルである。写真の表示時には説明文までダウンロードしなくていいし。低リソース環境のアプリにやさしい作りができるかもしれない。
まあそんなんマジメに検討できるようになるにはもうちょっと未来だろう。もうちょっと直近の影響についてはなんかないだろうか？うーん、たぶんalt属性値の考え方が少し変わるんじゃないかなと思う。たぶん。
HTML5におけるalt属性値の書き方については、HTML5: Techniques for providing useful text alternativesにまとめられ中である。現在はEditor's Draft。まだまだ長くなりそうだなーと思いつつ個人的に注視しているTRである。
例えばこの中の、3.2 Graphical representations: charts, diagrams, graphs, maps, illustrationsのExample2.1をみてみよう。現在では下記のようになっている。
ランプが動かなくなったときの対処法がフローチャート画像として提供されている。そのalt属性に「もしランプが動かなくなったら、まずプラグが入ってるか確認して、入っててもダメなら...なにがし」というふうにフローチャートの内容を説明した文章が設定されている。
HTML5におけるaltの使い方としては正しいんだけど、ちょっと文章長いよね？めんどいよね^^;と思える。こういうのはalt="ランプが動かなくなった場合の対処方法" としてlongdescに対処法を文章で説明したテキストへのリンクを指定するほうが無理がないように見える。
longdescがあるからaltではこういうふうに書かなくてよくなるというわけではなく、「詳細説明の代替テキストが長くなる場合はlongdesc属性を推奨するよ。altで書いてもいいけどね。」程度にこのExample2.1のパターンは補足されるといいんじゃないかと思います。
まあ、こんな単純なフローチャートだったらまだaltでいいけどね。並のアプリケーションのフローチャートを掲載したとして、それを文章にしたら本一冊くらいになると思う。それに絶対代替テキストが必要だ！というケースは（そんなケースないだろうけど）altが嫌がらせになるわなｗ
Web制作の現場的視点もからめて考えてみる
Dreamweaverのalt入れるテキストボックスそんなにデカくねーだろと。そのフローチャート画像がアップデートされたとして、またalt入れなおし？？。。。なんかそんなサイトメンテしたくなくなる。そういうときにlongdescを使ったら少しマシになるかもしれない。
まあ上記は半分ネタなんだけど、実際の制作現場で使えるなというケースもあると思う。例えば、大規模なWebサイト全体をアクセシブルにしようという場合。
多くのページに多数のグラフや図案などが掲載されているとして、それらの詳細説明の代替テキストを提供する場合に、なるべく既存のソースコードをいじりたくない。つーか今の表示をまったく変えずにしてほしい。つーか融通の利かないCMSだからややこしいす。というあるある話はけっこうよくあるあるだろう。
その時に代替テキストを別ページとして用意し、元ページのimg要素にlongdesc属性をつけて代替テキストページにリンクする。こうすることで元ページの視覚的な表示に難の変更も加えることなく画像の代替テキストに関する達成基準を満たすことができる。
別ページで用意する代替テキストの作成作業は、元ページの更新作業と非同期にできるので、人海戦術で作業効率が上がる可能性がある。今までの経験も含めて考えると、大規模公共系サイトにはハマるパターンだと思う。
官公庁とか政令市級の公共サイトとか、longdescが普及すると受ける恩恵はけっこうあるんじゃなかろうか。とも思えてくる。
もちろん公共だけじゃなくて一般的なWebサイトでも代替テキストを適切に提供することはいいことだ。HTML5は旧バージョンに比べて各要素の意味がしっかりと規定されてよりセマンティックなマークアップが実現できるようになった。
セマンティックなマークアップはマシンリーダブルなサイトを実現する。マシンリーダブルとはウェブブラウザ、検索エンジンなどのソフトウェア機械がページの情報をより正確に理解できる。ということだ。
機械がウェブ上の情報を理解する。そこから今よりももっと便利ですばらしいサービスが生まれる可能性がある。セマンティックに記述されたページは、将来生まれるであろう付加価値の高いサービスの中で、より上質なデータとしてその価値を発揮することができるのである。
HTML5でのマシンリーダブルなマークアップは現在でもスクリーンリーダーをはじめとする支援技術が追従していっている。つまり、よりよいマークアップが実質的に目の不自由な障害者などへの情報提供に実質的に貢献するようになってきていると言っていい。
このlongdescやその他HTML5のセマンティックな機能は、ウェブアクセシビリティを向上させるとともにマシンリーダブルを実現するというわけだ。その点でもこれからのウェブ制作者が理解して制作で実践していく意義は大きいと思える。
障害のある方々に微笑んでもらえるかどうかはマークアップエンジニアの腕次第だ！
と、ちょっと大げさに言っておこうかｗ
ウェブ制作者としての雑感
長文書いて疲れたしけどもう少しｗ
HTML Image Description Extensionにおいて、longdesc属性は今のところ次のように紹介されている。
マシンリーダブルであり、アクセシブルな機能だと言えると思う。
longdesc属性が復活しそうなので思うところを書いてみた。その１ ウェブアクセシビリティな話
白石さんのおなじみのスレでも紹介されているとおり、HTML Image Description ExtensionがW3CのWorking Draftとして公開された。現時点の仕様をみるかぎりではlongdesc属性を復活させるという内容のようだ。
これはちょっとWebアクセシビリティ的に興味があるので思うところを書いておくことにする。
longdesc属性とは？
使ったことない人も多いんじゃないかと思う。つーか知らない人もけっこういるかも、ボクも実際仕事では一度もマークアップしたことがない。longdesc属性はHTML4.01でサポートされていて、画像の詳細な説明を記載した文章へのリンクを示すものである。値にはURLを設定する。
画像を説明するための代替テキストとしてはalt属性を使うのが一般的だけど、説明がすごく長くなるような場合、別の文章を用意して、そのリンクをlongdesc属性に設定するというふうに使う。
longdesc属性を適切に解釈するユーザーエージェントでは、画像の説明文が必要なときに、何か操作するとlongdesc属性のリンク先から文章を取得して参照できる。といったことが期待されるわけだ。
しかしこのlongdesc属性、ほとんどのブラウザが実装していなかった。また、実装しているブラウザはあっても、それを有効活用しているケースがほとんど見られなかったようだ。たぶんそういう理由でHTML5では当初採用されなかったんだろう。
しかしHTML5の大方の仕様が安定して、アクセシビリティについて考える余裕ができて、改めて考えたらあってもいいんじゃね？となって上記WDが公開された。ざっくり運びなんじゃないかなと想像しています。
Firefoxにおけるlongdesc属性の実装
上記白石さんのスレでは矢倉さんがOpera(Presto)も実装してるよってレスをつけていらっしゃる。さすがだよこの人HTMLで知らないことってあるんだろうかまじで。恐れ多くも過去2回、おおやけで対談させていただいたことがあるけどほんとすげえ人です。
ボクはメインブラウザのFirefoxでlongdesc属性がちゃんと解釈されているかをみてみることにする。チェックするサイトはH45: longdesc 属性を用いるのテストファイルにする。確認したFirefoxはバージョン19.0.2。
これはWCAG2.0の実装法のひとつH45: longdesc属性を用いる に対応するテストケースだ。サイトにはグラフの画像がひとつあって、longdesc属性が以下のように設定されている。
これはH45-ref1.htmlに詳細な説明があるようだ。アクセスしてみるとたしかにグラフの内容が文章で説明されている。これをalt属性に設定するとなると、、、うーんたしかにちょっと長くてイヤな感じかな。
さて、このlongdescをFirefoxは解釈しているか？画像を右クリックして、画像の情報を表示 を選択してみる。
すると以下のように画像に関する情報を表示するダイアログが現れる。
赤線の箇所、「詳細説明」という行にlongdesc属性が指定されている。Firefoxはlongdesc属性を認識しているようだ。
次に、画像を非表示にしてページをリロードしてみる。結果は下記のようになった。
グラフの画像が非表示になり、alt属性に設定されている「会員数の遷移グラフ」というテキストが現れた。特にlongdesc属性の設定値は表示されないようだ。個人的にはここに詳細説明へのリンクボタンでも表示されたら親切なんじゃないかなと思うけど、そのへんはどう考えられているのかな？
ちなみに、FirefoxのアドオンにLongdescというのがある。名前そのまんまなんだけど、これを入れると右クリックしたときのコンテキストメニューに、longdesc属性値のURLにとぶボタンを表示してくれる。
こんな感じで画像を右クリックすると「View Image Longdesc: ....」というメニューが表示されて、クリックするとリンクに飛ぶことができる。
Firefoxの標準機能じゃないけど、これを使ったらlongdescの意義も多少みえる気がしますね。Chromeにも同じようなエクステンションがありました。
WAガイドラインからlongdesc属性をどうみるか？
Web Accessibility（長いのでWA）的にlongdesc属性はどう見たらいいか？
以下、個人的な見解です。と前置きした上で書いておく。
WCAG2.0を眺めると、以前Webフォントのことで書いたとおり、ざっくり「テキストデータは最強アクセシブルじゃね？」的な考え方を読み取ることができる。img属性で画像を掲載する際は、alt属性値で説明するとか、画像のすぐそばに画像の説明文を記載するなどしてスクリーンリーダー等が読み上げられるようにするのが良いとされる。
WCAG2.0の実装方法として、前者はH37： img 要素の alt 属性を用いる、後者については、以下が該当するとかんがえられる。
G73: 非テキストコンテンツのすぐ隣に別の場所へのリンクを置き、その別の場所で長い説明を提供する
G74: 短い説明の中で長い説明のある場所を示して、非テキストコンテンツの近くにあるテキストで長い説明を提供する
G92: 非テキストコンテンツに対して、それと同じ目的を果たし、同じ情報を提供する長い説明を提供する
G94: 非テキストコンテンツに対して、それと同じ目的を果たし、同じ情報を提供する、簡潔な代替テキストを提供する
上記のように複数の方法がある。実装経験から言うと、どれでも選べばいいという感じじゃなくて、コンテンツに応じて一番適したものを選択するのがいいと思ってる。
例えば、風景写真を掲載して、そのすぐ横に風景描写を詳細に説明した記事があるコンテンツの場合は、G73適合とみなす。画像のみで近くに説明を書きたくないレイアウトの場合はH37に応じてalt属性値を書く。といった感覚だ。
上記の他にWCAGにはlongdesc属性をつかった実装方法がある。
H45: longdesc属性を用いる
がそれだ。
しかし、日本のWAガイドラインJIS X8341-3:2010を策定しているウェブアクセシビリティ基盤委員会はこのH45について達成不可能という見解を示している。現時点でブラウザやスクリーンリーダーがlongdescをほとんどサポートしていないというのが理由だ。
このページには現在、2012年5月のテスト結果が記載されている。その結果をみるとスクリーンリーダーのJAWS 9.0 for Windows、ホームページリーダー3.04がlongdescの存在を読み上げるということらしい。UAのlongdesc対応が普及してないからH45は事実上達成不能という見解だ。
ごもっとも。いくら仕様があっても実装がなければユーザーが使えない。使えないものが達成基準には成り得ない。上記のFirefoxで検証したように詳細説明にアクセスできないんだったらlongdesc使ったからアクセシブルになったって言えないよね？ということだ。
こういうわけで、Web制作者の観点ではlongdesc属性を使っても意味がない、だから使わなくていいという感覚だったんだけど、このWDが公開されてHTML5でもlongdescがサポートされるかもとなると、ちょっと考え方を改めないといけないかなと思うわけです。
勧告される頃には全てのブラウザ（UA）が実装するだろうから。
あと、longdescが普及するとWAICのH45に対する見解も変更されると考えられるから。
、、、とまあlongdesc属性という現役のころも絶滅危惧種で、滅んだと思ったら虫の息を吹き返した超マイナー属性でも、書こうと思ったら意外と長くなるもんでした。我ながらびっくり。
まだ書きたいことはあるんだけど、ダラダラしすぎてもアレなんで残りはまた明日書こうと思います。
YeomanでAngularJSしてCoffeeScriptにしてみた。っていうかGrunt最強って話
JavaScript FrameworkならBackboneでしょ。
と勝手に思い込んでそればっか使ってきたボクですが、年初にheavenshellとかどっぺちゃんとで飲んだ時にviewが重くなるよね―とか話してたしかにそれ悩みだよなと思った。
そんときAngularJSってどうなんだろうねーって話にちょっとなって、そんときからangularいつかやってみようと思いつつ仕事で忙殺されてたんだけど、今日何気にSNSで「AngularJSに仮入信してみる」ってつぶやいたらGoogleの人にいいね！してもらってちょっと上がった。
さらに都合のいいことに外出で2時間程度電車に乗ってヒマな時間ができたので、車中でAngularの洗礼を受けてみようとPCを開いた次第。ちなみに途中で酔いました。以前新幹線で思い知ったのだけど懲りてなかった。電車でコーディングは控えましょう。特に自分。
さて、AngularJS。Google製JavaScript Frameworkである。どんなものかというのはググればいいので省略するとして、ボクがangular気になってる点というのはDIパターンを採用している点。クラス間の依存性が疎になるほうがコード量が増えていってもテストしやすくなるんじゃね？と。
Backboneだと依存性強く書けちゃうので、メンテナンスしていくとどうしてもそうなって、特にViewにしわ寄せがいってテストとか書きづらくなる。まあ自分の実力不足もあるんだろうけど、そういう傾向あるねって年初の会でも話題になってた。まあそういうのをangularなら小マシになるかもなと期待してやってみるわけです。
まあいっぺん書いてみようと。angularはまったく知らないので本家のチュートリアル見ながらイチからです。しかし本家からzipをダウンロードはしない。最近は何をつくるにもyeomanから始めることになっているのでyeomanからangularのプロジェクトを作成する。
$ yeoman init angular
こっから勉強していくことにした。ちょいとチュートリアルとはファイル構成が違うけど、まあわかるからいいや。つーかyeoman便利。
yeomanが吐いてくれるJSは app/scripts/app.js と app/scripts/controllers/main.js。app.jsをルーターにしてcontrollers/以下にコントローラーを置いていく感じ。index.htmlではapp.js, main.jsの順に読み込んでる。OKこれをcoffeeに訳す。 app.coffeeとmain.coffeeはこんな感じにした。
あとはこのまま yeoman server で完成！と思ったらそうはいかない。他のframeworkよろしくangulerもオブジェクトを各クラス間で使いまわす。しかしCoffeeScriptはコンパイル時にデフォルトでファイルごとのソースを匿名関数でラッピング（即時関数っていうんだっけ？）する。
上記のソースの場合、app.coffeeで生成した angulerApp を main.coffeeで呼び出してcontrollerを登録しているのだけど、このままコンパイルすると出力されるapp.js と main.jsとでは名前空間が異なるので、main.jsでangulerAppなんてないよ、とエラーになるわけである。
coffeescriptで複数のファイルでアプリを書く、例えば1クラス1ファイルみたいにするとすごくキレイに書けるんだけど、コンパイル時に上記のようになるのでそのままじゃ動かない。こういうときどうするかというと、coffeeコマンドで --join オプションを使って各ファイルを結合したり、 --bare オプションで即時関数化を無効化して各ファイルをグローバルで動くようにする。どちらを選ぶかはケースによって判断するのがいい。
yeomanではcoffeeのコンパイルをGruntに一任している。Gruntのcoffeeプラグインをみてみると、bareオプションが使えるみたいなので、yeoman angulerではbareでコンパイルするのが効率良さそうだ。ということで、プロジェクト直下のGruntfile.jsを以下のようにする。
29〜32行目にoptionsブロックを追加し、bareをtrueに設定。これでcoffeeのコンパイル時にグローバルなjsを吐いてくれるようになる。これで yeoman serverを実行すると正常にアプリケーションが起動する。
実はボクはこのときまでGruntでbareオプションが設定できるのを知らなくて、今までGruntで複数ファイルを連結するときはconcatで連結してからコンパイルという設定をやってきた。こんなふうに。これはこれでアリなんだけど、ファイルが増えるたびにGruntfileを更新しないといけなくてもっといい方法ないかなーと思ってたら上記のようなカンタンな方法があったわけですね。ドキュメント読まな。。orz
まあ何はともあれyeoman angulerでも気持よくcoffeeで書けそうになったのでちょっとAngulerJSを勉強してみますわ―という本日からしばらくになりそうです。つーかいつも思うけどGrunt便利すぎ最強。
地味だけど強力なWebフォントのお話。まだ日本のWebデザインで普及してないから書いとく
今日SNSでつぶやいたネタを少し広げて書いておこうと思う。
Webフォントサービス「フォントプラス」を電通レイザーフィッシュが採用
興味深い採用事例。サイト運用コスト軽減のためWebフォントを使う。たしかに大規模なコーポレートサイトの場合効果があるかもしれない。結果が知りたいところ。
と言ったら、MJの例の人が「画像つくる手間なくなるのいいからウチでもつかってるよ。」的なレスくれたりして、なるほどなーと思った。
WebFont。CSS Font Module Level 3でCSSによる仕様がまとめられている。まあ日本ではまだ活用事例が少ない地味なHTML5関連の技術である。
すごく簡単に言うと、どんなフォントでも使えるようになるって機能。Web上にフォントを置いておいて、Webサイトを表示するときにそのフォントを使うことでコンピュータの中にないフォントでもWebサイトで利用できるということ。
今までのWeb制作ではどんなPCでも入っているフォント、MSゴシック系やメイリオ系のみを使うのが常識だった。でもWebFontのおかげで今はモダンブラウザならどんなフォントでも使えるようになってる。これはWeb制作的に常識が覆る出来事なんだけども、地味だよね。イマイチ話題にのぼらない。
海外ではかなーりWebFontを使ったサイトが増えてきているんだけど、日本はまだ希少。原因はいくつか予想できるんだけど、それは最後に書くとしてWebFontのメリットについて書いておこうと思う。
まず1番目、冒頭にあるように制作コストが軽減できるというメリットがある。
主に装飾目的での画像文字をWebFontに置き換えることで作業コストを抑えられるシーンがある。文章中の作品名だけはこのフォントでお願いね～って依頼にイチイチPhotoShopでテキストのカーニングに合わせたそれっぽい画像文字つくってとかしなくてよくなる。
でも旅館のトップバナーとか写真に装飾文字かぶせるってパターンだとPhotoShopでやったほうがはやくね？という意見もあるかもしれないけど、画像にWebFontかぶせたほうが<div style="text-indent: -9999px; background-image: url(hoge.png);">ようこそ◯◯へ</div>みたいなことしなくていいから便利じゃね？と逆に思う。
あと、RWDを意識するとWebFontは有利だなと思う。WebFontはベクターデータなので様々な画面サイズで表示される際にもキレイに表示される。対して画像文字だと解像度に合わせたものを用意しないとキレイに見えないし、スマートデバイスなどでズームしたときに対応しない。
さらにRetina対応なんかも気にしなくていい。将来Retinaの倍の解像度がでてきたって大丈夫。だってベクターデータだから。解像度非依存ってのは将来のお客さんのクレームもつぶしてくれるほんと素晴らしいもんだと思います。
まーでもGUIツールでWeb制作しているデザイナさんなんかはコーディングでオフセット位置キメたりするよりフォトショでやったほうがラクだよねーと言いそう。ごもっとも。ボクのようにテキストエディタでWebコンテンツを作っているビンボープログラマーにもやったことないけど理解はできる。
しかしオンブラウザ・デザインというのも流行ってきているというし、Adobe Edge Reflowなんかが本格的に使われるようになると、WebFontを画像の上にドラッグして位置キメるとか普通になるんじゃないかな。そのへんでフォトショでバナーつくるの古くね？みたいになるような気がする。
そう考えるとAdbe Edgeみたいな次世代の制作ツールが早く普及したほうがいい気がしてきた。みなさん頑張って勉強してください。ボクはあいかわらずテキストエディタでいきます。
さて2番目、WebFontはアクセシビリティに貢献する。思えば1年前某Webフォント業界の方にそんな話をして意気投合したもんだ。ずっとこの考えは持ってたんだけどよく考えたらプレゼンやったことないな。WebFont話してって言われないもんなｗ
JIS X8341-3:2010、WCAG2.0など、Webアクセシビリティのガイドラインでは基本的な考えとして、画像化された文字を推奨しない。画像化文字はアクセシブルではないという判断だ。まあ画像データはそのままじゃスクリーンリーダーは読みあげてくれないし当たり前かもしれない。
WCAG2.0の達成基準1.4.5では「画像化された文字」についての基準がある。この達成基準は日本のWebアクセシビリティガイドラインであるJIS X8341-3:2010にも継承されているため公共サイトなどでよく実施される適合試験をクリアするためには対応する実装が必要になる。
基準をクリアできる実装としてはC30: CSSを用いて、テキストを画像化された文字に置き換え、変換するユーザーインタフェースコントロールを提供するなどがある。C30の実装パターンはいくつか考えられるんだけど、上にも書いた<div style="text-indent: -9999px; background-image: url(hoge.png);">ようこそ◯◯へ</div>みたいなよくあるコーディングがこれに該当する。
画像データの中に書いてある文字をマークアップすることで画像文字の代替テキストを提供する。これによってスクリーンリーダーはマークアップされた文字を読むことができる。目の不自由な人にも情報が提供できるってわけだ。
Webのデータの中で最もアクセシブルなデータはテキストだ。Webアクセシビリティを勉強していってると何気に「テキストデータ最強」みたいな傾向を見て取ることができる。フォントというのはテキストデータを表示するためのもので、WebFontはあらゆるデザインフォントをWebコンテンツ中で利用するための仕様だ。
できるだけデータをテキストとして提供することがWebアクセシビリティに貢献することにつながる。デザインとアクセシビリティとの調和をWebFontが実現する。
今でもたまーに「アクセシビリティを意識するとダサいWebデザインしかできない」という意見を見ることがあるが、そんな人はミツエーさんのサイトとかをみて同じ事が言えるかもう一度考えてみてほしい。考えてから自分の勉強不足を猛省してほしいもんだ。
さて、もっと考えたら他にもいろいろ出てくるだろうけど、WebFontを使うメリットは現在のWeb制作の中にもある。単にCSS3で新しいとかいうだけじゃない。本質的に大事な要素があるわけ。しかし日本ではまだまだ普及してないですね。
普及してない理由を考えてみると、まず日本語フォントのクラウドサービスが有料だというのがある気がする。上記記事のフォントプラスもモリサワのTypeSquareも基本的に有料サービス。お金がかかるってことで個人運営のWebサイトでは使いづらいというのがあるだろう。
日本語のデザインフォントもフリーなものがあるけど、モトヤやモリサワには及ばないし、第2水準くらいまでしか収録されてないというのもあって汎用的に使うのはちょっと辛いというのもあるだろう。
欧文だとGoogle Webfontsとか無料で十分実用に耐えるサービスがあるけど、日本語フォントは事情が違う。なんで日本語は無料じゃないんだよ、無料にしろよ！と。そうなんだけど日本語フォントってのは欧文に比べて製作コストがハンパなく高いので無料にしにくいんだと思う。難しいところだ。
欧文に比べて日本語フォントはデータが大きくて重い。というのも一因な気がする。日本語WebFontが重いからダウンロードに時間がかかる。これがクライアントのストレスになるというケースが既に発生しているようだ。
現行のモダンブラウザの中にはWebサイトのレンダリングが完了し、WebFontのダウンロードが未完了な場合、まずそのブラウザの標準フォントでテキストを表示するものがある。その後WebFontダウンロードが完了すると、そのWebFontでテキストを再描画する。
この場合、素人目に見るとWebサイトがなにか変な動きをしているような違和感があるので「なんとかなんないの？」と言われるわけである。言われてもどうすることもできない。そのブラウザの仕様だから。今のところそれを制御するような仕組みは用意されていない。
今、Firefox19でみるかぎりではテキストはWebFontのダウンロードが完了してから表示されているように見える。その辺のブラウザ仕様もいろいろ考えられてるっぽい。これは少しいい動きなんだけど、それでもテキスト以外のCSSや画像は表示されていて、文字だけ表示されないタイミングがあるのでなんか微妙ではある。
できればWebFontのダウンロードが完了して、レンダリングが全て正常に完了した時点でWebサイトをパッと表示したい。それまではプログレスバーで。という実装をしたいと思える。そのために先日CSS Font Load Events Module Level 3がEditor's Draftとして公開された。
これによると document.fontloader.onloadingdone イベントが聴けるようになる。それを元にいろんな処理ができるので上に書いたフォントダウンロード完了でパッと表示みたいなこともできそうだ。欧文フォントみたいに字数が少なくて軽いデータには大していらないかもしれないけど、日本語みたいな重いデータでは重宝しそうだ。この仕様、すぐWD Lastcallあたりまでは行きそうな気がする。
以上、日本語フォントの特性もあってまだ日本では活用シーンが限られている。というのがWebFontの現状かもしれない。しかし環境は整いつつある。メリットは書いたとおりいろいろある。
Webデザインを手がける方々はそろそろ使ってみるのもいいと思います。Webデザインはその誕生から現在に至るまで、テキストの装飾というノウハウをほとんど蓄積していなかったのだから。
IE10 for Windows7が出たのはHTML5的にいいことだと思うのでつぶやいてみる
IE10 for Windows7ついに出ましたね。もうちょっとかかるかなと思ってたけど意外と早かった。しかしこれも意外なことにたいしてニュースになってなかったので、ちょっとつぶやいてみる。今日は他のこと書く予定だったけどまあいいや。
今日現在ではまだまだWindows8のシェアはまだまだ伸びてなくて、世の中のPCの多くではWindows7が稼働している。現在販売されている新製品のPCにもWindows7プリインストールが多いですね。
Windows7のデフォルトブラウザはIE9だった。IE9はHTML5ブラウザ戦争中にリリースされたバージョンだけど保守的にHTML5をキャッチアップしていてHTML5TESTでは138点と低スコアである。なんとFirefox3.6より低い。現行のFirefox19なんて393点だぜ。
RIA開発においてもIE9へのアプローチは実際躊躇していた。まあモバイルファーストな案件ではけっこう外されることもあるのだけど、D&DとかStorage、WebSocketなんかが使えないのがイタくて、設計時にその辺をIE9でどうするかとか考えるのが軽く手間だったりした。「IE9だけができない。」そういうのがストレスになってたわけです。
しかし、IE10 for Windows7の登場で一応設計時点で「Win7もIE10だから大丈夫でしょ」みたいな選択肢ができた。これはありがたい。なのでHTML5 RIA開発においてはけっこう喜ばしいニュースだと思ってるんだけど、プレスでもツイートでもそんな意見を今んところ見ない。あんまり見ないので自分がなんか間違ってるのかな？と思ってきた。
なのでブログでテキトーにつぶやいてみるテストをしてみたわけですｗ
だってすごくね？320点だよIE10。9の倍以上つけてる。D&DもIndexedDBもWebSocketも使える（がっつりやったことないけど）IE10がリリースされて「やっと全てのメジャーWebブラウザでHTML5が使える！と言えるようになったな」と思ったのを今更思い出す。
でも、IE10が未だ普及していないWindows8でしか動かなかったので、現実案件で「IEも大丈夫」という気持ちにはなれなかった。しかしここにきてWin7版の登場。やっと大丈夫と発言していい状況になるなあという気持ちがある。
もうねMSさん。Win7ではIE10強制アップデートかけちゃっていいですよ。いっきにIE10のシェアグラフ上げてくださいよ。もう「Winodws」って7と8って世の中になってるじゃあないですか。XPはもう終わるしVistaとかなかったことにしていいんで。
左がmodern.ieで提供されているIE9 for Win7の仮想マシンにIE10をインストールしてみたもの、右がWindows8のIE10。ほらおんなじじゃないですか。これってHTML5開発ではすごくうれしいことじゃね？ちがうのかな？ボクだけかな？
まあいいや。ボクはうれしいです。
あと、最近IEのネタばっかり書いてるみたいだけど、別にMSさんの回し者じゃあないですよｗ 他のブラウザもウォッチしてます。メインブラウザはVimperatorだし。そもそもMacだし。
※追記（公開5分後）
「IE10 for Win7リリース。HTML5アプリケーションの普及牽引が期待される」みたいなニュースで盛り上がると、ほんと思ってたんだけどそうじゃなかったですね。みんなChromeとか使ってるから今更感なんでしょうか？
でも、他ブラウザのインストールを許可されない大企業なんかの制限されたPC環境ではやはりインパクトがでかいと思うんです。今の大企業なんかまだWin8なんか使ってないし、現行稼働中のWin7上のプリインストールブラウザでHTML5がパワーアップするというのは大きいと思うわけです。うん、やっぱエンタープライズでのHTML5 RIA普及のトリガとして使えるいいネタだと思います。IE10 for Win7のリリースは。
以上、ちょっと書き忘れていたので追記。
Google GlassとWinApp UIから将来のWeb UIを妄想してみる。
Google Glass。話題になってますね。デバイス的にはスマートフォン登場以来のInterest Deviceって感じでしょうか。これが本当にオシャレなのかどうかは別として、こういうデバイスが一般的になれば情報関係で便利になりそうな気はします。
2年前に来年のGoogleの発表を妄想するというネタスライドで「次はメガネに違いないわ！」みたいなことをほざいたら本当にメガネが出たのであーやっぱりそっちかーと思った。
グーグルは人間の行動データを上手に取得してビジネスにしている企業なのでより生活中で使用頻度の高いものをデバイス化して普及させることにはメリットがある。それで今まで取れなかったデータも取れるようになるから。
且つ生命に関わるような用途でないこと。そう考えるとメガネは一番適当だとスライドをつくった当時に思ったんです。ほぼネタの発表だったけど、結構まじめに考えていたわけですじつはｗ
まあそれは置いといて、発表されたGoogle Glass。面白いデバイスだと思うしハードの仕組みとかも気になるんだけど、それは対して興味がなくて他に強い興味がある。UIである。Google GlassでWebページ表示したらどうなるか？そんなことばっかり考えるのである。
アプリケーションはレンズの中で表示される。それはつまりユーザーインターフェースは自分の視界の面積以内に固定される必要がある。キーボードやポインティングデバイスのような入力装置もなさそうなのでスクロールやページ切り替えなどの操作も容易ではない。そんな中で例えばWebコンテンツなんかはどうやって表示するんだろうか？
メガネのディスプレイ（レンズ部）はスマートフォンの画面よりも制約がきつい。今言われているRWD（レスポンシブ・ウェブデザイン）なんかが宜しく対応してくれるんだろうか？
当然、マルチウィンドウを採用してウィンドウ内に従来のWebブラウザを表示してスクロールなりページングなりをするという方法はある。しかしまあ非常に操作が煩雑になるんじゃないだろうか。操作は音声で？
そんなんでニュースフィードを読むくらいならタブレットで読んだほうがはやいと思う。ナンセンス。ジェスチャーでポインティング操作？操作の手間は音声と変わらないんじゃないの？やはりナンセンスと思う。
下記はGoogle Glassをかけてる人の視界。飛行機に乗り遅れそうで急いで走っているっぽい。こちらのビデオの1:30あたりから。
右上にフライトのインフォメーションが表示されている。必要な情報が端的に、視界を遮らない形で提供されている。情報の優先度や重要度はアイコンやフォントのスタイルや大きさで表現されていて必要最低限。
無駄がなく直感的に把握できるよう設計されているっぽい。こういうUIで非常に大事なのは視界を遮らないこと。このインフォメーションがフルスクリーンで表示されるのはユーザーを危険に晒すことになる。
視界を遮らない程度の表示であっても、集中しないと読めないような情報量だったり複雑なレイアウトだあってもやっぱり危険だ。この手の情報表示というのは駅の掲示板、オーディオ機器のパネルなどで日常的に何気なく目にするデザインなのだけど、極めて洗練されたマイナスのアートワークであると言える。
これはこれで出発時刻ギリギリなんで急がないと！ということが判って便利なのだけど、ターミナルは？出発ゲートは何番？など目的地にたどり着くための情報がいくつか足りない。しかし、それらを詳しく表示すると視界が狭くなるし直感的に情報が取得しづらくなる。
「もっと見る」ボタンをつける？手は荷物でいっぱいだし、走っているから音声コマンドもままならない。ナンセンス。こういうスマフォ見る手間も惜しいようなシーンでGlassの本領は発揮されるべきですね。
じゃあどういうUIがよいのか？このビデオを進めるとひとつの回答が出てくる。このシーンから以後2～3秒間なので一瞬のことなんだけど。右上のインフォメーションは以下のようになる。
スキップアップなアニメーションで情報が切り替わった。出発時刻、ターミナル、ゲートの情報が表示される。おそらくは数秒感覚で必要な情報が複数ブロックにわかれて、ループ表示される仕組みだろう。まさに電光掲示板感覚である。
制約の強い、限定的な空間に多くの情報を表示させるためのシンプルで、有用性の高い表示方法だ。これを採用すれば表示ブロックにスクロールバーは必要なくなり、無駄なハイパーリンクでナビゲーションが混乱することも防げる気がする。
なんとなく、RWDの先にはこういうデバイスの想定があって、「ノンスクロール・デザイン」とでも表現できそうなデザイン手法もRWDを拡張していくんじゃないかなあと思ったりするわけです。
Webコンテンツもストリーミングものが増えていて、静的なコンテンツの一括表示よりも小さなデータのリアルタイム表示というニーズも増えてきている。以前どっかでWebブラウザはストリーミングコンテンツを表示するものに変わっていくみたいな記事をみたけど、ある意味そうかもしれないと思う。
そういう中で、Webデザインの将来を考えるとまだまだ考えることがたくさんあるなあと思います。
一方で、そんなことを考えている中で気づいたことがひとつ。上記のようなノンスクロール・デザインを実践しているスマートフォンがあって、それをボクは使っているのでした。ボクの仕様端末はIS12T。現在国産唯一のWindows Phoneである。
Windows Phone/Windows8はWindows Store Appというアプリケーションのスタイルを提供していて、そのUIの特徴の一つにTileがある。TileはiOSとかで言うところのアプリのアイコンなんだけど、他にも機能を持っている。
例えばカレンダーアプリのTileは直近のスケジュールを一つ表示してくれる。PeopleというSNSのアプリは「◯◯さんがいいねと言っています。」のような直近の未読ステータスを一つ表示してくれる。Tileは簡単なnotification機能を備えている。そのためアプリを起動しなくてもアプリに起こっている何かを知ることができる。
Tileの面積は決まっていて、大きさは2種類（Windows Phone8では4種類だったか？）しかない。アイコンなのでスクロールは当然できない。その制限の中で面積以上の情報表示が必要な場合、Tileでは様々なアクションで情報を切り替えてユーザーの注目を惹く。
時にはゆっくりと自動スクロールしたり、忍者屋敷の隠し扉みたいにパネルが反転したり、素早くスキップしたり。チラッとみただけでも「お、何かがあったな」とすぐにわかるようになっている。Tileはアプリが「今自分を起動すべき」ということをユーザーに直感的に伝える仕組みを持っているのだ。
TileのレイアウトはXMLで定義する。このあたりが参考になると思う。いろいろな表現が可能なのでアプリに合わせた通知を考えられるだろう。Tileの通知は具体的には下記のように写真の下から青いテキストブロックが定期的にオーバーレイされるような感じだ。
あまり情報がないのだけど、Windows Store ApplicationのUIはユニバーサルデザインの観点から非常に興味深い特徴がいくつもある。今のWindowsのUIチームは情報アクセシビリティについてとても深い考察をしているような気がする。ここでは詳しく書かないけどまあ見れば見るほどすごいと思える。
アクセシビリティを追求したWindowsとGoogle GlassのインフォメーションUIに共通した点があるのは興味深い。どちらもこれからの情報端末の姿を模索しているプロダクトである。この点を踏まえてもWebデザイナーは将来のWeb UIを考える上での参考にできるのではないかと思ったりする。
しかしまあ、Google GlassでWebサーフィンできるようになるのはまだまだ先な気がしますけどね。なんちゃってGoogle Glassなメガネがすぐに出てきて、UIがダメダメで使えない事態になるのは目に見えるわけですよ。
そこにバズってていいから何かの解決方法を唱えられるデザイナやエンジニアはちょっと儲かるんじゃねーの？と思いつつ。なんかテンション落ちてきたのでこのへんで手を止めようとおもいます。
B2G Desktop を起動してみる
FirefoxOSはHTML5的にも面白そうなデバイスなんですが実際どうなんでしょうねー？アプリを開発してみたい！と思ったらシュミレーターがFirefoxアドオンとして提供されているのでかなり手軽にやってみることができます。
シュミレーターについてはFirefoxの伝道師@dynamitterさんとかがよく紹介されているので周知だと思うんですが、同じ物をデスクトップ上でも動かすことができます。このアプリケーションランタイムのことは B2G Desktop と呼ばれているようです。
まあ別にFirefoxOSアプリ開発を試してみるには上記のアドオンで十分なんですけどね、最新のGaiaアプリを試してみるにはB2G DesktopがいいようですのでとりあえずGaia/Hackingを参考にデスクトップ上で起動してみようと思います。
ボクはMacなので以下はMacの場合です。
まずターミナルでgithubからgaiaをcloneしてgaiaをmakeします。
この例では /src にgaiaをcloneしたものとします。
$ cd /src
$ git clone git://github.com/mozilla-b2g/gaia.git gaia $ cd gaia $ DEBUG=1 make
次にここからB2G Desktopをダウンロードします。ボクの場合はb2g-20.0a2.multi.mac64.dmg をダウンロードしました。他のOSの方は適宜それっぽいのを落としてください。
dmgを展開して、適当なディレクトリに置きます。今回はとりあえず gaia直下に置くことにします。
gaiaのディレクトリで、以下のようにしてB2G Desktopを起動します。
-profile オプション以下のパスは ./gaia/profile/ と同位置なんですが、絶対パスで指定してください。
$ /src/gaia/B2G.app/Contents/MacOS/b2g-bin -profile /src/gaia/profile/
すると、B2Gが起動します。
初期セット画面が表示されます。
適当にNextしていって、ホーム画面までたどり着きましょう。
左がB2G Desktopのホーム、右がFirefoxアドオンのホーム。現時点でもちょっと違っていますね。
B2G Desktopはホームボタンもありません。操作はクリックとキーボードショートカットで行います。ショートカットは以下。
ホーム: fn + ←
パワーボタン: fn + →
ボリューム: fn + ↑↓
B2G Desktopを終了するには、ターミナルで Ctrl + cするかウィンドウをクローズします。この状態で、再び上記のコマンドで起動すると、以下の様な画面になることがあります。
この場合は、
$ DEBUG=1 make $ /src/gaia/B2G.app/Contents/MacOS/b2g-bin -profile /src/gaia/profile/
とすれば初期状態のB2G Desktopを起動することができます。
まだ開発中なのでgaiaのアップデートも頻繁に行われています。追っかけるためにとりあえずセットアップしてみるのもいいと思います。
