アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
そもそも (スコア:1, 興味深い)
この手の製品に限らず、広告とかを見てると、
・フィルタをかましてクライアントにより動的に適切なコンテンツを表示する
よりは、
・最初からクライアント毎に適切なコンテンツを見るように促す(携帯用は http://www.webiseite.dom/mibile/ みたいな感じ)
方が、システム的な初期導入/運用維持費用が安く済みそうなのは、素人考えなのでしょうか。
確かに同一URLにアクセスさせれば広告的な見栄えはするんでしょうけど、一度アクセスしてしまえばブックマークなり履歴から辿ることが多いんだよなぁ、とか考えると接続先のドメイン(URL)が多少長くても関係なかったりする訳で。
さらに言ってしまえば、QRコードで掲載してくれるともっとうれしい訳で。
Re:そもそも (スコア:0)
・クライアント毎に適切なコンテンツに飛ばす
のは難しいんでしょうか。
自分じゃ静的 web ページすらろくに書けないので外してるかもしれませんけれど。
Re:そもそも (スコア:4, 参考になる)
たとえば、あらかじめ静的なコンテンツがクライアントの種類ごとに用意されているのであれば、同一のURLから適切なコンテンツへリダイレクトしたりするのは簡単です。
ブラウザやi-mode端末などのユーザーエージェントは、Webサーバへのアクセスの際に、「User-Agent」ヘッダで自らが何かを名乗るので(ブラウザによっては偽装できますが)、それを元に振り分けます。
Apacheなら、mod_rewrite [apache.org]が使われることが多いんじゃないでしょうか?
ただ、i-modeなどで端末の世代/対応機能/画像の解像度・色数・表示特性などに応じて、個々にコンテンツを用意しようと思うと、端末の発売ごとに、新しく静的に作るべきコンテンツが増えたり、振り分けのための設定をするといった対応が必要なので、こうした『箱』が求められるということはあるでしょうね。特に、動作検証ということになると、たとえばi-modeだけでも端末の種類は大量ですから大変な作業になりますから。
理想をいえば、携帯電話とPCでは、ページ間のナビゲーションやUIなども違ったものが求められるので、最低限、「携帯向け」と「PC向け」の2種類を用意しておいて、細かい違いを端末ごとに調整したいということになるんでしょうが、どうやらNECの問題の製品はその辺も考慮されているっぽいので、サイト運営側としては魅力に感じるんだろうな、と思います。
おそらく今回のようなチケット販売サイトは、コンテンツが動的に生成されている部分が多い(ほとんど?)と思われますので、振り分けるという発想ではなくて、アプリ側で対応することも不可能じゃないわけですが、新しい端末への対応を考えると、細かい端末ごとの対応は、こうした製品を使いたいところかもしれません。
現実問題としてこういうソリューションが必要なのはいたしかたありませんが、ほんらいなら、XHTML+CSSやHTTP/1.1のコンテントネゴシエーションなどのアプローチで対応できるほうが美しいとは思いますけど。
Re:そもそも (スコア:0)