アカウント名:
パスワード:
済みませんが「業務」としての観点ではないと思います。まず、IE6で動作保障していたシステムに対して、「IE7でも保障する」ための検証費用は誰が出すのでしょうか?それはアップデートして得られるものに見合うコストでしょうか?という部分で会社として判断して、「そのままで」になってるんです。
とりあえず新しくしてみて、なんか出たらその時で~というのは趣味の世界です。誰がそんな行き当たりばったり作戦の責任を負うんですか。
政治的ではなく、純粋に金銭&時間的な問題です。
「IE6でしか使えないコンソールを売ってしまった事」が、実はとても恥ずかしい事だと言う事がバレずに済むのであれば、...
要求仕様として「IE6で動く」という仕様があった。HTML+CSSの仕様に準拠して書いたらIE6の挙動がおかしくて正常に動かなかった。その為、IE6で動くように仕方なくHTML+CSSの仕様に準拠しない方法で回避した。IE7にバージョンアップしてブラウザはHTML+CSSの仕様に準拠したが、コードは対応していないので挙動がおかしくなった。
といったことは普通にありそうですが。それとも、IE6がメインの時代に、HTML+CSSの仕様に準拠してますので、IE6では動きませんって言って納品するの?
#納品時にIE6のβで正常に動かないことを気づいておきながら、#要求されたIE5.5などのブラウザでは動いているので#何も言わずに納品したのでAC
要求仕様として「IE6で動く」という仕様があった。 HTML+CSSの仕様に準拠して書いたらIE6の挙動がおかしくて正常に動かなかった。 その為、IE6で動くように仕方なくHTML+CSSの仕様に準拠しない方法で回避した。 IE7にバージョンアップしてブラウザはHTML+CSSの仕様に準拠したが、コードは対応していないので挙動がおかしくなった。 といったことは普通にありそうですが。
その場合、全体をIE6用の特別なコードに置き換えてしまうより、普段は元々(仕様通り)のコードを使ってIE6の場合だけ特別なコードに分岐する方法にした方が、最初のコードを書いた労力も無駄にならないし将来の拡張にも対応しやすいし、よいこと尽くめであるように思ってしまいます。 そうではなくて全体をIE6専用のコードに置き換える方法を採ることが実際の現場では珍しくないのだとしたら、その理由って一体何なのでしょう。
「動かない」ことがわかるのが全てが終わってからということは当然ありませんので、IE6以外のブラウザでの動作が要求仕様にないのなら元のコードをそのまま開発継続・動作検証・保守を行う必然性はなく、破棄する方が全体のコストを低減させます。
コードを書く労力自体も軽くはありませんが、テストと保守の工数はもっと馬鹿になりません。
開発者もIE6しか知らないからでしょう。社内システムにアクセスする際にIE6を使うよう指示をされていれば、他のブラウザを使用する機会がぐっと減ります。そうなると、開発者自身がIE6専用のコードを書いていることに気付かないと思います。それでもフルタイム働いている開発者なのか?と思えてきますが、実際の現場を見る限りそのような傾向が強いです。
アプリのVista / Win2008対応が進まないのも、社内でVistaの使用が禁止されているとか似たような理由で発生します。
その場合、全体をIE6用の特別なコードに置き換えてしまうより、普段は元々(仕様通り)のコードを使ってIE6の場合だけ特別なコードに分岐する方法にした方が...
もちろんそうしますが、昔はHTML+CSSの準拠率が低くてブラウザ(特に複数の)で動作させる場合は標準から逸脱しなければならないことが多かったんですよ。CSSハック [google.co.jp]のような裏技を使わざるを得ないことが多々ありまして。こうなると新バージョンの場合の動作なんて予想できるわけも無く、標準仕様がどうこう言ってられないんですよ。
まず「IE6だけでOK」という仕様なら、IE6以外ではテストされないというのが重要です。
ちなみに「IE6だけでOK」と最終決定しているのはもちろん発注側です。対応ブラウザを増やすとテスト工程などでの工数が増える=開発費用が増えるのが原因です。社内用アプリなどでは対応ブラウザ数は予算より優先度は低いことが多いでしょうね。(ま、たまに不勉強な発注側担当者がめんどくさがりな受注側担当者に言いくるめられて…ということもあるでしょうが)
ともかく、IE6以外でテストしないですから、分岐するように書くと標準準拠コードの方はテストされません。受注側はその分の費用を
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
ちょっと不親切な気が…… (スコア:0)
自分のIEが旧版であることを知らなかった層を誘導したいなら、
ダウンロード先のリンクを見せたくらいじゃ、乗り換えてもらえ
ないのでは?
せめてIE6を使い続けることがどんなデメリットになるのか、他の
新しいブラウザがどれだけのメリットをもたらしてくれるのか、
あたりを訴求しないと……。
特に後者は、なぜIE6じゃダメなのかも理解してないだろうし。
Re: (スコア:1, 興味深い)
上がると互換性などのトラブルが絶対にある、ということを盛んに
言いふらしている人たちの存在が原因ですよね。
それに伴って、独自Webアプリを提供したベンダーが、互換性トラブルで
余計な問題にならないようにIE6でしか保証しないと逃げているわけ。
たしかに問題は皆無ではないでしょうが、それほど大きな問題は多くない
というのが本当のところ。
同感 (スコア:0)
国内のWebインタフェイスな業務システムの類を見る限りでは、
仰る様に、本当は大きな問題では無いよな、と思います。
まぁ、小さな問題であっても、
誰も費用出さないと言う事でしょうけど、
IE6独自の機能をフル活用しているので、
IE7,8に上げたら機能しない、なんて事はまず無いです。
せいぜい見た目の表示が崩れる、表示されなくなる程度の事ですし、
それにしたって、大半はIE独自解釈がどうこうじゃなく、
ブラウザ毎に処理が食い違うのが当然のデタラメのHTML記述で、
た
Re: (スコア:1, すばらしい洞察)
済みませんが「業務」としての観点ではないと思います。
まず、IE6で動作保障していたシステムに対して、「IE7でも保障する」ための
検証費用は誰が出すのでしょうか?
それはアップデートして得られるものに見合うコストでしょうか?
という部分で会社として判断して、「そのままで」になってるんです。
とりあえず新しくしてみて、なんか出たらその時で~というのは趣味の世界です。
誰がそんな行き当たりばったり作戦の責任を負うんですか。
政治的ではなく、純粋に金銭&時間的な問題です。
言い訳は何とでも出来るんでしょうけど (スコア:0)
> 誰がそんな行き当たりばったり作戦の責任を負うんですか。
たかだかコンソールが特定ヴァージョンのブラウザに依存する時点で、
それはもう「趣味の世界」レベルのクオリティなんですよ。
誰か、そんなものを導入してしまった事の責任を負いましたか?
「IEのヴァージョン上がったら動作保障は出来ない」が
当然のことであるかのように洗脳されているから、
ヴァージョンを上げる事や、それに対応する修正を、
「作戦」等と大袈裟に表現してしまうんです。
実際のところ、問題が起きないのが当たり前なんです
Re:言い訳は何とでも出来るんでしょうけど (スコア:0)
「IE6でしか使えないコンソールを売ってしまった事」が、
実はとても恥ずかしい事だと言う事がバレずに済むのであれば、
...
要求仕様として「IE6で動く」という仕様があった。
HTML+CSSの仕様に準拠して書いたらIE6の挙動がおかしくて正常に動かなかった。
その為、IE6で動くように仕方なくHTML+CSSの仕様に準拠しない方法で回避した。
IE7にバージョンアップしてブラウザはHTML+CSSの仕様に準拠したが、コードは対応していないので挙動がおかしくなった。
といったことは普通にありそうですが。
それとも、IE6がメインの時代に、HTML+CSSの仕様に準拠してますので、IE6では動きませんって言って納品するの?
#納品時にIE6のβで正常に動かないことを気づいておきながら、
#要求されたIE5.5などのブラウザでは動いているので
#何も言わずに納品したのでAC
Re:言い訳は何とでも出来るんでしょうけど (スコア:1)
その場合、全体をIE6用の特別なコードに置き換えてしまうより、普段は元々(仕様通り)のコードを使ってIE6の場合だけ特別なコードに分岐する方法にした方が、最初のコードを書いた労力も無駄にならないし将来の拡張にも対応しやすいし、よいこと尽くめであるように思ってしまいます。
そうではなくて全体をIE6専用のコードに置き換える方法を採ることが実際の現場では珍しくないのだとしたら、その理由って一体何なのでしょう。
Re: (スコア:0)
そう言った場合のIE7,IE8対応は比較的楽ですよね。
そーゆーやり方をしている会社とお付き合いしたいですね。
Re: (スコア:0)
「動かない」ことがわかるのが全てが終わってからということは当然ありませんので、
IE6以外のブラウザでの動作が要求仕様にないのなら元のコードをそのまま開発継続・動作検証・保守を行う必然性はなく、破棄する方が全体のコストを低減させます。
コードを書く労力自体も軽くはありませんが、テストと保守の工数はもっと馬鹿になりません。
Re:言い訳は何とでも出来るんでしょうけど (スコア:1)
開発者もIE6しか知らないからでしょう。社内システムにアクセスする際にIE6を使うよう指示をされていれば、他のブラウザを使用する機会がぐっと減ります。そうなると、開発者自身がIE6専用のコードを書いていることに気付かないと思います。
それでもフルタイム働いている開発者なのか?と思えてきますが、実際の現場を見る限りそのような傾向が強いです。
アプリのVista / Win2008対応が進まないのも、社内でVistaの使用が禁止されているとか似たような理由で発生します。
Re: (スコア:0)
その場合、全体をIE6用の特別なコードに置き換えてしまうより、普段は元々(仕様通り)のコードを使って
IE6の場合だけ特別なコードに分岐する方法にした方が...
もちろんそうしますが、昔はHTML+CSSの準拠率が低くてブラウザ(特に複数の)で動作させる場合は
標準から逸脱しなければならないことが多かったんですよ。
CSSハック [google.co.jp]
のような裏技を使わざるを得ないことが多々ありまして。
こうなると新バージョンの場合の動作なんて予想できるわけも無く、標準仕様がどうこう言ってられないんですよ。
Re: (スコア:0)
まず「IE6だけでOK」という仕様なら、IE6以外ではテストされないというのが重要です。
ちなみに「IE6だけでOK」と最終決定しているのはもちろん発注側です。
対応ブラウザを増やすとテスト工程などでの工数が増える=開発費用が増えるのが原因です。
社内用アプリなどでは対応ブラウザ数は予算より優先度は低いことが多いでしょうね。
(ま、たまに不勉強な発注側担当者がめんどくさがりな受注側担当者に言いくるめられて…ということもあるでしょうが)
ともかく、IE6以外でテストしないですから、分岐するように書くと標準準拠コードの方はテストされません。
受注側はその分の費用を
Re: (スコア:0)