{進捗記録}{進捗}{輪結}{希哲15年4月10日の開発}{単純な実装}{動的切り替え}{省略表示}{希哲15年4月10日の進捗時限}{希哲15年4月10日の進捗}{希哲15年4月10日}(39)

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

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

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

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

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

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

出振るい済み

{デラング}{進捗記録}{描写}{初期}{進捗}{論組}{輩符}{!?}{??}{希哲14年7月27日の開発}(61)

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

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

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

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

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

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

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

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

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

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

{進捗記録}{右吹き描き}{}{知名}{進捗}{デライト}{領当て}{希哲15年4月10日3歩}{輪括}{吹き描き}(74)

{希哲14年7月18日8歩 K#F85E/5B28-D190}

朝から前後景輪一覧領当てについて本格的な検討を始め,およそ6歩分かけて昼過ぎには概ね方向性が定まった。これで,デライト用合い設計にも死角がほぼ無くなった。

まず,6月30日の開発で検討していた,吹き描き前後景部の所定件数越えを「...」で表現し,そこから一覧に飛ばすという案は,一旦白紙とすることにした。一覧ではなく,知名だけざっと確認したいという場合が考えられるためだ。動的にただ追加するのではなく,所定件数以内で表示範囲を切り替えていく,というのであれば領当てを壊すこともない。

輪郭一覧ページ付け動的追加を検討してきたが,かえって重くなったりする懸念もあるため,いったん画面遷移で実現することにした。表示は一覧の左上と右下に ...上下矢印,ページ番号を組み合わせる形を検討。現状,録落ちボタンを使っているため紛らわしいが,これはすでに利用者情報ページに移動することを決めていたため無視していい。細かいことは実装しながら試行錯誤していく。

前景一覧については,4月14日7歩考案した逆さ吹き描き踏襲するが,最上部だけでなく一覧の各吹き描きも逆さにしてみることにした。

引き入れボタン引き外しボタン実装する上で,引き入れ状態をどう表現するかという問題もあったが,これも一応の目処が付いた。結局,くぐった輪郭と輪括関係にない輪郭線点線に変え,中景部と上にくる前後景部白煙色を入れ替えるとそれなりに見えることが分かった。この時,全て白煙色にしてしまうとぼやけ過ぎて視点が定まらないため,注目させるべき前後景部のみ白にする。これに加え,ボタンの状態が変わっていれば十分区別出来る。

他の案として,左右反転も脳裏をよぎったが,やはりこれは自他の区別に使うべきとして廃案。横にずらすなども,横幅に余裕のないスマートフォン等の端末を考えれば普遍性が無い。吹き描きはその輪郭を認識するために必要な情報が凝縮されているため,何らかの省略表示を取ることも出来ない。というわけで,表示位置・表示形式は変えず,輪郭線色彩ボタンの3要素に特徴を持たせることで輪括関係を表現するのが最良という結論になった。

引き入れボタン引き外しボタンは現状ですでに表示されている =} 形のボタン活用し,可能な限り単純性を保つ。

ついでに,輪郭をくぐった状態での検索挙動についても整理。現在,吹き描き内部の検索窓は全体検索になっているが,これは本来輪括関係のあるものに限定して検索するのが直感にかなっている。そこで,くぐっていない状態で最上部に表示されている検索窓をくぐった状態でも表示し,そこを全体検索として使い分けることにした。画面遷移時にページ内輪結で隠せば,必要な時だけ出てくるように出来る。最初は検索窓を画面に2つ表示するのは美しくない気がしたが,かといってチェックボックス検索語の特殊記法を導入するのが美しいとも思えない。これが一番直感には適っているだろう。

ここで,自他の区別に使うことを想定していた左右吹き描きもその方針確定した。

これを機に,4種の吹き描きに厳密用語を与えておくことにした。現状の左眼形を「左吹き描き」とし,左右反転させたものを「右吹き描き」,両者を併せて「左右吹き描き」と呼ぶ。さらにこれを上下反転させたものを「逆さ左吹き描き」「逆さ右吹き描き」と呼び,併せて「逆さ吹き描き」と呼ぶことにした。

{スプレッド構文}{...}(2)
{複合駒手}{希哲11年7月10日}{.../}{...}{知機駒手}(5)
{...}

{}