アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
そもそも (スコア:1, 興味深い)
この手の製品に限らず、広告とかを見てると、
・フィルタをかましてクライアントにより動的に適切なコンテンツを表示する
よりは、
・最初からクライアント毎に適切なコンテンツを見るように促す(携帯用は http://www.webiseite.dom/mibile/ みたいな感じ)
方が、システム的な初期導入/運用維持費用が安く済みそうなのは、素人考えなのでしょうか。
確かに同一URLにアクセスさせれば広告的な見栄えはするんでしょうけど、一度アクセスしてしまえばブックマークなり履歴から辿ることが多いんだよなぁ、とか考えると接続先のドメイン(URL)が多少長くても関係なかったりする訳で。
さらに言ってしまえば、QRコードで掲載してくれるともっとうれしい訳で。
Re:そもそも (スコア:4, すばらしい洞察)
重要なのは、コンテンツ製作者が複数クライアント向けに同じ内容のページを複数作らなくて済むことなんだと思います。
Re:そもそも (スコア:1)
気になって製品概要を確認してみて納得しました。
なんか考え方が違ってましたorz
http://www.sw.nec.co.jp/cced/mobilenet/intro.html
元の情報を、クライアント毎に適した形に修正するんですね。
てっきり、クライアントに適したコンテンツを振り分けるだけかと思ってました。
Re:そもそも (スコア:1)
図が気になるんですが、
携帯電話・PHS
・ iモード
・ Vodafone Live!
・ EZweb
・ ブラウザフォン
・ ドットi
・ H"
UAが「WILLCOM」だと知らんブラウザ扱いでパソコン用ページが返りそうな予感!!
# 今さらH"-Linkの人居るの?
UA定義 (スコア:3, 参考になる)
UserAgent定義ファイルがNECの登録ユーザー専用サイトにアップされており、
それをDLして読み込ませていました。
「○○(キャリア)の××(機種)でうまく表示されない」
「□□□の△△△で全部表示されず、次へボタンが出ない」
などと言われる度に、定義ファイルがアップされてないか専用サイトをチェックし、
切羽詰まると同キャリア同メーカーの、画面解像度の近い機種用の定義をカスタマイズしたものです。
NECに問い合わせるのもしょっちゅうでした。
それでもページの開発に比べれば工数が少ないので、重宝でした。
モデレート したいときには 権利なし
かつかれー
うまく表示されない (スコア:1)
Mobilenetとは無関係と思うけど、先月末に以下のようなことがありまして、
・ WILLCOMのWX310Kに機種変更
・ 追加機能をレジスト(FlashやらQRリーダやら)
・ 自販機に貼ってあった歌ジャケのQRコードを撮ってみる。
・ 解析されたURLに飛ぶ
・ Flashムービーが読み込まれる。データサイズが相当あるのか、かなり待たされる。
・ WX310Kの説明書にあるようにフォーカス当てたら操作には問題なし。
・ どう見てもPC用ページです。ありがとうございました。
うまく表示されてしまいました。文句が言えません。
Re:そもそも (スコア:0)
H"-Linkを利用してるかどうかは知りませんが、ル・モテ [panasonic.jp]よりも
使いやすい音声端末が無いと、未だにFeel H"端末だけを使ってるユーザを数人知っています。
#私はOperaとE-mailサービスに負けてAIR-EDGEに移ったクチですが
#AIR-EDGE端末でル・モテの後継が出てくれたら喜んで京ぽん捨てます
Re:そもそも (スコア:0)
そうすれば動的に処理する必要がないので,負荷云々の問題は発生しない.
Re:そもそも (スコア:0)
こういうシステムが必要な人は、
コンテンツの更新頻度が高い、
もしくは対象となるページ数が多く管理が難しい環境ではないかと。
Re:そもそも (スコア:2, 興味深い)
PC用のブラウザのコンポーネント単位では種類が限られますが、
携帯端末は新機種の交代も早く、ブラウザの種類を追っていられないので
場合によってはフィルタ任せにしてしまったほうが
コストが低くなる場合もあると聞いたこともあります。
もちろんローソンがどうなのかは知りませんよ。
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)
Re:そもそも (スコア:0)
このエンジンの売りは、おそらくバックエンドからそういった生成部分の分岐・変換処理の手間を追放して負荷と開発コストを削減、コンテンツは1ソース・マルチユースで製作コスト削減、でもって後段を増やせばスケーラビリティ確保もできますというような所だろうし、そういう意味では、この構成自体は失敗