眞鍋さん、どうやらワードで書いた文章のテキストデータをそのまま貼り付けているらしい。文字の色指定とか文字サイズとかはタグで指定しないとブラウザ上では表現されないので、そのまま貼り付けても単なる文章のテキストが表示されるだけになる。
眞鍋さんのようにWYSIWYG方式で編集したいのであれば、前回の記事で紹介したPerformancing使えばそんな悲しい思いはしなくてすむのだが、どうやらまだお試しいただけなかったようだ。残念（まあある意味当然だが）。
先に画像のUpだけブラウザで普通に行えば、あとはUpした画像のURLを指定さえすれば何とかなるハズ。FirefoxとPerformancingだとブログ編集が気楽に使えるので、一度試してみることをお薦めしたい。
| 固定リンク
| コメント (0)
| トラックバック (0)
ココログのあまりの重さに、眞鍋かをり氏も更新作業中に書きかけの長文記事を飛ばしてしまったらしい。嗚呼、あのツールを使えば助かったのに。
というわけで、書きかけのブログ記事を飛ばしたくない人におすすめの、Performancing for Firefoxを紹介しよう。
Performancing for Firefoxはブラウザ上にブログ編集ツール機能を追加してくれる、Mozilla Firefox用の拡張機能だ。
Performancing for Firefoxでは、書きかけの記事もそのまま保存ボタンを押すだけでPCに保存してくれる。PCに保存した記事を呼び出すのも簡単で、複数の記事を切替ながら書くことも出来る。編集画面はテキスト方式・WYSIWYG方式をボタン切替で選択できる。プレビュー機能も用意されている。また、ブラウザの画面を上下に分割した状態で編集操作ができるので、参照中のWebページとの同時に表示出来て便利だ。実際、タブブラウザであるFirefoxとの組み合わせはかなり使い勝手がいい。
Firefox でBlogを書けるエクステンションの記事がきっかけで各所で結構評判になっているので、当方でも試してみたが、簡単に使えた。これを使えば記事を飛ばすなんてこともなくなるだろう。
眞鍋さんにはFirefoxとセットでお薦めしたいツールだ。
なお、インストール後にはブログの種類に合わせた簡単な設定が必要になる。ココログでの方法については あそびやさんの記事が詳しいので、設定方法はリンク先の記事を参照してほしい。
Performancing for Firefoxのインストールについては、Mozilla公式サイトであるFirefox Addons内のPerformancing for Firefox配布ページから行うのがよいだろう。
追記：追記が出来るかをテスト。
追記その２：追記は出来た。
追記その３：画像のアップはFTPで行わなければならないようだ。ということはココログでは画像のアップは無理？
追記その４：トラックバックはPublishing Optionsから設定可能。トラックバックを複数打つ場合にはカンマ区切りで行う。（参考：Performancing - ドラフト機能、トラックバックなどが追加 — OpenStratus Archive）
| 固定リンク
| コメント (0)
| トラックバック (1)
いくつか書きかけの記事があるのだが、それよりも先に指摘すべき内容なので書かせていただく。
@niftyは
一番問題なのは、画像認証を導入した事で視覚障碍者をブログのコメントから排除する状況を作り出してしまったことである。アクセシビリティの観点から見て、これは改悪といわざるおえない。しかもどちらかというと劣悪な部類である。
ココログで導入されている画像認証は一般的にはCaptchaと呼ばれる手法であるが、画像内にある文字を目で読んで書き込むことで認証を行うため、画像を読むことができない視覚障碍者は認証作業を行うことができない。そのため結果としてサービスから視覚障碍者が排除されてしまうという問題が発生する。
この手法については過去にもGoogleやYahoo!などでユーザー認証の際に導入され、視覚障碍者から抗議の声が何度も上げられている。大きな問題としてニュースでも取り上げられたことがあるので、仕事上ユーザビリティやアクセシビリティに関わりがあるような人にとっては既に知られている事といってよいものである。
ITmedia News：アクセシビリティに扉を閉ざしたままのGoogle (1/2)
ITmedia News：アクセシビリティに扉を閉ざしたままのGoogle (2/2)
大規模サイトに潜むアクセシビリティの落とし穴：ITpro
@niftyクラスの企業にはおそらくユーザビリティやアクセシビリティの専門家もいるはずだが、なぜこの手法をブログのコメント欄に採用したのだろうか？
Captcha - Wikipediaにも解説があるが、「Captchaは機械可読ではないように設計されているので、スクリーンリーダのような一般的な支援工学のツールでは解釈できない。」という現状がある。視覚障碍者がスクリーンリーダを使っても認証作業を行うことができないのだ。
また、「Captchaが視覚的である必要はないが、現実問題として音声(聴覚)Captchaの開発は画像(視覚)Captchaよりも後れを取っているようなので、現状では有効ではないかもしれない。」という現状も指摘されている。
Yahoo!やGoogleではこの問題の解決方法として電話オペレーターによる認証作業代行を採用していると記憶しているが、ブログのコメント欄でこの方法を取るのは現実的だろうか？
ブログのコメント欄はYahoo!やGoogleのアカウント認証とは異なり、認証用のアドレスも一意ではないはずなので、一々どのブログのどの記事にコメントしようとしているのかをオペレータに教えなければならないといった手間がかかる。またブログの書き込みはアカウント認証と比べても圧倒的に数が多い。記入数などを考えてもオペレータに頼る手法は現実的ではないだろう。
つまり、現状の仕様ではブログのコメント欄に画像認証を採用されると視覚障碍者は手も足も出ないことになる。
このように著しく視覚障碍者の発言権を阻害し、アクセシビリティを低下させる手法であることは明らかである。にも関わらず、この仕様を続けるのであれば、@niftyの企業としての見識も問われることになる。
@niftyの親会社である富士通はユーザビリティやアクセシビリティへの取り組みやツールなどの成果を公開しているが、こういったことが起きると親会社の姿勢まで疑われることになりかねない。
もっとも、他の認証方法が無いわけでもない。Captcha - Wikipediaに書かれている内容に次のようなものがある。
何かのテキストの意味を理解するような、他の種類の課題もCaptchaとして用いることができる。例えば、論理パズルや常識問題、パスワードそのものでなくバスワードの構成法を教える、などである。
それ以外についてもいくつか方法が考えられるとは思うが、いずれにしても特定の条件を持ったユーザーを排除することは避けなければならないので、複数の方法から選択できるようにするなどの工夫が必要になる。
物作りの経験をもつ古河社長であれば、こういったことはよくお分かりのことかと思う。であればこそ、ユーザの視点で見る習慣を思い出していただきたい。
Crossing Fingers／クロッシングフィンガーズ: セキュリティとアクセシビリティでも言われているが、「できれば安易に導入するのではなく、誰もが使えるセキュリティシステムを目指して欲しいと切に願う。」という言葉を念頭に置きつつ、早急に改善策を導入していただきたいと願うものである。
他ブログの関連記事：
豆雷太 記: 当ブログをご覧いただいている皆様へ（長文）
空とぶ海猫亭: コメントの逐次検証は不要etc.
世の中は不思議なことだらけ: 新ココログのスパム対策
追記：ココログスタッフの方々へ。当然であるが、ココログには視覚障碍者と思われる方のブログも存在する。今回の改悪はそういった方々の権利も阻害しているといったことを忘れないでほしい。彼らも大切なユーザーなのだから。（※なお、私自身は健常者である。）
2006年4月3日：追記
| 固定リンク
| コメント (5)
| トラックバック (2)
先日の記事で書いた「眞鍋かをりのココだけの話」の表示問題だが、HTMLの表示は正常に修正された模様。感謝。ただし、RSSの不具合はまだ未修正の模様。
で、 トラックバック先の記事を見て思ったこと。眞鍋かをりはライオンキングに出演したいのだろうか？いや別にいいんだけど。
追記：解決したと思ったが、古い記事はいまだ正常に表示されず。デザインの再適用をさせていないのでは？
| 固定リンク
| コメント (0)
| トラックバック (0)
以下は「眞鍋かをりのココだけの話」の運用担当者に読んでほしい話。
「眞鍋かをりのココだけの話」にある個別の記事をMozilla Firefox 1.07で見ると、デザインが崩れてしまっている（トップページでは問題無いが、個別の記事では症状がでる）。また、記事の下の表示されるトラックバックの一覧を見ることができない。以前のデザインでは問題なく見れていたのとは雲泥の差だ。CSSの書き方の問題のなのか確認していないが、デザイナーはFirefoxでの表示確認ぐらいはすべきだと思う。
同様の問題はRSSの出力にも見られる。同ブログのRSSは眞鍋かをりのココだけの話 powered by ココログ - by Rssadに転送されるようになっているが、「channel rdf:about」の部分でURLが指定されているにもかかわらず、Firefox用のRSSリーダーであるSageで読み込むとURLがローカルに飛ぶ形になっており、channel rdf:aboutの指定が正常に機能しなくなっている。xslによるスタイルシート指定をとっている関係もあるのかもしれないが、同様の手法を取っているbk1のRSS配信サービスでは問題が起きていない事を考えると、指定の仕方がおかしいだけとしか思えない。
ココログ フリーの写真にも見られるように、「眞鍋かをりのココだけの話」はココログの顔とも言える存在になっているのだから、こういう細かい部分にも気を配ってほしい。
なお、直接の関連は無いかもしれないが、眞鍋氏のブログだけだと担当者に読んでもらえるかどうか不安が残るので、古河社長のブログとココログスタッフのブログにもトラックバックを打たせていただく。あしからずご了承ください。
追記：「相手先のトラックバックURL を入力」からいつまでたってもトラックバックが消えないので（ココログのサーバが重いのか？）何回もやりなおしたら、真鍋氏のブログにトラックバックが沢山送られてしまった。どうもすいませんm(_ _)m。
| 固定リンク
| コメント (0)
| トラックバック (1)
以前にも記事で触れているが、＠niftyがハッキリと認識すべき問題だと思うのであえて書かせていただく。迷惑メールフォルダーの学習フィルタは日本語メールへの対応度を改善すべきだ。ＭＯＯＣＳ ＬＡＵＮＣＨ ＰＡＲＴＹは楽しそうだが（※サービス開始おめでとうございます！）、できればそちらにばかり力を入れていないでこちらも改善してほしい。
以下はその理由。
11月現在、スパムメールブロックを解除した状態で迷惑メールフォルダーを利用した場合、日本語の迷惑メールに関しては相変わらずのすり抜け状態が続いている。
11月1日から11月10日の間、スパムメールブロックを解除した状態で迷惑メールフォルダーを利用してみた。なお、学習フィルタの学習内容を一度リセットしてから、迷惑メールフォルダーに溜まっていた1800通ほど迷惑メールを再学習させてある（再学習させた迷惑メールにはスパムメールブロックを使って弾いていたものも含めてある）。
※日本語の迷惑メールは全てinfo＠系（関連記事）。
※日本語以外の迷惑メールは全て中国語のもの。半数以上は基本フィルタでの対応？
※すり抜けた迷惑メールに関してはその都度再学習を行っている。
※＠niftyの迷惑メールフォルダーではSymantec提供の基本フィルタも動いている。
迷惑メールフォルダーに溜まっている迷惑メールが全て学習フィルタ（＠niftyの場合はベイジアンフィルタを採用）によりフィルタされたものと仮定しても（実際はSymantec提供の基本フィルタによって振り分けられる迷惑メールの方が多い）、ベイジアンフィルタを通った日本語の迷惑メールのうち20％近くはすり抜けてきている事になる。すり抜けてくる率を考えても、日本語の迷惑メールに対しベイジアンフィルタが有効に動作しているとはいえないだろう。すり抜けてきた迷惑メールを再学習させても、数日後に同じ文面の迷惑メールがまたすり抜けてくるのだから性質が悪い。
迷惑メールフォルダーのメール受信状況 （2005/08/13～2005/11/10）
※基本フィルタで検出した迷惑メールが途中から激増し、間で激減している部分があるが、これはスパムメールブロックによるフィルタ（内容については関連記事を参照）を10月半ばに一旦解除しているため。
一般的な話になるが、英語の迷惑メールの場合、ベイジアンフィルタを使わなくても90%程度のスパムを弾くことができ、ベイジアンフィルタをすると98％程度までブロックできるらしい。であれば、日本語迷惑メールであっても、日本語に対する実装がきちんとしていればそれに近い数値になるはずだ。
ではなぜそうならないのか？これには日本語特有の問題が関係してくる。
ベイジアンフィルタではデータを最小単位の単語に分解してから統計処理をするのだが、スペースで単語を区切る英語とは異なり、日本語では単語を区切るための印がない。そのため、そのままベイジアンフィルタにかけても適切な統計処理を行うことができない。
この問題を解決するためには日本語の文章を適切な形に分解してからベイジアンフィルタに流し込む必要がある。日本語を適切な形にする方法としては下記のいずれかの方法がある。
POPFile: JP FrequentlyAskedQuestions/LearningDifferenceによると、１はPOPFileで、２はscbayesで、３はMozillaで使われている方法だそうだ。
このように適切な形に分解する処理を入れることで、日本語の迷惑メールであってもベイジアンフィルタ上で適切にフィルタされるようになるわけだ。
個人的な感想だが、この中でフィルタ精度が一番高くなるのは形態素解析を利用する場合ではないだろうか。実際、形態素解析にKAKASIを採用するPOPFileでは98％程度の振分け精度を確保している。日本語と英語の違いを考慮したとしても優秀な数値と言える。
※POPFileにはこの他にもBase64エンコードの日本語メールも処理可能な様になっている（詳細は関連記事を参照）など、様々な工夫がなされている。振分け精度の高さはその辺りも影響しているので注意。
＠niftyでどの方法を取っているかはわからないが、以前から英語の迷惑メールはかなりの高確率でブロックしているにも関わらず、日本語迷惑メールは相変わらずすり抜けてくる。すり抜けてくるメールの割合を考えると、日本語周りの実装が適切になされていないとしか言い様がないだろう。
ところで＠niftyの迷惑メールフォルダーにおいて、学習フィルタ（ベイジアンフィルタ）はどのような位置付けなのだろうか？
＠niftyの迷惑メールフォルダーではSymantec製の基本フィルタとベイジアンフィルタを組み合わせる形でサービスを提供している。迷惑メールの情報がSymantecのデータベースに追加されると基本フィルタでブロックされるようになる。が、ユーザーからSymantecに迷惑メールのデータが提供されてもデータに反映されるまでのタイムラグがあるのだろう。11月に入ってからも、2～3日程度の間に全く同じ文面の迷惑メールが複数すり抜けてきた。
普通に考えると、ユーザーから提供されるデータが基本フィルタに反映されるまでの間は代わりにブロックするのが学習フィルタの役割のはずだ。それなのにベイジアンフィルタが日本語迷惑メールを処理できないため、ユーザーにいらぬ負担を強いる事になっている。
データバックアップメモ - extended -: 「info@～」で始まる迷惑メールへの対処法 in @niftyで方法を紹介しているように、スパムメールブロックを使う事でブロックできる場合もあるが、それとて初心者ユーザーには設定すらできない場合があることを考えれば、とてもまともな解決策とはいえない。実際、ココログに投稿されているユーザーの意見をみても、迷惑メールフォルダーをすり抜けてくる迷惑メールに腹を立てている人が非常に多い。
基本フィルタがあるから大丈夫、スパムメールブロックがあるから大丈夫、ではないのだ。
＠niftyは早急にベイジアンフィルタの日本語周りの実装を見直してほしい。
| 固定リンク
| コメント (0)
| トラックバック (1)
以前書いた記事でも言及しているが、迷惑メール対策として＠niftyが提供している「迷惑メールフォルダー」という迷惑メール対策サービスを使っている。この迷惑メール対策サービス、以前は日本語の迷惑メールに対して無力だったのだが、6月に＠niftyが追加したSymantec Brightmail AntiSpamのおかげで日本語迷惑メールに対しても機能するようになった。ところが、8月になって増えだした「From:info@～」で始まる日本語の迷惑メールはBrightmail AntiSpamの基本フィルタもすり抜けてくるではないか！
迷惑メールフォルダーがダメなら個別指定のフィルタで対処するしかない。というわけで、＠niftyが提供する「スパムメールブロック」を利用して「info@～」の迷惑メールに対処する事にした。
「スパムメールブロック」ではフィルタ設定の機能が８月に強化された。具体的には、メールヘッダー全体がフィルタの対象になり、任意のヘッダが追加できるようになった。また、「ワイルドカード」と呼ばれる機能も追加されている。ワイルドカードでは、「*」が任意の長さの任意の文字を、「?」が任意の1文字を意味する。今回はそれを利用して「info@～」ではじまる迷惑メールをブロックすることにした。
ただ、このワイルドカードによる指定をFromにそのまま適用してしまったのでは、必要なメールまでブロックしてしまいかねない。おまけに「info@～」の迷惑メールでは＠の後ろが毎回違うので、個別のアドレスで拒否指定しても無意味である。何らかの工夫が必要になる。
改めて「info@～」迷惑メールに関する情報を調べてみたが、メールヘッダのReceivedに記録される送信元のIPアドレスも頻繁に変わっていた。IPドメインサーチ等を使って調べてみたが、韓国や中国のレンタルサーバなどを大量に使っているようだ。知人が海外からメールを送らないとも限らないので、できれば国ごと全部拒否するのは避けたい。
さらに「info@～」系の迷惑メールでは、メールヘッダのReturn-Pathにも「info@mail.～.com（または.net）」と追加されているようだ。本来、Return-Pathは受信サーバで付けられるものらしいので、Return-Pathも偽装の対象のはずだ。が、何故かここはパターンが変わっていない。
そこでスパムメールブロックのヘッダの種類にReturn-Pathを追加して、ワイルドカードで「info@mail.*.com」「info@mail.*.net」と指定してみた。これでReturn-Pathに「info@mail.～」が含まれるものを迷惑メールフォルダに振り分けるようになるはずだ。とりあえずパターンを変えられるまでの対処療法でしかないが、やらないよりはましだろう。
あとはReceived:にある個別のIPアドレスを指定していくのが常道だが、その辺りのやり方はぞうさんちv3の記事が参考になる（スパムメールブロック設定、スパムメールブロック設定 2005-08-09を参照）。
ちなみに、Yahoo!で取得したメールアドレスにも「info@～」の迷惑メールは来ているが、こちらは以前書いた記事で紹介したPOPFileで対処している。POPFileの場合、「info@～」の迷惑メールはほとんどが検出されている。どうやら日本語迷惑メールに対する検出率はPOPFileの方が高いようだ。＠niftyの迷惑メールフォルダーも、日本語メールに対する学習フィルタの精度を上げる余地がまだあるように感じた。
2005年09月12日追記：
2005年09月12日追記
2005年09月12日追記
2005年09月13日追記
2005年09月18日追記
2005年09月18日追記
2005年09月20日追記
Norton、役立たずかー！？ヽ(*｀д´)ノだと思います（キッパリ）。
2005年09月21日追記
2005年09月22日追記
2005年09月23日追記
2005年09月25日追記
2005年09月27日追記
2005年09月29日追記
2005年10月01日追記
2005年10月02日追記
2005年10月06日追記
2005年10月09日追記
2005年10月10日追記
2005年10月16日追記
| 固定リンク
| コメント (19)
| トラックバック (8)
古河社長のココログ新年会に関する記事には既に関連のトラックバックが多数ついているのでご存知の方も多いかと思うが、ココログブックスコンテストの件で問題が起きているようだ。
当方は当事者ではないので、どういった問題なのかは悪徳不動産屋の独り言: ｎｉｆｔｙへの公開質問状や新年会の参加者が書いている各所の関連の記事を読んでもらったほうが良いだろう。各記事を見れば分かるかと思うが、審査員講評などその後の展開を見ているとどうも@niftyは内向きの都合で対応してしまい、火に油を注いでいるように思える。
この対応をみて思い出したのが、昨年6月頃にあったココログ絶不調時の出来事だ。当方でも関連する記事を書いて古河社長のブログや多数のブログにトラックバックを打った。結構大規模なトラブルだったので、当時のことを覚えている方も多いかと思う。@niftyは当初満足な対応も無く火に油を注いでしまったのだが、その後の対応で随分と印象が良くなった事を記憶している。トラブルが解決した後に書いた記事では文中で下記のような内容を書いた。
古河社長のWeblogにココログのトラブル対応についてのお詫びが掲載された。文面的には形式的なものに近いが、今回のレベルのトラブルに対する対応としてはかなり異例の対応ではないかと思う。個々の対応では不満の残る部分もあったかとは思うが、私個人としては概ね満足できる対応であった。寝食を惜しんでトラブル対応をしていただいた方々にお礼を申し上げたい。と共に、勝手かとは思うがお願いをいくつか。
一番お願いしたいのは、システムの問題だけではなく、トラブル対応も含めていろいろと指摘された内容について一つづつ検証をしてほしいということだ。今回の問題は、ただココログのデータベース担当者を責めれば済むという問題でもないし、誰かに責任を押し付ければそれで済むという類の問題でもない。現場には分かりきったことではあるだろうが、責任を押し付けただけでは何も変わらない。
何人かの方が言われていたが、昨今社会問題にもなっている「三菱のような……」という例え方をされるということは、ユーザーがそれだけ@nifty の対応に対して同種の悪い体質を感じているということでもある。つまり、次にトラブル時の対処で同じ事をやったらもう後が無い、と感じさせてしまったということだ。そう思わせた原因が社内にあるのであれば、検証し改善するしかない。時間がかかるかもしれないが、今後同様のことが起きないように「なぜこのような対応をすることになったのか、なぜこのような結果になったのか」その過程と原因を突き止め、確実に改善していっていただきたい。
今回のトラブルで参加者の方々が述べている要望にも通じる部分があると思うのだが、どうだろうか？そして、参加者やその他ユーザーに対しての説明が必要なのも同じだ。当時はこんな一文を書いた。
今は臭い物に蓋をしてもすぐに見つけられてしまう時代なのだから、絶対に説明を端折るべきではない。トラブルの後こそ、ファンを作るチャンスなのだから。
大変だとは思うが、がんばって改善してほしい。
コミュニティにおけるトラブルという意味では同様に蓋をする事は出来ないだろうし、蓋をすれば火に油を注ぐ事になるのは間違いないだろう。はたして今回@niftyはどう対応するのか、注視したい。
| 固定リンク
| コメント (0)
| トラックバック (1)
昨年末に史上まれに見る大規模な被害をもたらしたスマトラ沖地震だが、各所で既に募金などのチャリティが始まっている。今回は他よりも多少動きの遅かった＠niftyだが、プロバイダのトップページで公開されているようにスマトラ沖地震被災者支援チャリティーコンテンツが始まっているので、募金をしたい＠niftyユーザーはぜひアクセスして欲しい。
ちなみに古河建純 インターネットBlogではまだ触れられていないようだ。というわけで、一応トラックバックを打っておく。
追記：「被災者支援の輪を広げるため、趣旨にご賛同いただける方は、 このページにリンクをお願いします。」と記述するならば、リンクを張るためのタグを指定しておいた方が良いのではないだろうか。
追記２：@niftyでスマトラ沖地震チャリティー公式ブログなるものが始まっているようだ。
| 固定リンク
| コメント (1)
| トラックバック (1)
古河建純 インターネットBlogがデザインを新しいテンプレートのものにしたらしいのだが、Windows2000SP4環境下のFirefox1.0で見ると犬の絵が半分ほど隠れてしまう。正確にはフォントサイズをかなり大きくすれば犬の姿は出てくるのだが、いささか大きすぎる。フォントサイズに関係なく犬の姿が見えるようにならないものだろうか。犬好きの人間としては切にお願いしたい。
ところで、ココログはFirefoxへの対応度ではWeblogサービスの中でも割と良い方に分類されると思うのだが、それでもこういうことが起きるというのはどうしてなのだろうか。おそらくコンテンツ作成側の事情というものに関係しているのだろう。
ここ1～2年、市場でのブラウザのシェアはWindows OS上のInternet Explorerがその8～9割ほどを占めてきた。コンテンツ作成者も市場シェアに合わせておけば文句をいってくる人の割合は少なくて済むので、あとは過去にブラウザ戦争を繰り広げたNetscapeの旧バージョンを多少フォローしておけばよかった。が、最近のFirefoxの登場でシェアの割合が急激に変わりつつあるため、そうもいっていられなくなってきた。
Internet Explorerでの表示を優先するというのは市場における「現在のシェアのみ」を考えれば当たり前である。だが、本家サイトで見られる変化やNDO::Weblogの記事で指摘されているような状況がおきつつある以上、デファクトスタンダードなブラウザであるInternet Explorerを優先する方法では早晩修正にばかり時間を取られる事になるのではないか。
NDOの記事へのコメントで「WEBスタンダード準拠のサイトを作る場合はまず準拠しているブラウザで最適化するのが重要」といったことが指摘されている。また、先にIE優先でコンテンツを作成してしまうよりもWEBスタンダードに準拠したブラウザで最適化してからInternetExplorerでも綺麗に表示されるように修正した方が結果的に工数が少なくて済むのでは、といった提言も他所で目にしたりする。つまり、今までのやり方では上手くいかなくなりますよ、という事なのだろう。
公的な分野でも、経産省が調達ガイドライン作成の中で「IEでしか読めないページ，Windowsでしか使えないシステムは不適」（IT Pro ニュース）と述べるなど、世の中の方向性も明らかに変わりつつある。ちなみに、Mac版のInternet Explorerは既にサポート期間が終了している。こういったことも上のような動きに少なからず影響を与えているのではないかと思う。
そういう空気が当たり前になりつつあるのであれば、大手プロバイダのサービスといえども調達ガイドラインと同じ方向に動くのが自然というものではないだろうか。既にgooなどではオープンソース･ソフトウェアへの対応を積極的に推進する動きも起きている。健全な競争を生み出す意味でも、また事業者側のリスクを減らす意味でも、特定の環境に依存しないよう、提供サービス全体での対応見直しをお願いしたい。
| 固定リンク
| コメント (0)
| トラックバック (0)
最近のコメント