特定ブラウザ依存性への挑戦「TouchUpWeb」プロジェクト 48
ストーリー by kazekiri
nitonito曰く、"最近はウェブアプリケーションによる業務システムが主流を占めているようですが、皆さんの職場のシステムは特定ブラウザに依存してませんか? 世の中には特定ブラウザに依存したサイトが多数存在しています。そしてこのことが、LinuxなどOSS環境の普及を妨げる要因のひとつになっています。 (株)三菱総合研究所、Mozilla Japan、(株)アルゴ21により開発されている「TouchUpWeb」プロジェクトでは、このような阻害要因へのアプローチとして、動的に依存箇所を訂正するという方法を採用しています。現在は、Firefoxの機能拡張と、Mozilla Japanに設置した配信サーバによる運用形態です。これは、先日ここでも話題になった「Japanize」と似た仕組みなので、それとは異なるいくつか特徴を挙げてみます。(本文続く)
- プライバシー保護の観点から、常にユーザの明示的な操作によってのみ、サーバにアクセスする。バックグランドで自動的に通信が発生することはない。
- 編集にはGreasemonkeyを使用しているため、サイトアクセスのたびにサーバにアクセスすることがない。
- 配信サーバへのスクリプトの登録はコミッタに限定することで、不正なスクリプトの混入リスクを極力抑え、質を担保する。
- 作成段階のスクリプトの検討は、現在はBugzillaを利用したバザール方式。
- マスター−スレーブ構成により、サイトに運用サーバを設置し、サイトごとにスケジュールされた間隔でサーバを最新状態にアップデート。
- マスターサーバもサイト内で完全独立で運営できるので、イントラネット用のサーバ運用などにも使える。
もともと、学校教育関係サイトや自治体システムのブラウザ依存性に対する問題提起から始まったこのプロジェクト、OSS環境普及に役立つことを期待しています。 なお、TouchUpWebプロジェクトでは、スクリプト作成やシステム改善のために、プロジェクトメンバーを広く募集しています。"
IE依存サイトが増えるだけのような気がするよ (スコア:3, すばらしい洞察)
Re:IE依存サイトが増えるだけのような気がするよ (スコア:2, 興味深い)
なにしろ作成者の母集団が違うので、現状は「シェアが数パーセント減った増えた」というのはIEにとって意味のあるレベルではなく、すでに安全な状態でエコシステムを構成している状況だと思います。
今こういう動きに対して懸念されるシナリオは、「IE6と今度出る予定の7ではレンダリングが違う」ことで、7が発表されてしばらくはそれに話題を取られ、せっかくのキャンペーンに水を差す結果が生じるのではないかということでしょうか。
(他のブラウザを全くチェックしない人々も、意図した見え方をしなくなるケースではこの問題に取り組まないといけないため、結構大きな話題になるはずです。)
今打てる手としては、そういうゴタゴタに巻き込まれない、いわゆる搦め手を狙い、そのうちに本流に還元していくためのインフラストラクチャを作ることではないかと思います。
例えば、まだ「これを使えば問題ない!」という完成品の存在しないWISYWIGエディタ、またはBLOGシステムなどの、HTMLジェネレータの類。
私は積極的には使いませんが、世の中の大半の人々は「何かしらのテキストと画像を与えるとHTMLを吐き出すプログラム」に頼っています。
こういうところが出力を直さない限り、「書いたものがどういうHTMLになっているのか」すら分からない人が多いんじゃないかと思いますので、自力修正は望めないでしょう。
単品のオーサリングツールとしては、市販品はもとより、Kompozerぐらいまでは試してみましたが、「主に日本語環境で問題なく使用できる」という観点も加えると、標準で安心して使えるものはまだ見たことがありません。(もし知っていたら教えてください)
また、いわゆるアベレージな人々がIE(またはブラウザスイート製品であるOutlook Express)から乗り換えるためには、「設定すればいい」のではなく、「すべてが未設定のままで必要な機能を呼び出しできる」ことが重要です。
「動く環境」で設定を変更することができる人は、詳しくない人の中にもたまに現れますが、「動き出す前に諸設定が必要なもの」にチャレンジする人は非常に少ないためです。
しかし、「欲しいガジェットがソフトウェアと組み合わせられている場合に限り、そういう障壁が突然取り払われる現象もあります。
したがって、iTunesなどは数年前は誰も知りませんでしたが、いまではメジャーソフトウェアとなっています。Microsoft製品にはQuickTimeはあったかもしれませんが、最初からiTunesをインストールして販売しているのはまだ見たことはありませんから、何らかの手段でインストールを実施した
「一般人が欲しがるものを見つけて付属させる」ことを続けると、話題は自然についてきます。また、そういうサイトが「標準に準拠しつつ、IEではきちんとレンダリングされないサイト」でも何の問題もありません。
さらに別の観点からは、「表示互換性に乏しいWEBサイトを補正し、互換性を向上させる」目的でのデファクトスタンダードというものもありだと思いますが、まだそういう製品を知りません。
これはサーバからクライアントのどのレイヤで実装されてもいいわけですが、著作権のほうであれこれ言われそうなので、「IEやWindows以外で良好に」という言葉を外し、単純に「アクセシビリティのための業界標準」として、表示するにはそれなしには済まないようにするという、いわゆるクローズドキャプションのような強制力が生じる状態にしてしまうのも手だと思います。
時代はユニバーサルデザインなので、閲覧者を選ぶようなサイトはそのうちに時代遅れになるでしょうし、突然視力が弱くなったら、拡大して読まないと無理なことだってありえますので、デザインの変更を拒否するようなサイトを、いまのうちに啓蒙しておくべきでしょう。
もはや「対Windows」を意識すると低レベルな争いになる懸念がありますので、ターゲットはもっと高いレベルにおくべきだと思います。
そこから、もしかしたらGoogleのようなムーブメントを起こせるかもしれません。
Re:IE依存サイトが増えるだけのような気がするよ (スコア:0)
「みれなーい」
「何で? 他にそんなこという人いないよ?」
「ネスケだと見えないんだよ! 直せよ!」
「(……ウザ)」
↓
「このページはIE3以上で動作確認しています」
# もう「ブラウザは寛容たるべし」の時代じゃないのかねえ
Re:IE依存サイトが増えるだけのような気がするよ (スコア:0)
非IEな人たちの心配をしなくて済むんだからラッキーよ。
これは問題ないでしょ? (スコア:1, すばらしい洞察)
これは依存してても何の問題もないでしょ?
社内システムで多数のブラウザで動作確認する必要は、外注にせよ内部開発にせよ
工数を増やして無駄な経費がかかるだけ、社内の標準とされるブラウザで動けば十二分でしょう、
Re:これは問題ないでしょ? (スコア:2, すばらしい洞察)
私が携わったWeb系システムは全てそうなってますな。
まあ、実際試したら動くとは思いますけど保障はしない、と。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:これは問題ないでしょ? (スコア:1, 興味深い)
丁度それって、IEだと気軽にできてFirefoxでは面倒なとこなんですよね。
上記の場合、今まではIE限定とさせていただいてました。
そのうち、「Firefoxでもいけるようにしてよ」といわれないかヒヤヒヤしている私には嬉しい取り組みですねぇ。
Re:これは問題ないでしょ? (スコア:1)
Re:これは問題ないでしょ? (スコア:1)
社内システムだから、特定環境以外では動作確認しなくてもいいです。動作保証ブラウザじゃないんだから、サーバークラッシュ以外の不具合があっても許します。うまく動かなくても、報告できて、次のシステムでちょっと考慮してくれれば、現時点での対処はあきらめましょう。次のシステムで「それなりに配慮したつもりだけど、動きませんでした」も許します。でもブラウザ違うって弾くのは止めてくれと思います。(/_;)指定ブラウザ以外を使う以上、そのリスクは分かっているのだから。余計なお世話です。
少し大きな会社だったら、対外向けには特定ブラウザに依存しないように作るはず(特にアメリカに展開しているなら)です。検証までするかはともかく、対外的なルールなりノウハウを社内システムにも適用するってのは、ものすごく難しくてコストががんと上がっちゃうものなのでしょうか?
# 全部場当たり的に外部に発注するんだったら納得。
HTMLなりその周辺ってそんな囲い込みのための規格じゃないと一応それらしいことを言ってみたら、どれだけ叩かれるかな。^-^
vyama 「バグ取れワンワン」
Re:これは問題ないでしょ? (スコア:0)
やってみて「動いた!」と自分でも驚きながら作ってるような奴が多いんじゃないか?
# 同じブラウザでもバージョン依存の問題が発生する事があることも知らなかったりしてね
Re:これは問題ないでしょ? (スコア:0)
「IE以外では表示できませんので仕様です」と
言い切る社内システム・・・指摘しても直す気ゼロ。
こんなんで工数削減ってもなあ。
Re:これは問題ないでしょ? (スコア:0, すばらしい洞察)
Re:これは問題ないでしょ? (スコア:0)
当然のように (スコア:1, すばらしい洞察)
#Operaとかw3mとかでだって見たいよ。
Re:当然のように (スコア:2, すばらしい洞察)
違います。FirefoxのFirefoxによるFirefoxのためのプロジェクトです。
参考: 現状の TouchUpWeb プロジェクトと Web 標準非準拠ページを準拠させることは別の話 [xrea.com]
基本的に対応は個々のブラウザがバラバラにやらなくてはなりません。OperaはOperaでuser.jsを使ってやってるわけです。たまたま他のブラウザの成果を流用できることはあるかもしれませんが。
なんでそんな無駄なことになってるのかって? そりゃ元のページがWeb標準を無視しているからですよ。Web標準に準拠したページなら、個々のブラウザはただ標準への準拠度を上げるだけで対応可能であり、不毛な努力は不要です。
Re:当然のように (スコア:1)
ただ、基本的なコンセプトが「ユーザースクリプトで修正してしまう」なので、前提にユーザースクリプト機能が使えるってのはしょうがないかも。
#w3mってそういった事できますかね?
でも、読んだ感じではプロクシサーバか何かでスクリプトを埋め込めば大概動きそうな気も。
Re:当然のように (スコア:0)
これもGreasemonkey構文を使っているようです。サーバはOperaが管理して、週1回のスケジュールでアップデートという仕組みのようです。
ユーザー JavaScript による制御 [opera.com]
Re:当然のように (スコア:0)
売り文句が間違ってると思う。
世にあふれている、(ある意味)古い規格のページを最近メジャーな規格にしてみるシステムとでも言ったほうがいいんじゃまいか。
Re:当然のように (スコア:0)
# 著作権の問題(同一性の保持とか)はどうなってるんだろ
Re:当然のように (スコア:0)
実際は「IE依存をFirefoxで解決」じゃない。
# 挑戦だから、今後は他のブラウザにも……と期待しておくか
また障害? (スコア:1)
Re:また障害? (スコア:2, おもしろおかしい)
そこでこのプロジェクトですよ!
# という仕込みだったらいいな。
CodeZine掲載の記事 (スコア:1)
「不完全なHTMLを動的にタッチアップ」 [codezine.jp]
KHTML (スコア:1)
Re:KHTML (スコア:1)
Swift [getwebkit.org]というプロジェクトで、Windows上でのWebKit利用ブラウザの開発がされていた (いる) そうです (ソース:Taken SPC : GetWebKit! [xrea.com])。まぁ開発は止まってるようですが。
Re:KHTML (スコア:0)
http://www.atmarkit.co.jp/flinux/special/cygwin2/cygwin02b.html [atmarkit.co.jp]
Re:KHTML (スコア:1, 参考になる)
相当ハイスペックなマシン上でも使い物になるとは思えません。
KDEがQt4ベースに移行すればWindows版も出てくるのかもしれませんけど。
KHTMLってコンカラでいいなら仮想環境にLinux入れとけばいいのでは。
だめぽな気がする (スコア:1, 興味深い)
> 不正なスクリプトの混入リスクを極力抑え、質を担保する。
で、サーバへの接続でSSL使ってないのはどういう冗談なのでしょうか?
Re:だめぽな気がする (スコア:2, 参考になる)
Re:だめぽな気がする (スコア:1, 興味深い)
Re:だめぽな気がする (スコア:0)
ブラウザ依存を無くすためには (スコア:1)
Re:ブラウザ依存を無くすためには (スコア:0)
Re:ブラウザ依存を無くすためには (スコア:0)
言葉の問題ですけど (スコア:1)
「特定ブラウザ依存性」の治療ではなく、「特定OS依存性」の治療でしょうね。
かなり大規模な組織で、かなり本気で代替OS導入検討をしてみない限り
こういう発想は出て来ないと思うなあ。
依存といってもいろいろ (スコア:0)
熱狂的に1つのブラウザを愛しつづける人の視線を
別のブラウザに向けさせてみるとか
そういう依存かと思いました。
#某ちゃんねるの専ブラに依存しまくってるのでAC
いやぜんぜん・・・・ (スコア:0)
おおよそ、タレコんだ人は、IEばかりで嫌気がさすといいたかろうが
それだったら、IE互換のモジュールを組み込めがよいだけ
別に妨げにはなっていない、ひとつの理由は
導入時に何を使おうかと決めてから使うからです。
その時点で、選ばれないブラウザーがあるとしたら
見合うだけの魅力がないだけのこと
Re:いやぜんぜん・・・・ (スコア:2, 興味深い)
あればね。MSが出してくれると良いのだけれど、たぶんそれはなさそうだよね。
自前で作れって言われても、それよりこの記事のシステムの方が手を付けやすいし、他に応用が利くかもしれないです。
ってか、目的より手段に興味あるな。
ユーザスクリプトの自動配信/更新システムって新しい可能性をもってそうだけど、安全性をどう確保するかってのは難しい問題だと思うので、その辺りどう運営していくのか。
そこらへんも含めてシステム化できれば違った目的にも使えるんじゃなかろうか。
Re:いやぜんぜん・・・・ (スコア:0)
> あればね。MSが出してくれると良いのだけれど、たぶんそれはなさそうだよね。
IETab [mozdev.org] とか、ありますよ。
Re:いやぜんぜん・・・・ (スコア:0)
Re:いやぜんぜん・・・・ (スコア:0)
依存しまくってます。 (スコア:0)
気になる情報漏洩 (スコア:0)
イントラネットでの利用には注意が必要かと。
#イントラネット担当からすれば該当サーバはブロック対象にしておいた方が無難か?
Re:気になる情報漏洩 (スコア:1)
スレーブのみの運用ではTouchUp情報の登録はできませんので、扱えるのは公開サイトだけです。このフィードバックは、TouchUpWebプロジェクトのサーバに送られますが、これを遮断することにどれほどの意味があるでしょうか。ユーザが故意にフィードバックとは無関係の情報を載せるという話なら、他にも簡便な手段がいろいろあると思われますがいかがでしょうか。
Re:気になる情報漏洩 (スコア:0)
イントラ内と外で使用感が異なるという説明をどこかに明示しておかないと
イントラ内だろうが外だろうが勝手に導入して「使えないぞ~」とか
前記の様な「セキュリティに問題は?」となるので、そこのとこ、明記しておくことを推奨。
> スレーブのみの運用ではTouchUp情報の登録はできませんので、扱えるのは公開サイトだけです。
> このフィードバックは、TouchUpWebプロジェクトのサーバに送られますが、
> これを遮断することにどれほどの意味があるでしょうか。
> ユーザが故意にフィードバックとは無関係の情報を載せるという話なら、
> 他にも簡便な手段がいろいろあると思われますがいかがでしょうか。
いや、単にフィードバックの中身が不明だと何が送られるか分からないというだけの話。
MSがOSやアプリでフィードバックを送ることについて、かなり神経を使って説明しているのを
参考にしましょう。いまは説明責任が問われる時代です。
いっそのこと公開プロキシにすれば? (スコア:0)
# Firefoxだけに依存させるのが悲しいですね。
IEがFirefox互換になればよいのに (スコア:0)
IEを単なるGeckoコンテナにしてしまうのだ。
そしたらFirefoxだけで動作確認すればよくなって、ちょー楽チン。
だめかなぁ?
プロジェクトの寿命 (スコア:0)
Firefoxの拡張は、お椀の上にコップを載せるようなもので、お椀が動く時は、それなりの配慮が必要になる。それなのに、今度はそのコップの上に、さらに茶碗を積もうとしているわけで、不安定極まりない。
"Grease"は「元のウェブサイトの変更」「ブラウザの変更」「Greasmonkeyの変更」「拡張の変更」の4者からのパラノイア的要求にさらされ続けて、錐揉みでバージョンアップを余儀なくされるのではないだろうか?そのうちブラウザ間の差異を吸収するよりも、バージョン間の差異による不具合の方が大きくなって、崩壊していく気がする。
いや、それでも、「ワールドカップ期間中」みたいに期限がきってあれば、それなりに役に立つ可能性もあるが、これをだらだら続けると確実に崩壊する。そもそも、メンテナンスに必要な労働力が尋常ではないだろうし。