アカウント名:
パスワード:
普通のGoogleのトップすら、AirH"だと何だか重く感じるんです。いや、重いんです。
Google 検索窓を記述したローカルファイルをホームページにする [hi-ho.ne.jp]、とか。そういやこの方法だと Palm 向けページに飛ばされませんね。
一番いいのは画像オフ(やw3m)だったりするかも知れないが。
w3m は
「ロード最中でもページの最初のほうは表示し始め、なおかつロードは継続する」という仕組みが無いブラウザ
なので、電波状況が劣悪だったり、低速回線だったりすると待ってる時間がものすごく長く感じます。途中でキャンセルすればいいんですけどね(w3m/0.4)。
かたや、うちは端末はPCだけど回線がいまだに狭いので、画面分割などよりもHTTP entityの圧縮をきちんとやってくれるとありがたいですね。特に、SSIなどを利用しているためにcacheが効かないところでは、圧縮をするとしないとでは見る側の使い心地が全然違います。サーバ側でも、帯域の節約になりそうなんですが。
なお、/.-Jではcomment.pl以外でgzip圧縮が可能です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
逆に (スコア:2, 興味深い)
パケ代掛って"しかも"ナローな PDC とかなら解りますけど、AirH" で新らしめな Palm とかだと逆にありがた迷惑だったりしませんかね。なんかクッキーでカスタマイズって感じにも見えませんし。
自分が使ってた時に 2ch の i-mode 版を試した事があるんですが、何度も接続に行くより、かえって一気に読みこんで、ゆっくり見る方が楽に感じました。後、モバイル用と称して、貧弱なページを"強制的に"見せられるのも嫌でしたし。
フラッシュ使ってるとか、あきらかに環境を選ぶページならまだしも、Google なんて軽いのもウリだったりするわけで。
Re:逆に (スコア:2, 参考になる)
>AirH" で新らしめな Palm とかだと逆にありがた迷惑だったりしませんかね。
>何度も接続に行くより、かえって一気に読みこんで、ゆっくり見る方が楽に感じました。
>後、モバイル用と称して、貧弱なページを"強制的に"見せられるのも嫌でしたし。
ページ分割はデメリットも多い、という点は同意します。
初期レスポンス速度も欲しいけど、
「こっちだってメモリがそこまで逼迫してるわけじゃないぞ」
と思うことも多いので、一長一短。
一方、ページが「貧弱」ってのはどういう意味でしょうか?
スラドのライトモードみたい(^^;な表示形態、という意味でしたら、
俺としては「常に」肯定したいです。つまりモバイルどころかPCで使っているときであっても。
普通のGoogleのトップすら、AirH"だと何だか重く感じるんです。いや、重いんです。
それを出来るだけ無駄(!)を殺ぎ落として高速化してくれるっていうなら、
それに越したことはない。デバイスの如何を問わず。
貧弱なほうがいい。
某社の予約サイトをよく使うんですが、俺はPCからでもimode版ページに言って予約してます。
あらゆる動作がきびきびしてるので、それに比べると、
絵だの表だの枠だのをウダウダ出してくるメインページなんか使えたもんじゃないですね。
#ましてそのせいで数分差で予約逃した時にゃあ…(T_T)
…そうでなく、貧弱ってのが「へたに分割したページ」のことを指してるのでしたら、
上記のようにそれなりに同意。
ただし、Googleに限って言えば、スラドのモデと同じで(^^;どうせデータの表示順が最初から
俗世間の人々にとって「見たいであろう順」になっているので、
分割されても最初の1頁さえ見えれば足りる、ということも多いかも知れない。
それと、「ロード最中でもページの最初のほうは表示し始め、なおかつロードは継続する」
という仕組みが無いブラウザを使っているという条件が組み合わされると、
サーバのほうで小出しにしてくれるのも考えようによっては悪いとも言い切れない。
>フラッシュ使ってるとか、あきらかに環境を選ぶページならまだしも、Google なんて軽いのもウリだったりするわけで。
まだ軽くする余地は有ります。
一番いいのは画像オフ(やw3m)だったりするかも知れないが。
個人的に価値がよく判らないのが、
普通のGoogleのトップページってJavaScriptかなんかを使ってるでしょ、あれ。
あのぶん削ってくれたら、少しだけ速くなると思うんだがなあ。
Re:逆に (スコア:2, 参考になる)
Google 検索窓を記述したローカルファイルをホームページにする [hi-ho.ne.jp]、とか。そういやこの方法だと Palm 向けページに飛ばされませんね。
w3m は
なので、電波状況が劣悪だったり、低速回線だったりすると待ってる時間がものすごく長く感じます。途中でキャンセルすればいいんですけどね(w3m/0.4)。
Re:逆に (スコア:1)
あ。これはいいですね。(トップページの)JavaScriptも回避できるわけだし。
参考になりました。+=1。
うーん。これはいいなあ。最初のページを自分ローカルで持つってのが味噌ですね。
他にも、自分ち(ぉぃ)の掲示板に一撃でポストするフォームとかを作っておくと、重宝するかも知れない。
#WikiのInterWikiNameの仕組みを流用して、いきなりポストページに飛ばす、という技に通じるものがあるなあ。
>w3m は
(中略)
>電波状況が劣悪だったり、低速回線だったりすると待ってる時間がものすごく長く感じます。
レンダリング確定するまで表示は出来ない、という考え方だったんでしょうかね…
まあ、受信とレンダリングと表示とユーザ操作(キャンセル)待ち受けを同時にこなすのは
マルチスレッドなりselect(?)なりを色々駆使しないと無理でしょうから…
あと、ページ解釈をする側としては、未確定でありながら表示可能という「状態」を
どうやって作り出すか、も、大変だろうなあ。
途中表示が出来ない解釈系ですら、大変そうですもんね…
>途中でキャンセルすればいいんですけどね (w3m/0.4)。
0.4ってw3mのバージョンっすよね。
Ctrl-Cを使えば、0.3でもキャンセル(もどき)が出来るようです。
ただ、たとえばZDや読売を見るときが該当するんだけど、ロードメーター(?)が8割9割いっていても、
Ctrl-Cで止めちゃうと、表示されるのは最初のチョビットだけなんですよね。
レンダリングが確定しないうちに止めちゃったっていう扱い…なのかな…
まあ最新版入れればいいんでしょうけどね。
タブブラウザ化したのと、その余波(?)で
ダウンロードしながら同時に他のページも見れる(LoadはともかくViewは出来る。つまりDL中もタブ切り替えを受け付ける)
などという事実上(実装方法は知りませんが)のマルチスレッド化のおかげで、
いわゆる古典的なCUIプログラムっぽい制限(=いかにもシングルスレッド&非イベント駆動な雰囲気)が
無くなってるのが、凄く良いです。
#Librettoの超横長大迫力(藁)画面でタブが「上」に表示されると悲しいのでG7
#どこぞのWindowManagerみたいに、横に出せるといいなあ。
#確認してないけど、出来るんかな?縦書きが大変そうだが(^^;
Re:逆に (スコア:0)
ただしもうw3mと全く別物になっているけど。
GoogleのJavaScript (スコア:1)
>あのぶん削ってくれたら、少しだけ速くなると思うんだがなあ。
いや,むしろ遅くなるかもしれない。
GoogleのトップページのJavaScriptの用途は二つ。
1.ページロード時に検索文字列エリアにフォーカスを移し,いきなり文字入力ができるようにする。
2.TABLEのセルなどをFORMのSUBMITボタンがわりに使う。
前者は非常に細かな気遣いだが,これにより入力前にテキストエリアをクリックするなどの手間が省けて,利用時のストレスがずいぶん減っている。
後者は,「イメージ」や「グループ」などの部分に使われている。JavaScriptを使用しないとなると,代わりにINPUTタグのIMAGEタイプを使用しないといけないので,余分な画像ファイルのロードが発生してしまう。
Re:GoogleのJavaScript (スコア:1)
>GoogleのトップページのJavaScriptの用途は二つ。
>1.ページロード時に検索文字列エリアにフォーカスを移し,いきなり文字入力ができるようにする。
>2.TABLEのセルなどをFORMのSUBMITボタンがわりに使う。
キーボードがついた計算機なら、TABを叩けば解消する問題ですね(^^;
てゆーか、トップページを表示するのにかかる時間の問題ですから、
表示してからのUIの良し悪しは(とりあえず俺の上記話題には)無関係です。
なんてゆーか、サブミット後はGoogle鯖が処理してる時間も込みだから、多少長くても
許す意識が働いてしまうんだけど、サブミット前つまりトップページの表示は
一瞬で出ないとムカツクんだよね。単なる道具の呼び出しくらい一瞬でないと嫌だなと。
蛇足ですが、WinでIEの時は俺は「JavaScriptを受け付けるかどうかは、毎回ユーザにDialogで質問する」
設定にしてるもんだから、尚更時間かかるし(^^;
>「イメージ」や「グループ」などの部分に使われている。JavaScriptを使用しないとなると,代わりにINPUTタグのIMAGEタイプ
イメージのトップページをブックマークに入れとけば済みそう(^^;
あとは、「イメージのトップページ」というものをGoogleが用意するかどうか(つまりGoogle側)の問題かなと。
Re:GoogleのJavaScript (スコア:0)
Inputまでたどり着くのに何回Tabをクリックすればイインカイ?
え?5回?
Re:逆に (スコア:0)
>スラドのライトモードみたい(^^;な表示形態、という意味でしたら、
それは自分としてもOKです。
問題は、携帯電話用みたいなページに強制的に飛ばされて、必要な(お目当ての)画像等が省かれていたり、PC 用とは完全に切り離した携帯電話用のようなページに飛ばされるのが嫌だったのです。(コンテンツが違ったりする)
というかまぁ、どんなページにせよ、ユーザー側で選択でき
Full Google (スコア:1)
にアクセスすれば従来の画面で検索できるようです。
yp
ナローバンドもいろいろ (スコア:1)
かたや、うちは端末はPCだけど回線がいまだに狭いので、画面分割などよりもHTTP entityの圧縮をきちんとやってくれるとありがたいですね。特に、SSIなどを利用しているためにcacheが効かないところでは、圧縮をするとしないとでは見る側の使い心地が全然違います。サーバ側でも、帯域の節約になりそうなんですが。
なお、/.-Jではcomment.pl以外でgzip圧縮が可能です。
Re:逆に (スコア:0)
Re:逆に (スコア:0)
Palmじゃないけどw
なにで判断されてるんでしょうね?
Re:逆に (スコア:2, 参考になる)
Mozilla/4.0 (compatible; MSIE 5.5; Windows CE; sigmarion3)
などでPDA向けGoogleに飛びますね。いろいろ試してみるとどうやら Windows CE sigmarion などの文字列が決め手になっているようです。
Windows CE Palm でもイケるようで、Windows CE PDA名 というのが判別条件の一種っぽい感じです。
Re:逆に (スコア:1, 参考になる)
http://www.google.co.jp/palm
に飛びました。以下適当。
Windows CE sigmarion => http://www.google.co.jp/palm
DoCoMo => http://www.google.co.jp/imode
J-PHONE => http://www.google.co.jp/jsky
Re:逆に (スコア:0)
Re:逆に (スコア:1)
ためしにhttp://www.google.co.jp/palm/に行ってみたけど、
検索するとなんか文字化け風味。
AirH"32kだから使えた方が便利なんだけどなぁ。
「なんとかインチキできんのか?」
Re:逆に (スコア:1)
http://www.google.co.jp/palm にアクセスしたら、日本語でも文字化けしませんでした。
Re:逆に (スコア:1)
ありがとうございました。
#スラッシュあり [google.co.jp]
#スラッシュなし [google.co.jp]
「なんとかインチキできんのか?」
Re:逆に (スコア:0)
実際にAir H"(128k契約)+Pocket PCで使っている身としては、体感的に改善されるので非常に助かるという答えを出しておきます。
パケ代よりも、高