{デラング}{進捗記録}{交度}{デライト}{`whr_kw()`}{希哲15年8月23日の開発}{検索語変換}{どうとでもなる}{条件次第}{OR 検索}...=}(70)

{希哲15年8月23日7歩 K#F85E/A-E74C-ECC6}

全知検索整備についての検討終了

全文検索にはとりあえず pg_bigm採用しておくことにした。知名検索でも中間一致検索性能課題だったので,これも解決出来そうだ。後方一致検索に関しては,PostgreSQL 9.1 から reverse()組み込み函数として提供されるようになっているので問題ないだろう。

後縁実装どうとでもなるが,難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので,まずは検索演算子として各種機能実装したい。これに関しても,だいぶまとまってきた

カンマAND 検索に使うという構想があったが,& ボタンとの兼ね合いもあるので,まずは無難&AND で AND 検索,|OROR 検索対応することにした。除外検索条件次第- を使えるようにしてもいいだろう。

部分一致検索については,省略記号 ...ダッシュ記法応用した ---対応する。

描写検索については,基本的には昨年7月27日3歩方針踏襲し,末尾に ?? を加える形で対応することにした。デラングとの兼ね合い検索寸片をどうするかという課題は残るが,デライトではそれほど多用するものではないので,まずは普通に引っかかるだけで十分だろう。

一つの可能性として,検索ボタンダブルクリックダブルクリック検索対象切り替える機能があってもいいかもしれない。

いずれにせよ,まずは既存の検索語変換交度whr_kw()まとめる作業から始めることになるだろう。

=}
{進捗記録}{希哲15年4月10日の開発}{単純な実装}{動的切り替え}{省略表示}{希哲15年4月10日の進捗時限}{希哲15年4月10日の進捗}{希哲15年4月10日}{凝り過ぎ}{出振るい済み}...=}(39)

{希哲15年4月10日3歩 K#F85E/A-E74C-22BD}

前後景輪数表示不具合修正のついでに,吹き描き前後景部省略表示導入した。

吹き描き前後景部前後景輪10輪を越えた場合に,省略記号...)を表示し,前後景輪一覧2ページ目への輪結とした。

これまで,省略されていても特に表示が変わらなかったため,初見では把握しにくかった。また,省略された輪郭を見たい場合に,いったん1ページ目を開いてから2ページ目に移動する必要があった。

問題としては当初から認識していたが,今回の方法に近いことは昨年考えた希哲14年6月30日の開発後でいったん白紙にして動的切り替え検討する希哲14年7月18日8歩など,仕様複雑化してなかなか実装に入れなかった。

無くても何とかなっていたことではあるので,あまり凝り過ぎず,とりあえずは最も単純な実装採用することにした。

出振るい済み

{開発}{開発記録}{領当て}{手定め}{デライト}{Android}{iOS}{共有ボタンを追加しました!}{タッチ端末}{マウスアウト}...=}(71)

{希哲15年3月27日の開発 K#F85E/A-E74C-1FE0}

主に共有ボタン実装

想像以上に確認調整しなければならないことが多く手間取ったが,それでも OGP 対応作業開始からわずか2日納得出来る形になった。



予定通り,採用サービスは FacebookTwitterLINEはてなブックマークPocket日本国内利用者数の多いサービスをより共有ボタンに近付ける形で配置した。

Web Share API に対応していれば省略記号(...)が表示され,それを押すと端末ネイティブ共有機能利用出来る。省略記号の画像には全知検索ページャーに使っている ell.x2.png がそのまま使えた。AndroidiOS動作確認済み

当初,不揃いな各ボタンを整然と並べるために四分円を使い,横長の Twitter と Facebook,正方形の LINE とはてブ,最後に Pocket,と三段で構成することを考えた扇形共有ボタン部区が,これは廃案とした。試してみると意外と悪目立ちしたため別の領当てを模索していたところ,二段目の余った左余白に Pocket と省略記号を並べれば綺麗にまとまることに気付いた。

例えば同じ形状モノクロにするなど,よくあるアレンジを加えようかとも思ったが,各サービスの利用規約に抵触する可能性がある上,用者にとっては一見して分かりにくいものになりがちなので,公式のものをそのまま利用することにした。

各サービスの徹案依存する格好にはなるものの,TwitterFacebook に合わせているのだろうし,LINE正方形ボタンを変える理由もなく,はてブは柔軟性があるのでそれなりに安定して使える領当てではないかと思う。

用合いとしては,共有ボタンへのマウスオーバー小窓を開き,小窓からのマウスアウトで閉じるようにした上で,タッチ端末向けにクリックタップ)での開閉も出来るようにした。触り心地良好だ。

