Twitter サービス終了がありうるとしたら,基本的には,誰の手にも負えなくなり見向きもされなくなった時だが,まだ時間がかかる。あとは新サービスに移行させるためとか。今の経営者だと「誰にも渡したくないから」的な非合理的な理由も想像出来なくはないので,どんな可能性もゼロとは言えない。

{あれ K#F85E/E74C-F67F}
kn mk
}{出放り}{希哲15年9月10日の開発}{希哲15年9月9日の開発}{考えにくい}{問題があった}{並列実行}{直列実行}{--prl
}...
{希哲15年9月10日5歩 K#F85E/E74C-93B7}
whr_kw()
}{希哲15年8月23日の開発}{検索語変換}{どうとでもなる}{条件次第}{OR 検索}...
{希哲15年8月23日7歩 K#F85E/E74C-ECC6}
全文検索にはとりあえず pg_bigm を採用しておくことにした。知名検索でも中間一致検索の性能は課題だったので,これも解決出来そうだ。後方一致検索に関しては,PostgreSQL 9.1 から reverse() が組み込み函数として提供されるようになっているので問題ないだろう。
後縁の実装はどうとでもなるが,難しいのは用合いだ。全知検索窓をこれ以上ごちゃごちゃさせたくないので,まずは検索演算子として各種機能を実装したい。これに関しても,だいぶまとまってきた。
カンマを AND 検索に使うという構想があったが,& ボタンとの兼ね合いもあるので,まずは無難に &
か AND
で AND 検索,|
か OR
でOR 検索に対応することにした。除外検索は条件次第で -
を使えるようにしてもいいだろう。
部分一致検索については,省略記号 ...
とダッシュ記法を応用した ---
に対応する。
描写検索については,基本的には昨年7月27日3歩の方針を踏襲し,末尾に ??
を加える形で対応することにした。デラングとの兼ね合いで検索寸片をどうするかという課題は残るが,デライトではそれほど多用するものではないので,まずは普通に引っかかるだけで十分だろう。
一つの可能性として,検索ボタンをダブルクリック/ダブルクリックで検索対象を切り替える機能があってもいいかもしれない。
いずれにせよ,まずは既存の検索語変換交度を whr_kw() にまとめる作業から始めることになるだろう。

{希哲15年3月4日5歩 K#F85E/E74C-2402}
途中で終了。
統一感の無かった描出ボタン(描き出しボタン・描き直しボタン)と通注の表現を調整。
ラベルには「描き直す?」と表示しておき,押すと「描き直す」に変わっていた描き直しボタンを「描き直す」と「完了」の組み合わせに修正。これに合わせ通注も「〜で編集」から「〜で描き直す」,「〜で保存」から「〜で完了」という表現に統一。
新規描出フォームでは描き出しボタンに合わせ通注の「〜で保存」を「〜で描き出す」に統一。
通注は最初期実装から分かりやすさを重視し「編集」と「保存」の表現を使っていたが,その後,描出ボタンを実装するにあたってボタンのラベルには「描き出す」,「描き直す」を使い,通注の方を放置していたことでこうした不統一が生じていた。
いずれにせよ描き出し・描き直しはデライトのごく基本的な用語なので必ず理解してもらう必要があり,Twitter における「ツイート」同様ブランディングの一環でもあるため,常に表示されているボタンには使わざるをえない(ここで使わなくて済むならそもそも特別な用語自体必要ない)。
ここで「編集」や「保存」などの用語が混在していることは好ましくないとは感じていたが,微妙に使い分けたいこともあり難しいところだった。
描き出しはともかく,描き直しは編集欄を開く操作と保存する操作があるため,これのために「?」を使うという苦肉の策を取ったりしていた。後者のために「保存」を残すかとも考えたが,「完了」が一番自然であることに気付き決着。
ちょっとしたことのようで大分すっきりしたように感じる。

{希哲14年8月3日の開発 K#F85E/5B28-51F4}
