{初期実装}{全知検索ページャー}{希哲14年8月7日}{デライト離立補完終結}{悩ましい}{機能退行}{輪郭}{Google 検索}{探索}{満足}=}(19)

{希哲14年8月7日の開発 K#F85E/A-5B28-C642}

全知検索ページャー8日用語化)の形が概ね出来た(詳細は9歩)。

デルンにおけるページャーは,長いこと悩ましい問題だった。初期実装には Google 検索のような普通のページャーがあったが,全知検索改良していくうちに機能退行した。輪郭探索出来ることが多いため,無くても意外と困らなかったということもあるが,最良の形が頭の中でまとまらなかった。

結果としては満足行く案が出来たので,デライト離立補完終結直前まで遅らせたのは正解だったのだろう。


{約2,810件}{約16,800,000件}{希哲14年5月22日のツイスト}{希哲14年5月22日}{フロンティア}{ツイスト}{Google 検索}{状況}{新天地}{知能増幅}=}(13)
{柔品}{美しいソフトウェア}{希哲13年12月11日}{希哲13年12月11日のツイスト}{ソフトウェア}{ツイスト}{Google 検索}{美しい}{日本語}=}(9)
{メモ検索}{希哲13年10月14日のツイスト}{希哲13年10月14日}{ツイスト}{Google 検索}{メモ}{頭脳}{全知検索}{インターネット}{デルン}=}(10)
{第一次検索革命}{第二次検索革命}{希哲13年7月27日}{希哲13年7月27日のツイスト}{ツイスト}{Google 検索}{全知検索}{デルン}=}(8)
{希哲13年7月15日}{希哲13年7月15日のツイスト}{ツイスト}{Google 検索}{機械翻訳}=}(5)
{希哲13年6月25日}{ウェブページ表示速度}{gzip_types}{PageSpeed Insights}{デルンの最適化}{新月庭}{Pg/}{gzip 圧縮}{譜類整理}{Google 検索}=}(13)

{希哲13年6月25日の開発 K#F85E/A-5B28-CCBE}

昨日寝る前,ちょうど新月庭が始動しだした6月Google 検索理積み更新が行なわれていたことを知った。かなり影響の大きいものだったらしいが,吉と出るか凶と出るか。

これについて調べている時,PageSpeed Insights を思い出した。一時期これを利用して旧月庭の高速化に取り組んでいたが,旧月庭には根本的な問題が多すぎたため少し離れていた。

今日,久しぶりに新月庭で試してみると,諸場96点,個人機99点くらいの結果が出た。gzip 圧縮イチの出力する HTML と静的な JavaScript で効いていない問題に気付いた。どれも旧月庭の nginx.conf から写す時に抜けたり,gzip_types 設定の微妙な差によるものですぐ修正出来た。

修正後,諸場99点,個人機100点の結果が出た。

XPO/Pg/譜類整理

長い間適当だった XPO/Pg/ 以下の譜類整理を行い,見通しが大きく改善した。


{希哲13年6月2日}{希哲13年6月2日のツイスト}{ツイスト}{Google 検索}=}(4)
{希哲13年4月7日}{希哲13年4月7日のツイスト}{用者体験}{ツイスト}{Google 検索}{Windows}=}(6)

{あれK#F85E/A-5B28-E499}

用者体験(UX)の設計が難しいのは,「用者(ユーザー)の体感的な快適度」と「統計的な最適化」とがしばしば異なるからだ。例えば,Windows が更新で勝手に再起動したり,Google 検索が勝手に検索語を修正してきたりするのは,それが統計的にみて用者の利益になると判断されてるからだが,用者には体感出来ない利益よりも「邪魔された」という体験の方が強く記憶される。

=}
{希哲13年3月28日}{あれ}{SNS 検索}{希哲13年3月28日のツイスト}{ツイスト}{Google 検索}{全知検索}=}(7)