今日は簡単に。RSSをブラウザーや専用クライアントで見ている人は多いが、自分が普段使い慣れたツールで見られたら便利という考えもあるだろう。メール中心の生活をしている人は、メーラー内蔵のNNTPクライアントで見てみるってのはどう？
現在発売中のWebDesigningには、去る4月19日に電気通信アクセス協議会の主催や総務省の後援で行われた「Webアクセシビリティ・セミナー」の記事が掲載されている。この記事を読んだ後、おいらもこういう関連の情報は全く知らんというわけにもいかないだろうなぁー、と見に行かなかったことをちょっとばかし悔やんでいたわけだ。
んで、この時とはターゲットが異なるようだが、ソフトウェア技術者協会関西支部および社会福祉法人プロップステーション、システム情報制御学会MUIS研究会らの主催で行われた「Webアクセシビリティ・シンポジウム」というのを見に行ってきたですよ。この間スラドでトピックになっていたやつですな。
このシンポジウムで議題になったのは、ユニバーサルデザインと社会との関係について、そしてボイスブラウザを体験してみよう、の2つ。
前者について講演を行ったのは、ユーディットというIT機器やWebサイトのユニバーサルデザインについて研究をしている企業の代表。この会社で行っている、障碍を抱えている人やその関係者を含む17歳から80歳まで200人以上が在籍する多様な登録社員（非常勤みたいなもの？）制度の話や、CGデザイン、Webクリエーションやデータベースリサーチなどの分野で活躍する5人の障碍を持つ正社員の紹介などがあった。経済産業省で進行中のウェブアクセシビリティガイドラインのJIS化に関する委員会の主査もこの会社の障碍を持つ社員が勤めているとのことで、障碍者の社会進出の勢いのひとつを受け持つ存在でもあるようだ。
この企業ではユニバーサルデザインの定義を「年齢、性別、能力、体力などに関わらず多くの人たちが使えるように、最初から考慮して設計、開発すること」としている。社会制度や生活空間の設計を行ってきた「健康な成人男子」というのは、全人口のほんの何割にも満たない存在。この人たちが、社会の大多数を占める「自分達とは異なる状態にある人」たちのことを考えないと、多くの人に住み良い社会は実現できないという。アクセシビリティ関連の話題として「バリアフリー」が取り上げられることがあるが、こちらは「使いにくい街や物を使いやすいように、徐々にバリアーを外していくこと」なのだそうだ。
ユニバーサルデザインの例として、ヤマハのPASも紹介されていた。この自転車は高齢者の体力などを考慮した上で設計を行っているが、特に老人向けとはうたわず若い女性への浸透を狙った宣伝し仕掛けた。そして認知度と普及度が上がった結果、高齢者に「使ってみよう」という気を起こさせた、という説明もあった。障碍のある人を基準にものを作ることで満足のできる層を飛躍的に増大させたというわけだ。そしてこれらの製品は特に障碍者や高齢者専用というわけでもないのだ。IT機器においても、こうしたデザインに気を配っているIBM ThinkPadやDocomo F671i isなどは高齢者から若い人まで幅広い層からの指名買いがとても多いのだそうだ。また、障害者の利用を意識して作られたもので、その後一般利用されるようになったものとしては、トランジスタ（もともとは補聴器用）、カーディガン（リューマチ患者用の衣服）、ARPANET（聴覚障碍者向けに作られたテキスト交換用インフラ）、音声認識技術（脊髄損傷者向けのワープロソフト）、ウォシュレット（病院用）などが挙げられるそうだ。
WebにおいてはWAIのガイドライン勧告以降も、米国のリハビリテーション法508条によってアクセシブルでない製品を連邦政府が購入することを禁じたおかげで多くの公共サイトに変化が起きたり、日本でもJIS化に伴い法制によってアクセシブルでないWebサイトを公共サイトから排除することを考えている自治体などが出てきている、といった動きがあるそうだ。
また、すでにアクセシビリティを実現している自治体として秋田市や浜松市が挙げられていた。確かに情報本位のサイトデザインになっているし、画像をオフにしても情報は読み取れるわ、デザインは崩れないわ、よく作ってある。なにせ透明GIFでレイアウトを作ったサイトなんざ、画像を読み込めないと（以下略）。
2005年には成人人口の半分が50代以上となり、物づくりの基本を考え直さないとならない時代になるそうだ。これらの層は若い人に比べると多くのハンディを抱え、だが高い向上心と時間とお金を持っている。ところが世の中の多くのものは、生活実感の少ない都会の20歳〜30歳代のデザイナーがデザインしており、作り手と使い手の間の距離が大きいのだそうだ。ウェブのデザイナーはOSやブラウザーなど閲覧環境の差異については敏感に意識するが、それを見る人たちの差異についてはほどんど気にしていない。見る人によって年齢や能力、知識に差があることを意識するだけでも、作り方は変わってくる、それが第一歩なのだそうだ。
次に2つ目の演目について、有志団体「ACRI」の代表より講演があった。こちらは利用しやすいウェブ作りの普及に関して、ボイスブラウザーという切り口から活動を進めているとのこと。先日の「Webアクセシビリティ・シンポジウム」で行われた「みんなのWebコンテスト」にも参加したりと結構がんばっている。
バックグラウンドとしては、特に周囲に障碍者がいるわけでもなく、Validでユーサビリティを意識したサイト作りを楽しんでたという、どこかで聞いたことのあるような経緯なのだが、ある日IBM ホームページリーダーで自分のサイトを閲覧し、あまりのひどさに衝撃を受け、ASV 全国視覚障害者インターネット接続支援連絡会の助けを借りて、障碍者によるインターネット利用の現場や利用状況の調査を行ったのがACRIの始まりなのだそうだ。
以前、犬気圏の「音声ブラウザ メモのメモ」でボイスブラウザーの話題をしていたのでご存じだと思うが、スペースでレイアウトを調整したテキストやalt属性のない画像、フレーム付きのサイトなどをボイスブラウザーでアクセスするとえらい目に遭う。画面が何もない状態で、そういった特徴を持つサイトにアクセスするデモをしてくれたんだが、正直「あのー（￣△￣；」というのが感想。何のサイトだか全くわからない。見えているものと聞こえるもののギャップが激しいのだ。
WAIのアクセシビリティガイドラインでもこういったことに対する対処を呼びかけているが、例えば日付けのフォーマットをどうするとか（2003/06/01よりは2003年6月1日が望ましい）、リンクに「ここ」とか「こちら」と書くなとか、地図の内容は道順説明のためのテキストを別に用意してimg要素のlongdesc属性にそのテキストページを参照するURLを書いておく手もある、といった具体的な例の紹介が少なく、ただガイドラインの内容をクリアして終わりというサイトが多いのが現状なのだそうだ。うーん、実物を使っていろいろやっているとその意味がよく分かりますな（￣△￣；。
また、音声ブラウザ自体の問題もいくつかあるのだそうだ。例えばユーザーエージェント名がベースとなるブラウザーのものをそのまま利用するのでボイスブラウザーでアクセスした記録が残らない、読み間違えが多い（Ruby要素のサポートを懇願していた）、音声スタイルシートの未サポートによって細かな制御がしにくい（EmacSpeakを利用したBilingual Emacspeak Projectの製品は対応しているらしい）。そして価格が高い（15万円位するものもあるそうだ、ひえー）。なによりも、多くの製品が要素に対する振る舞いの情報が公開されていないため、コンテンツの制作者側が「よくわからん」と言い出す事態になるそうなのだ。
こうした現状をふまえ、各製品の動作チェックを進め、もしも可能なら自前で理想の音声ブラウザーを開発し、とにかく安く配って、知名度と普及率を上げて音声ブラウザーも気にするのが当たり前という状況にしたい、と言っていたが、先は長そうだなぁ（￣△￣；。「HTMLとCSSに詳しい人、視覚障碍者、プログラマー、宣伝好きなどの協力者求む」状態らしい。おいらは機会があったら（そしてPCが手もとにあったら）、音声ブラウザー使ってみますか。
ちなみにこの代表、一時期Web製作板で話題になった「スタイルシートでマルチカラム・デザインを 実現する方法」のサイトの人ですね。ついでにいうと最初に出てきたスラドのたれ込み主でもありますね。すべては自作自演でありましたか（￣△￣；。
その後、関係者によるパネルディスカッションが行われた。話題は大きく分けて2つ。1つ目はアクセシブルでないサイトに対する現実的な答えとしての「オペラ」ブラウザーの存在。もうひとつは、大学の情報工学教育におけるアクセシビリティ教育の必要性についてだ。
オペラについては、マウスジェスチャーやキーボードショウトカット、拡大縮小表示機能、プリセットされたユーザースタイルシートが紹介された。特に注目が集まったのが、拡大縮小機能とスタイルシート。どちらも「個人に合わせた形で情報の形を変えられる」という点が評価を受けており、今後のいろんなソフトがアクセシビリティ対応を行っていく上での参考例となるだろうとのこと。また、スクリーンリーダーとの相性をぜひ検証すべきだとの意見が出ていた。多くの人はオペラというソフトを初めて見る人たちだったようだ。おいらにすれば、オペラなんぞすっかり見慣れたソフトだったのだが、違う視点からこういった評価と提案が出てきたのは新鮮だったりする。
そして、大学の情報教育でのアクセシビリティ教育だが、特に重要なのが研究室。研究室内では様々な文化が先輩から後輩に継承されていくが、その中に「アクセシビリティの高いサイトを作ることは、Validなサイトを作ること以上に大切で、かつ優れたデザインを実現する手段だ」という価値観を持たせてほしいとのことだった。
また、主催であるプロップステーションでの活動の紹介も行われたが、ハンディキャップのある人の社会参加には技術者の支援がぜひとも必要だという訴えが行われた。ITが障碍者の大きな力になるのであれば、当然技術者の支援というのはその力を大きく左右することになるのだろう。
つーわけで、技術的にどうこうするセミナーというより、何に困っているのかどう解決するのがいいのか、といった内容を「お腹いっぱい」いただいてきました。
上でひとつ言及し忘れていたことがあるんだが、ユーディットの講演で「ユビキタスに対するアクセシビリティの確保」ということが今後の課題に挙げられていた。おそらくモバイルに代表されるいろんな機器でアクセスする可能性を排除しないこと、と受け取った。
i-modeやJskyといった専用のマークアップ言語を使う端末はともかく、PCと同じHTML/XHTMLを表示できるブラウザーを搭載した端末は今後増えていくはず。というのも、PC向け、昔のスペックのPC向け、モバイル向けと別々の環境に向けてコンテンツを作り直すことは、手間の面でも費用の面でもあまり良いことではないことだからだ。
これはユーディットの代表も口を酸っぱくしていっていたことだ。かつて長野オリンピックの際に5カ国語版のコンテンツに加えて、最新技術に対応できないブラウザーのためにそれぞれのテキスト版を作るという提案が出て、この手間をどう解決すべきなのか、という論議から出てきた答えなのだそうだ。
その点で、PCと同じコンテンツを表示できるモバイル端末の普及は、コンテンツの制作側に対して大きな手助けとなるはず。また、特にホビー向けのモバイル機器を中心に、容量の大きな画像/映像ファイルを扱うために、ハードウェアスペックの強化が進んでいるという追い風がある。
ただし、そうは思ったものの「モバイル端末の画面は小さい。そこにPCと同じコンテンツを表示していいのか!?」という疑問が出てきた。そこでPCと同じコンテンツをモバイル向けに提供する場合のひとつの例を見てみようと思ったわけだ。
明らかにモバイル端末からのアクセスを想定しているサイトの例としてwww.opera.comを選んだ。なぜここを選んだかというと、ハンドヘルド機器向けのスタイルシートを用意しているからだ。www.opera.comのトップページをハンドヘルド機器向けのスタイルシートを適用した状態で閲覧すると以下のように表示される。Opera 7でハンドヘルドモードの起動は「Shift」+「F11」キーで行う。北米などで販売されているソニーエリクソン製携帯電話向けのOperaには、このモードが組み込まれているようだ。
PC向けの表示と見比べてみてほしい。まず目に付くのはナビゲーション。携帯には関係のないコンテンツへのリンクが取り外されている。また段組みが取り外され、縦にコンテンツが並んでいるが、各見出しが青いバーの地で彩られており、分かりやすい見た目を提供している。その他にも、多くの記事が省略され画面がごちゃごちゃしないように調整がされているのがわかる。
www.opera.com自体、もともとFlashなど動きのある要素がないこともあり、PCとモバイル機器向けのコンテンツの効率的な提供に成功しているようだ。もしもPCと同じ情報が見たければ、スタイルシートを解除すればいいことになる。もっとも、その機能がモバイル端末に実装されるかどうかは、また別の話になるが。
この方法はmedia="handheld"をサポートしている端末が前提になるため、日本のモバイル端末用ブラウザー（例えばザウルスなどに搭載されているネットフロント）に対しては有効な手段にはならないのかもしれない。また、この先携帯電話の搭載メモリー容量がどう変わっていくのかも気になる話だ。そうであっても、こういったテクノロジーにすぐに対応できるようなつくりを心掛けているコンテンツであれば、モバイル端末への情報提供、ひいてはユビキタス環境へのアクセシビリティの提供はそう難しくないかもしれないと思いたい。
100人ぐらいの参加者で障碍を持った方も1〜2割ほどいたようです。来場者の多くは体に障碍を抱える人や福祉関係、そして大学教授や教育機関のウェブ管理をしている方だったように思います。セミナールームを使った小規模で、しかも有志による手作り感の漂うセミナーだったのですが、それゆえ密度は濃かったです。もじらパーティなんかと同じ印象を受けたかな。
ただ手作りが故に、仲良し団体同士で一緒に進めた感じがあちらこちらにあって、講演の最中にも内輪話が結構あったりしたのは困りもの（￣△￣；。
また、他の機関などで並行して進んでいる同種の動きに関する情報が、当事者たちによく見えてないのかな、と思うような場面もありました。いろんなグループが草の根的に進めているんだろうけど、お互いの存在を知らないとか、自分達以外にどんな人たちが何をしてるのかといった情報が届かないようでは、まだまだ大きなうねりになるのは遠いのかなぁっと。この状況の改善には国や専門誌のサポートに期待するしかないですな。
犬神さんは行けなかったそうですが、主催側で収録ビデオのオンライン配信を検討しているそうです。公開時期は聞かなかったのですが、しばらく経ってから関連情報をチェックしてみるといいかもしれません。
覚えているだろうか。おいらは今年1月の「そんな情報だけでもおいしいわぁ」という記事で、こんな妄想を語っている。
こんな調子で、収集したサイトの管理人の自己紹介ばかり表示されるソフトとか、そういう情報を記述する規格とかあったらおもしろいんだけど、誰か知らぬか。＜それこそ、RDFの活躍の場のような気が（￣△￣；。
というわけで、The Web KANZAKIの6月1日付けの記事「メタデータによる知人ネットワークの表現」はまさに「キター ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!」ってな感じな訳だ。
その醍醐味は、他のFOAFデータとの連携らしいのだが、よく原理を飲み込めていないので語彙や「ドメイン」「レンジ」などの概念が意味するところがわからん。とりあえず、自分に関するデータだけでもウプしました。
使い道は後から考える、とりあえず一歩を踏む出すことにして。どんどん成長させるべ。
ちなみに、上のFOAFファイルはリンクをクリックするとモジラはファイルに保存しようとし、マック版オペラは一応レンダリングしてくれた。しかしだ、本当はソースを見てほしかったので、どちらもあまりいー感じはしないなぁ。
それはともかく、ブラウザがサポートしていないXML系の文書、どのように処理してますか？ 上の文書はapplication/rdf+xmlで吐いています。
とある方面（どこ？）では、それなりにクズ扱いされているオペラではあるけど、そのオペラの関係者が各種のインタビュー記事などで口にしているフレーズでひとつ気に入っているものがある。
それは「State of the Art」というフレーズ。オペラ社のミッションステートメントのページにも載っている言葉だ。辞書的には「最新の技術」という訳が付くが、「Art」という言葉が添えられている点がミソだと思っている。欧米の文化には詳しくないので、間違った意味で捉えているかもしれないが、オペラの技術が生み出す機能というのは深い思索に基づいた芸術である、という（信者的な）捉え方もできるのかなといったところだ。
オペラの特徴的な機能は、マルチドキュメントインターフェースにしてもマウスジェスチャーにしてもオペラ社の完全なオリジナルではなく、それ以前にどこかでアイデアが示されたことのあるものばかりだ。ただし、オペラはこれらの機能をただ技術的な興味から装備したわけではなく、彼等のいう「The Best Internet Experience」を提供するために用意したのだ。
それはオペラによってこれらの機能が、ウィンドウズのウィンドウ制御システムに不満を持っていた人たちやハンディキャップを持つ人たちにとって「使える機能」ということを示したことに実証されているように思う。むろん、ソフト利用に対してそういった不満を持っていない人たちからもこれらの機能が評価され、一部では熱狂的な信者を持っているのは有名な話かと思う。限りなく信者的な見解ではあるが、「オペラには匠の手によって実現された、心のこもった最新技術が含まれている」という言い方もできなくはない。
モジラを愛している人たちには申し訳ないが、モジラがいろんな機能を取り込む際にこの「Art」や深い思索がどれほどあったのか。技術的な点ではモジラは非常に高度で、隙のないくらい多彩な機能を備えている。おいらも何か新しいことをやる際には、モジラのいろんなツールに助けられている。ただ人を納得／熱狂させるための製品哲学に関しては、モジラはとても弱く、人工的で工業生産品のような感じもしなくはないのだ。
モジラの多彩な機能を持ってすれば、確かにいろんなソリューションを提供することは可能だ。でも「こんなことに困っている人たちを助けるためにこんな機能を備えました、これはあなたたちにも大変に役立ちますよ」といった部分に関しては、モジラを推す人たちの間からはなかなか聞こえてこないのが現状だ。また、何を以ってモジラを推していくか、まだ迷いがあるように思えてならない。
おいらのいう「マーケティング」というのは、別に売ったり普及を進めるために宣伝や仕掛けをしろということではなく、ましてやその手法云々を他に見習えということでもなく、ただモジラが存在している理由やモジラがあれだけの機能を備えている理由を納得させるための何かをもっと訴えていけ、という感じだったりする。むろん、アップルに代表される、海外のブランド力のあるソフトを持つ企業というのは伝統的にそれが得意だったというのは言うまでもないんだが。
以前オペラのハンドヘルドモードの話しをしたんだが、こういった表示モードの切り替え機能を備えているブラウザーがどれくるかるか、少し気になったんだ。そこで、簡単なテストページを作成して、手元にあるブラウザーのいろんな表示モードとスタイルシートの関係を調べてみた。
印刷時にそのままでPrint用スタイルシートが適用されるのがサファリだけ、というのが驚きだった。他のブラウザーでは明示的に設定しない限りは、スタイルシートが解除された状態で印刷される。ウェブブラウザーで印刷用スタイルシートを標準で適用すべきなのかどうかは意見が分かれそうだが、この状態だと印刷用スタイルシートを作るのは無駄骨ですかねぇ。
スタイルシート対応の組み込みブラウザーなども試してみたいけど、手元に全くないのが残念だね。
「トモダチいないんですか？」みたいな言い方されてしまったんで、FOAFファイルの「foaf:Person」カテゴリに6月に入ってから引用やコメントなどで関連のあった人のデータを追加しましたですよ。
FoaF Explorerによってウェブブラウザー用に整形されたデータ
というものの、こうしたRDF関連のデータ形式は作成の手間がかかるし、SN比の高いデータであることによる弊害（嘘をつくのが簡単になるなど）なんかもないわけではないので、対応することで何が幸せなのかがいろんなツールによって提案されていかないと作っていくのは辛い感じがするねぇ。
foafnaut!のようなツールが日本でも盛んに利用されるようになったり、以前話題になったサイト間の近さをあらわすツールなんかがこれをベースに使えるようになったり、といったことでもない限りはやらないだろうなぁ。GoogleでFOAF関連の日本語情報を探してもIBM Developper Worksの情報しか出てこなかったし。
未だに信じがたいんだが（おいらはてっきりクラシック版の話しだと……）マック版のインターネット エクスプローラー（愛称IE:mac）が開発中止とな。正式発表を未だ探せないでいるのだが、'97年春の日本語の通るバージョンの登場から去年の12月まで足駆け5年近く使い続けたブラウザーだけに本当に引退となると非常に感慨深いものが浮かび上がってくる。
インターネット エクスプローラー自体はご存じの通り、インターネット普及期の人気ブラウザー「モザイク」の1ディストリビューションだった「スパイグラス モザイク」がその原型で、かつてのライバルブラウザー「ネットスケープ コミュニケーター」とは遠い親戚関係にあった。
マック版のインターネットエクスプローラは、当時ウィンドウズでは「マイクロソフト プラス！」のおまけだったものをマックに移植したもの。最初のバージョンである2.0は日本語が通らないものだったが、'97年春にバージョン3として日本語版が登場、「マイクロソフト メール&ニュース」という文字化けしまくりで不評を買ったIEコンポーネントタイプのメールソフトとセットになっていた。
このバージョン3が出た頃は「ネットスケープ3」の全盛期で、テーブルとフレームを使ったサイトが本格普及した時期でもあった。おいらの大好きなウェブオーサリングツール「ゴーライブ サイバースタジオ」（今のアドビ ゴーライブ）がこの世に初めて登場した頃でもある。
当時のネットスケープは、すべて読み込み終えてからレンダリングを開始していたのでテーブルの多いサイトではもたもたしている感触が拭えなかったのに対し、インターネット エクスプローラーは読み込みながら随時表示していったので「非常に高速なレンダリングを実現している」といった印象を受けた。
ただ、画像などはその位置を最後に調整し直していたので画面が動くのが気になったが（そのためか、画像のサイズをHTMLに記述するのが当たり前となってしまった）。またキャッシュの効きが異常に強く、コンテンツを更新しても数時間経たないと変更を確認できないこともあった（これはバージョン5の登場まで悩まされた）。アップル製のインターネットスイート「サイバードック」が登場したのもこの頃だ。
続くバージョン4では、オートコンプリート機能の採用やブラウザーの使い勝手を大幅に進化させたサイドバーの搭載などが盛り込まれた。日本では'98年春のマックワールドエキスポで初公開され、数日後より配布が始まっている。付属のメールソフトはIEコンポーネントタイプのアウトルックエキスプレスに変更された。
また前バージョンでは先攻採用だったCSS1に正式に対応した。おいらがCSSを使うようになったのもこのバージョンから。CSSで行の高さを調整できるのが魅力的だったが、同時期に登場したネットスケープ社のインターネットスイート「コミュニケーター」で、画像にも同じ高さが適用されて後に続く文字が隠れてしまうのが悩みの種だったのも覚えている。
またこの年の夏にアップルとマイクロソフトの間に結ばれたクロスライセンスを含む5年間の業務提携の契約によって、マックの標準ブラウザーになったのもこのバージョンから。iMacを買うと「インターネット」というアイコンがデスクトップ上にあり、これをダブルクリックするとインターネット エクスプローラーが起動するようになった。
'99年の春には改良版であるバージョン4.5が登場。この頃にはウィンドウズ市場でのコミュニケーターとインターネット エクスプローラーのシェアは完全に逆転。マック市場では初心者はインターネット エクスプローラー。古くからのユーザーはコミュニケーターという2極化が進んだ。
このバージョンで思い出深いのは「XHTML対応に問題あり」だったという点。XHTML 1.0は従来のHTML 4.01をXMLで再現したものなので従来のブラウザーでも問題はないはずなのに、このバージョンでは冒頭のXML宣言によって、コンテンツをHTMLと判断できずソースをそのまま表示してしまう問題があった。当時XHTMLを使っていた猛者たちは、UTF-8でファイルを保存してXML宣言を省略するか、SSIでXML宣言を入れるか入れないかの振り分けをしていた模様（この辺は某功罪スレの初期のログを見ると分かる）。
2000年の春に登場したバージョン5は全面的に改訂が行われた。おいら的に一番大きかったのは「タスマン」と呼ばれるレンダリングエンジンの採用。「開発者」というよりは「利用者」として参加する割合の高いマックユーザに向けて「高速」「DOMやCSS2を含むWeb標準への対応」をモットーに開発された。このレンダリングエンジンは当時マイクロソフトのWeb標準対応状況を激しく非難していた米国のウェブ標準化プロジェクトをして「もっとも標準準拠に近いブラウザー」と言わせしめたほどだ。iCabでマックユーザーの意識を引いた「Web標準対応」にインターネットエクスプローラーが火をつけた感じとも言え、おいらもこのブラウザーでWeb標準対応を強く意識するようになった。
ほかにも高速化を目的としたプログラムのタイト化（つまりIEコンポーネント製品を作れなくなった）、そしてマックの標準ブラウザーにふさわしいスタイリッシュでユーザビリティ的にも優れたユーザーインターフェースの採用（このためにマイクロソフトは数百万ドルのデザイン費を注ぎ込んだとか）などが特筆すべき事項か。前バージョンで起きていたXHTML関連の問題は解決されたが、そのかわりファイルプロトコル経由でXHTMLデータを読み込むとパースエラーを起こすという妙な問題が起こるようになった。おいらは当時この問題に対処するために、ウェブ共有コントロールパネルを利用してlocalホストからhttpプロトコル経由でデータを読むようにしてた（そのかわりダイヤルアップだったから、いちいちバーチャルLANに設定を切り替えていたんだけど）。
同年秋にはMac OS X用のバージョン5.1ベータが登場。当時はプログラムのユニコード対応が遅れていて、あちこちで文字化けが頻発していたわけだが。この5.1から「ベータ版」がとれたのは2001年秋のMac OS X 10.1に付属のものから。「IE:mac」という愛称を採用し、「マイクロソフトのブラウザー」という看板を外した歴史的なバージョンでもある。ファイルプロトコロルの問題はこのバージョンで解決したんだが、かわりにXML関連のパーサーがバカになっていった。おいら的にはW3Cの標準に対応したMSXML3の早期採用を望んでいたんだが、結局これはかなわぬ夢となったわけだ。
2002年夏にはバージョン5.2が登場。ここからはMac OS Xのみのバージョンとなる。おいら的には特筆すべき事項はなし。これがIE:macの最後のシリーズとなった。この2002年は、モジラ1.0そしてネットスケープ7、キメラ（現カミーノ）、オペラ6と新しいブラウザーが話題となり、またこの夏にマイクロソフトとの業務提携が切れたことからアップル製ブラウザーの再登場が噂された年でもあった。
MSN用のブラウザーの話しもあるので、バージョン6の開発ももう大詰めを迎えているのだろうと思っていたが、先日のウィンドウズ版の単体提供中止の話とタイミングを合わせたのだろうか。（同社の「.NET」も含む）最新のウェブ技術への対応という課題を残したまま、IE:macは舞台を去ることになってしまった。
かつてマイクロソフトは会社の戦略をインターネットを軸に切り替えるときに「インターネット製品を出すようなことはしない。インターネットを自社製品に取り込むのだ」と述べたと言う。これからマイクロソフトはその言葉通り、オフィス製品やウィンドウズ自体のサービスを中心に、目に見えないかたちでウェブのサービスを利用できる形態に移行していくのかもしれない。ウェブを利用しているのはもはやブラウザーだけではなくなっているのも事実なのだから。
IE:macに続く、マックの標準ブラウザーは高い志を持ったものであってほしい。ウェブブラウジングが今後ウェブ利用の主役でい続けるかどうかはおいらには分からないが、だがより問題の少ない情報の発信を後押しする高い技術力と志をブラウザーの開発者が備えていることは絶対に必要だと考えているのだ。
【追記】スラドでMacBUの開発者のサイトを紹介してもらった。うーん、報道は本当っぽいなぁ。
ウェブでの情報発信つーのは思いのほか難しいことが多い。利用側の利用の仕方が一定でない（それはブラウザーが違うといったレベルの話ではない）ため、商売でサイトやるとなるといろいろ気を使うことが多くなるんだ。また、費用の問題もあるので作業効率を考えないといけないんだが、自分の知っているやり方と違うというだけで駄目出しをしてくる人もいたりして、そこをなんとかしないといけない。
実際に作業をしてくれる人はこの辺良く分かってるんだが、偉い人や無理解な外注ににそれを納得させるには至らないことが多いんだな。つーわけで、相手を黙らせる方法を考える必要にたびたび見舞われてきたわけだが、以下その記録。かなり脚色入ってます。
説得力ないなぁー（￣△￣；。お粗末様でした。
インターネット エクスプローラーがマック市場を去ることになり、そのあとには「クチバシの黄色い」ブラウザーたちが残ることとなった。むろんモジラもネットスケープもまだ健在だが、次世代の主役はこの「クチバシの黄色い」ブラウザーたちが担っていくことになるだろう。
アップルのサファリは日本語の扱いにまだ問題を残しているが、伝え聞くところによると、今月中にはゴールデンマスターを迎え、7月からMac OS X 10.3（パンサー）が登場する秋あたりの間で正式版に昇格する見込み。今後はマイクロソフトが技術協力を行うという話もあるらしい。
それが本当なら、こんなストーリーになるのではないか。
マイクロソフトは、MSNメッセンジャーやオフィス製品で.NET対応を進めるのに並行して、サファリの実装するウェブフレームワークの.NET対応を支援する。アップルはこれをSDK化し、各社製品がカーボン/ココアのフロントエンドを持った.NET対応のウェブアプリケーションとして開発されるための基礎作りを行う。また、ブラウザとの連携が必要なサービスをサファリで利用できるようにする。
ま、完全においらの妄想ではあるんだが（￣△￣；、マイクロソフトとしても自社技術の利用人口が広がるのは悪い話ではないはず。ましてやマックは20年近く関わり続けた馴染みの市場な訳だし。
一方で、カミーノ、ファイアーバードといった新世代のゲッコーブラウザーは、軽量でシンプルな使い勝手を武器にサファリに真っ向勝負を挑むことになると思う。現時点ではレンダリングの正確さではゲッコー系に一日の長があり、世界中のゲッコーユーザーのフィードバックが生かされる点で多くのマックユーザーのフィードバックを得るサファリと同じ条件を持っている。UIのカスタマイズなど独自の魅力を増やし、どれだけファンを獲得するかにかかっているような気がする。
もうひとつはオペラ。このブラウザーは正直言ってサファリとの真っ向勝負を避けるのが懸命だ。オペラの魅力は「state-of-the-art」、おいら的に「深い思索に基づいた芸術」と訳しているこの特徴は「マックユーザーに受けるブラウザー」を目指した時点で破たんしてしまうような気がする。オペラが目指すべきは壮大なクロスプラットフォームの野望にあると思う。
オペラには最大3つまでのプラットフォームのライセンスを買えるプログラムが用意されている。ウィンドウズ版とリナックス版を見る限り、次のマック版オペラがどんなブラウザーになるかは容易に想像がつく。リナックスやマック、果てはPDA/携帯電話と、マルチプラットフォームで利用するウィンドウズユーザー（もしくは携帯電話ユーザー）に変わらぬ使い勝手を提供するのがオペラの狙いだろうし、「.switch」を進めていたアップルに対して「共存の価値あり」と訴える手段にもなるはずだ。こういった手法はマックユーザーには受けないかもしれないが、非アップル的な価値観を持つユーザーには十分訴えるものがあると思う。
それから密かに期待しているのは、サファリのコンポーネントブラウザーの誕生について。サファリの基礎部分を共有し、リアルベーシックなどで気軽に独自の機能を上乗せできるようになれば、独自ブラウザーや2ちゃんねるビューワー、RSSリーダーやメールソフトなど、いろんなネットクライアントに道が広がるように思う。
マックという舞台から降りるインターネット エクスプローラーだが、昨日のメンテナンスアップデートにて提供されたバージョン5.2.3は、驚くほどの高速化を果たしている。マルチスレッドへの本格対応やCSSのバグなど根本的な問題は見送られたようだが、サードパーティにしてまだこれだけの速度改善ができる能力を持っていたことに驚く。MacBUを去ったブラウザーの開発者たちが、今後いろんな分野でその力を発揮していくことを願ってやまない。
いや、初めはなんだか先行きが不透明で本当に役に立つようになるのかなぁ、と思っていたFOAFだが、何気なくWebViewを通しておいらのFOAFを見てみたら、ご近隣のトモダチの輪をたどれるようになっているではないか！ 参加者が増えたんでこういう楽しみもできたか。ちと感動。
しかし、おいらのデータ、Knownが2人以上表示されないぞ。何か記述を間違えているのかも。
「セマンティック・ウェブ」なんつーのは、ウェブの生みの親であるティム・バーナーズ・リーが言い出した、「途方もなく巨大な妄想」と見る向きもある。今現在、おいらたちが知っているRSSやFOAFなんかは、「人間にもコンピュータにも理解できる情報群」というとてつもない妄想の一例だ。
さて、妄想が妄想たる所以、それはただのインフラに過ぎないRSSやFOAFを利用するアプリケーションを利用することで、何かとてつもない世界が広がるかのような気にさせられてしまうことだ。おいらは、昨日WebViewでおいらのFOAFデータが、ご近隣のFOAFデータとリンクしている様に感動を覚えた。これは初めてハイパーリンクを見たときの驚きと同様ではあるが、半面旧来の友達リストをXMLに置き換えただけでしかない。
このWebViewを見ていると、ある可能性に気が付く。表示されるデータの中に「interest」という項目がある点だ。
おいらが設定した覚えのない項目がinterestの中に含まれているのが気になるが、システムのバグか、それとも誰かがおいらの興味のあるものとして設定したものが引っ張られているのか。この中から任意の項目を選ぶと、その項目に興味を持つ人たちの一覧が表示される。その人たちの名前をクリックすれば、その人のFOAFデータに移動する仕組みだ。
興味の対象を媒介にする点では、ここ1〜2年人気が高まっている関心空間を彷佛とさせる。FOAFは人のつながりをRDF的に示すための道具。個人のサイトでXSLTを使って整形した時点では、個人と他人の意識的なつながりしか目に見えなかったが、WebViewを通すことで違う切り口からつながりが見えてくる。
この切り口はFOAF（やRDF）が提供する語彙をウェブアプリケーションがうまく利用している一例だ。となれば、おいらはFOAFというものに適度な語彙の拡張と、FOAFと他のカテゴライズシステムとの相互乗り入れを果たせるウェブアプリケーションの登場に期待してしまう。
例えばFOAFにスラッシュドットのユーザーIDを示す語意が用意されていれば、誰かのスラッシュドットでの発言を追うことで、同じトピックに参加した人の興味の対象や他の発言を調べるといったことが、スラッシュドットのログをたどるよりも効率的に行える（もっとも、このSN比の高さは、RDFデータが嫌われる原因の1つとも言えのだるが）。
SVGを使って、人と人とのつながりをビジュアル化する試みはすでに紹介されているが、これをさらに進化させて、ある一定の興味の元に集う集団やその影響といったものもある程度の図示が可能になるかもしれない。そうすることで、ほかにもCSSに興味を持っている人たちのコミュニティはないのかな、とか、誰が異なる興味を持つコミュニティ（例えばCSSとオペラブラウザー、CSSとアニメ）の架け橋になているのか、とかを眺めて楽しむこともできるかもしれない。そうなれば、グーグルのような場所で「CSS アニメ」と検索するだけで「ねこめしにっき」ほかいくつかのサイト群が的確に紹介される、といったことも想像できるわけだ。
というわけで、おいらはバラ色の未来図を意図的にそのマイナス面（詐称の問題など）を無視して語り続けるわけだが、すでにあるものの代替として押し込めてしまうか、それとも新しいネット利用のスタイルを訴えながら種を蒔いていくか、ま、あとは好き好きにどうぞ、ということで（￣△￣；。
最近の土日は寝込んでいる（ゴロゴロしているわけではない点に注意）ことが多いので、なんだかせっかくの休みがもったいない。というわけでこの1週間は体調管理に気を使って、今日一日まるまるサイトのメインテナンスに割り振った次第。
まずはトップページ。開始初期の頃はトップページを持っていなかったこのサイトも、大きくなるにつれてトップページに情報を集約する必要が出てきた。今年に入ってからトップページを用意したわけだが、今回は少し見栄えがするように味付けをしてみました。怪しいCSSの使い方をしているので、レンダリングエンジンの怪しい某ブラウザーではどうなることやら。
次にRSSの更新記録ページのXSLTスタイルシートの更新。昨年秋から使っている例の黄色いスタイルシート用の構造に変換していたので、それを今回のオレンジと茶色のスタイルに合う構造に変更。ついでにXMLに直接XSLTを当てて閲覧するスタイルをやめて、HTMLに変換したものをアップロードした。
このページを用意した当時は、手元に単体のXSLTプロセッサーがなかったんだな。だからしょうがないからインターネット エクスプローラーやモジラなどXSLTプロセッサー内蔵のブラウザーを頼るしかなかったんだ（￣△￣；。ただ、まだまだウェブの世界はブラウザー中心で、HTML以外のリソースを扱えるクライアントは非主流派だ。ウェブブラウザーに便宜を図る意味でもHTMLのソースは用意しておくのが現時点ではいいかな、ということで今回の措置となった。
ただし、今回のように静的なファイルを作ろうとすると、毎度毎度手間がかかってしまってしょうがない。ウェブログのソースからRSSの自動作成、HTMLへの変換、サーバーへのアップロードを行うスクリプトを組むか、もしくはPHPを使ってサーバー側にXSLTプロセッサーを置いて、ブラウザーに動的にHTMLソースを送付するということも検討課題の中に入っている。どちらにせよ、今のおいらのスキルでは無理なんだが。
作成したRSS用のXSLTを見ながら、今度はFoaF用のXSLTを作成。どちらも吐き出すHTMLの構造はかなり近いのだから、RSS用のXSLTからFoaF用のXSLTを吐き出すためのスタイルシートを書けばいいはずなのだが、どうも取り組む気にならない。こういうことも取り組まないといつまでたってもスキルが伸びないんだよなー、と思いつつやっぱり手書きでXSLTを書き直す。最近ようやくXPathが理解できはじめている。「.」を「self::node()」と書くだけでも、どのノードを処理しようとしているのか随分意識できるようになるものだ。
FoaF用のHTMLページのために用意するXSLTはDACさんのFoaFページを参考に、外部のFoaFアプリケーションとの処理を意識して書いてみた。基本的にはFOAFファイルを持っている人のMbox_Sha1Sumデータを引数にしてWebViewに渡すリンクを用意をしてある。これによって、この人の外部とのつながりや興味の対象を確認できるといった次第。
FoaFファイルからこういった自分なりのカスタマイズをしていると、昔ファイルメーカープロを使ってウェブを作っていた頃を思い出す。どのデータをどういう見せ方をしようで悩んだり、いろいろ仕掛けをほどこして有用なページを設計しようとか、非常に懐かしい。
ひとつ思ったのはSHA1にエンコードするためのソフトウエアが欲しいという点。今はThe Web KANZAKIのFOAF紹介ページ上にあるものを使っているが、毎回インターネットに出るのもなんだか、といった感じ。PHPにライブラリが用意されているらしいので自分で組むか、シェル上で動くソフトを探すなりした方がいい感じがする。それともvCardから自動変換してくれるソフトとか。
だれかマック向けに、こういう機能を持ったブラウザーを作って下さい。
えーっとタブブラウザーでは、あるページを開くとかならず別のページがその後ろに回ってしまいます。今日、別のページのスタイルをまねるために複数のページを見比べてましたが、マックにおいて複数のウィンドウを並べて見比べるというのは非常に手間です。
そこでウィンドウを分割し、複数のドキュメントを表示できるブラウザーが必要となります。エディタの分野ではこうした機能を持ったものがありましたし、マイクロソフトエクセルでは、ひとつのウィンドウでのマルチドキュメントはできないまでも複数のドキュメントのウィンドウを整列する機能があります。エクセルの場合はツールバーがウィンドウの外にあるのでこうした方法をスマートに実装できますが、これをブラウザーでやると、ツールバーの分画面が狭くなります。
さくっ、とワンボタンで表示中のページを分割表示。こういった機能を各ブラウザーの開発者は検討してもらえないでしょうかねぇ。
昨日は昨日で「まだまだウェブの世界はブラウザー中心」と言った舌の根が乾かぬうちに、昨日とは観点を変えて、「専用クライアント」という角度からメディアタイプを考えてみるテスト。あくまでも「テスト」なので、真に受けないように（￣△￣；。
RSSやFOAFといったXML応用《アプリケーション》が新しく作られる度にapplication/何とか+xmlなどというメディアタイプをこしらえるのは、おそらくソフトウェアの実装の方が追いつかなさそうであり、それよりはXML文書みんなまとめてtext/xmlまたはapplication/xmlにしてしまった方が文書を作る人もソフトウェアを作る人も楽でいいのでは、などとも思っていたりします。
と北村さんは6月19日の徒書で述べているんですが、おいらはこういった悩ましい部分に答えを出す専用クライアントの普及をぜひとも望みたいわけで。おいらが見てきた限りのこの手の話はブラウザーで取得することを前提にしているのがほとんどなんだが、逆に専用クライアントであれば実装の問題は遥かにハードルが低いんではないかと考えてみたりする。
ものは試しと、スカンクワークスのRSSをapplication/rss+xmlで吐き出すサンプルをアップしてみた。このサンプルにモジラでアクセスすると、知らないメディアタイプということで処理方法を訪ねるダイアログが表示される。これをRSSビューアーである「ネットニュースワイアー」で見るとどうなるだろうか。え、フリー版の「ネットニュースワイアー ライト」じゃないのかって？ あー、今日ランチェロソフトウェアのサイトを見にいったら今月末まで25パーセントオフって書いてあって、つい買ってしまったんだよね（￣△￣；。ブログへの投稿機能とかあるらしいんだが、詳細はまた今度。
話が横道に逸れてしまった。えーっと、このサンプルにネットニュースワイアーでアクセスしたところ、何の問題もなく表示される。いや、このソフトがサーバーから送信されてきたメディアタイプを無視してる可能性も否めないし、News.JPとか他のRSSビューアーで見てないんでなんともいえないんだが、取り敢えずおいらの思惑と合致する「都合のいいデータが出た」のでめでたしめでたし。
いや、結局ブラウザーというのはある種汎用的なウェブリソースの閲覧ツールという位置づけと言う見方もできなくはないので、ブラウザーの実装を前提に考えるよりも「こういうリソースは、こういうメディアタイプで送信して、クライアントはこういう処理をする」といったルールを優先した方がいいのかもなーということなのだ。そしてデータの提供者はブラウザーから直接メタデータにアクセスさせるよりも、なにかのツール（例えばCGI）を介してブラウザーにデータを提供するのも手なのではないだろうか。むろん、自分の手元で強引にメディアタイプを書き換えられる強者は別。そういう人は開発者だったりそういったデータの勉強をしている人だろうから。
そして、メタデータにアクセスするクライアントは、専用クライアントもそうだしCGIもそうなのだが、できる限り本来期待されるメディアタイプのリクエストを投げ、それに対する処理を用意しておくこと。また、万が一サーバーが本来期待されるメディアタイプのリクエストに応えられない場合に備えて「*/*」も用意しておく、などをしておくのがいいのかも、と思ったりする。
とは言え、その専用クライアントさえも対応状況が悪いとなると頭を抱えるしかなかったりして。例えばFoaFだが、おいらは公開後数日間は、このファイルをapplication/rdf+xmlで送出していた。この期間中、foafnautからおいらのFoaFデータを捕捉できなかった。application/xmlに変更することで、ようやくこのアプリケーションからおいらのFoaFを利用することができるようになったのだ。ここは日本語の表示に対応していないので、なんかいろいろ言ってやりたい気はするんだが、早まるなということでしばし静観。日本人による日本人向けのサービスとか、なにか兆しは見えないのだろうか。
ちなみにオペラなんだが、オペラ7が出始めた頃にapplication/xhtml+xmlでデータを送出していたんだが、スタイルシートが外れやすいような気がしたので対応をやめてしまったという経緯がある。タイムアウトまでのタイミングがtext/htmlとapplication/xhtml+xmlとで異なる可能性もあるんだが、真っ先にtext/htmlを要求するのは自信がないからだったりして（￣△￣；。ま、んなこと言っても「*/*があるから問題ないだろ」で片づけられてしまいそうですが。当のオペラソフトウェア自身がXHTMLメディアタイプの普及度を理由に当初XHTML 1.1で記述されていたコンテンツの送出をtext/htmlで行うと宣言していたし、その後XHTML 1.0 Strict準拠に変更したという経緯があったわけで。ちなみに多少品質が劣化していることを示す「q=0.1」つーのは、どこにかかってくるんだろう？
どれくらいおいらのイメージと差があるか、またうれしい誤算があるか、いろいろですが、すぐに実現してしまうPiroさんはタダモンじゃねぇよ（￣△￣；。こういうのって誰が先に作ったとかよりも、どちらかと言うとどれくらい早く使いたい人の近くに露出させるか、のほうが実は大事だったりして（著作権無視や特許の横取りはイカンが）。
モジラ ファイアーバードでミニさとみかんが使えるようになってしまう辺りは明らかに「誤算」系かと。
最初にその存在を知ってから、もう随分経ってしまった。RSSのデータをニュースディスカッション用のプロトコル「nntp」に乗せて配信するためのブリッジソフトに「nntp//rss」というのがある。ウェブよりもメールを中心にネット生活している人に、効率良く情報を手に入れるためのツールとして考えてもらった方がよさそうだ。
ソフトを使うにはJavaの実行環境およびアドミニストレーター権限が必要。Mac OS Xの場合、どこかパスの通るところに置いておいて、コマンドシェルから「sudo java -jar nntprss-start.jar」を実行する。nntprssが起動したら、ブラウザーを起動して「127.0.0.1:7801」を入力して管理画面にアクセスする。
ここが管理画面になっているので、収集するRSSのアドレスを指定してあげるわけだ。これによって、nntprssがRSSクライアントとなり情報を収集しはじめる。その間隔は10〜120分の間で10分ごとに調整可能。あとはNNTPクライアントからこのブリッジのアドレスを指定すればいい訳だ。RSS 1.0対応コンテンツなら、きちんとrss:item要素の中身まで表示される。
メールソフトのインターフェースを利用できることで、情報をメールソフトに集中できる利点はあるが、ひとつ受信日時がnntprssがRSSを取得した時間になってしまうが気になる。どの順番に記事が発行されたかを気にする立場から言えば、発行順にソートしてほしいんだなー。dc:date要素に日にち情報はあるが時刻情報がないのでしょうがないんだが。
![[Valid RSS]](/common/valid-rss.png "Validate my RSS feed")
![[Valid XHTML 1.1]](/common/noa.png "This page is Valid XHTML 1.1")