でもデライト語体の右下に置いておくことにした(デライト扉の様子・共有ボタン実装後)。

ソーシャル ボタンは,徹案の上でも処理の上でも雑然としたものになりがちなので,単純性重視しているデライトでの採用は見送り続けてきた。普段は邪魔にならず,かといって手間にもならず,用者にとっては分かりやすく,そこそこ美しくも見える……と,限りなく理想形に近いものが出来たと思う。

LINEPocket は使ったことがなかったため,本機能の手定めのためにアカウントを取った。



エクスポート機能仕様検討も進んだ(9歩)。

{デラング}{進捗記録}{論組}{輩符}{`!?`}{`??`}{希哲14年7月27日の開発}{検索種別}{描写検索}{補助的}...=}(61)

{希哲14年7月27日3歩 K#F85E/A-5B28-31DB}

デライト検索における部分一致検索全文検索仕様について大まかな方針を決め終了。

現状,デルン初期から引き継いでいる輩符による部分一致検索が残っているが,輩符は末尾ならともかく先頭に置くのは一般に使われる除外検索と紛らわしいという問題がある。

代わりにアスタリスクを使うという手も考えた。技術者にとっても分かりやすく,一般的にも伏せ字で使われることがあり,直感性に大きな問題はない。特殊記号であることは明らかなので混同の恐れも小さい。ただ,アスタリスク描写記法デラング)において見出し強調などに使うことを想定しており,その場合一貫性に欠ける。

そこで,「...」を使うことを考えた。例えば,「検索語...」で前方一致検索,「...検索語」で後方一致検索となる。「」や「・・・」で代用してもいい。普遍的省略記号であり,直感性アスタリスクに勝る。唯一の難点として素早く入力しにくいというのはあるが,全知検索ではあくまでも補助的な手段であるためこのくらいで丁度いいかもしれない。

ついでに将来的に全文検索などに対応をする場合の用合いについても検討

そのうち,知名検索だけではなく描写検索も含めた全文検索への要求も高まるだろう。現時点で想定しておかなければならない検索種別は,現状の知名のみ検索に加え,描写のみ検索,知名・描写検索の3種となる。これらを上手く切り替えられる方式を考えておきたい。

現状,?ボタンに使っているため,これを拡張して,検索語の末尾に ?! を加えることで検索種別を切り替えられる方式を考案した。末尾にこれらの文字を加えると,ボタンも ??!? に変化する。例えば,知名・描写両方を検索したい場合は ?? に,描写のみを検索したい場合は !? のようにする。!論組では否定の意で使われるため,知名は検索せず描写は検索する,という状態を上手く表している。

自然で分かりやすいが,自然過ぎることによる問題もある。題名などで疑問符感嘆符を使うものは珍しくないため,上手く切り分ける方法も考えておく必要がある。一番分かりやすいのは,記号の前に空白を置くことだが,フランス語のように言語によっては既にそういう習慣がある。末尾に空白を置いて無効化出来るなど,いくつか代替手段も必要だろう。

細部に課題は残るが,大まかな方針としてはこれで間違いないだろう。

{省略記号}

{}