角括弧を使った外部輪結に限り,外部輪結アイコンを表示するようにした。
破下線の色は silver
だったが,まだ若干目障りなので gainsboro
にした。 lightgray
だった URL の破下線色も gainsboro
にしておいた。
lightgray
}{外部輪結アイコン}{希哲16年7月26日の進捗時限}{silver
}(24)輪郭選り手抜控機能整備を概ね終え,ようやく出振るい出来た。追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。
この出振るいにより,中途半端な実装だった輪郭選り手抜控機能に一通りの機能が揃った。下書き抜控一覧も使えるようになり,抜控の把握が容易になった。予てから欲しかった新規描出フォームの消去・復元ボタンも抜控の削除のため追加した。18日の開発で実装した描写拡縮ボタンも使えるようになった。また,周辺の交度整理も大きく進み,理腑としての意義も大きかった。
利便性・信頼性の向上はもちろんのこと,昨年から中途半端な状態で引きずってきた当努が片付いたことによる精神衛生上の効果も大きい。昨年来の他の当努は本格的に着手していないか,着手して間もないので,ここから思考を整理しやすくなる。
抜控機能整備が長引いた最大の原因は,他にやりたいことが多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間に設計方針が変わったり深刻な不具合に気付いたりしたので,時間をかけたことで円滑に片付いた面もある。
再描出は知番でいいとして,新規描出の鍵をどうするか,というのは難しい問題の一つだった。昨年7月28日6歩から検索語を鍵に含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信の検索語まで取っていたため,これを書き換えると意図せず他の抜控を上書きしたり消去してしまう可能性があった(4月28日20歩で書いた消失不具合の原因だろう)。これは求頼文字列から取ることで回避した。
下書き抜控一覧についても,表示条件や領当てなど色々考えることが多かった。検討の結果,再描出下書きは,検索語無しの場合(上部メニュー同様)のみ輪郭一覧の上に表示(画面撮り),新規描出下書きは,他の抜控がある場合のみ新規描出フォームの上に常に表示させることにした(画面撮り)。邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発で決めた通り,一覧は省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化と抜控を溜め込み過ぎる懸念があるため見送った。抜控の溜め込みは性能低下,消失リスクの増大(あるいはそれを補う作業コストの増大)に繋がる。目障りになったら消化するようにしてもらいたい。
一番難しかったのは鍵仕様の設計だった。一応,鍵仕様変更時の更新方法は考えていたが,手間を考えるところころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所が見つかった。一時,鍵に仕様変更日時を含めることを考えていたが,これは複雑化を招くだけなので廃案とし,Aejs_DG_rev
に判別用の文字列を入れておくことにした。新規描出下書き抜控の鍵には自我知番を含め,自我の切り替えにも対応した。
その他,これまで描写のみ保存していたのを知名にも対応する,消去ボタン・復元ボタンを実装する,などこまごまとした問題を片付ける必要があった。
出振るい後,軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様の更新処理の失敗だった。領下で十分な手定めをしたつもりだが,本番環境では一部の鍵が1回の処理で更新出来なかった。結果的に,3回実行する必要があった。開発者通類で localStorage の内容を見ても交度を見返しても心当たりがない。
少し迷ったが,時間が経つにつれ重要性が急速に低下する部分なので,調査は打ち切ることにした。最も使用頻度の高い私や常連用者達が出振るい後も普通に使えていることから,深刻な問題は発生していないと判断した。今後,同様の処理を書く際の注意点として記憶しておく。
見出し記法実装に関しては一段落した(デライト公式での解説)。
結果的に,Org-Mode,主要なウィキ実装,AsciiDoc,Markdown の方式に幅広く対応出来ることになり,当初想定よりずっと洗練されたものになった。
見出しの扱いは簡単なようで意外に複雑で,デルン初期実装では早期に実装していたものの,デライトに合わせた再実装がなかなか難しかった。出来てみれば,時間をかけただけのことはある。
昔の輪郭には見出しを使ったものも少なくないため,これらの可読性が向上し,SEO にも寄与してくれることが期待出来る。
見出し記号には,当初予定していた星号に加え,要望による等号,実装途中で条件付きで取り入れられることに気付いた番号記号を採用した。半角・全角の区別は無い。
実装しながら,最初の見出し記号の数も任意にした方が都合が良いことに気付き,最初の見出し記号の数を基準とすることにした。最初の見出し記号の数を下回る見出し記号が現れた場合は,それを新たな基準にする。
いずれにせよ,HTMLで見出し階層を飛ばすのは良くないとされているため,こうせざるをえないのだが,中景輪符の捉え方で,見出し記号2つで始めた方が直感的と感じる人もいるだろう。この仕様を利用して,見送るつもりだった番号記号も採用出来た。
見出し装体に関しては,文字を適当な大きさ・太さにして,h3 要素までは下線を入れるという,特筆すべきことはあまり無いものに落ち着いた。
見出し記号が多様化したこともあり,3月30日9歩で作った見出し装体素案から星号部分を除いた形になった。
実際試してみると,これくらいあっさりしていた方が気軽に使いやすい。これ以上装飾すると目障りになりそうだ。
当初,HTML 上で見出し階層がずれても装体を維持するように調整するつもりだったが,これはいったん保留とした。現状,中景輪符が h1 でも h2 でも同じ装体になっていることに合わせようとしたが,本来これは変わった方が自然なので,後でまとめて調整した方がいいだろう。
見出し記法実装の一段落(10歩)をもって DIL 0.2 にあった主要な記法を全て取り込んだため,長らく定まっていなかったデラングの版存を 0.03 と定めた。
デラングの版存に関しては,時印を元に適切な版存を自動適用するという方向で検討するようになっている(3月7日14歩)。それはそれとして,管理上版号も欲しいと考えていたが,なかなかまとまりが付かなかったこともあり,特に版号を与えていなかった。
キリの良いところでデラング 0.01 とするか,などとぼんやり考えていたが,これだけ長いこと弄っていて 0.01 というのも出し惜しみが過ぎると感じていた。
この見出し記法実装をもって旧デルン実装で主に利用していた DIL 0.2 を取り込み終え,開発予定のまま棚上げになっていた DIL 0.3 を置換することになるため,点零記法でこれに相当する 0.03 が丁度良いのではないかと気付いた。
デラング 0.01 は DIL 0.1 の,デラング 0.02 は DIL 0.2 の別名としておく。
lightgray
}{silver
}{出放り}{<a.URI>
}{希哲15年3月22日の開発}{薄過ぎ}{記号的}(33)datePublished
}{進捗記録}{差}{<meta>
}{文字}{進捗}{デライト}{SNS}{領当て}{日時表記}(62)途中で終了。
これまで再描出日時がある場合は新規描出日時の上に2行で表示していた時印部だが,初期状態では新規描出日時を隠しておき,マウスオーバー時に表示させるようにした。クリック/タップで表示を固定・解除することも出来る。
時印は文書としては正確に把握出来た方が良く,個人的には時計代わりに見たいことも多いので,昔から SNS 等でよくある「〜前」という表示が嫌いだった。デライトでは %Y-%m-%d %T の形式を採用しそれなりに気に入っていたが,難点も感じていた。
特に,時印を2つ並べた時に文字の固まりとして目障りであり,視認性も良くなかった。比較して見たいことも考えると縦2行しかないが,ぱっと見で差が判別しにくい。単純に縦方向の空間を無駄に取ってしまうという問題も大きかった。
何らかの省略形式を導入することも考えていたが,例えば新規描出日時と時刻部分だけが違う再描出日時の日付部分を省略したとして,それが新規描出の日付と同じことを意味しているのか,今日の日付であることを意味しているのか,一見して理解してもらえるか怪しかった。正しく意図を解釈したとしても,両方の時印を見比べなければならないのは煩雑な気もしていた。
初期状態では片方だけ表示しておけば,ぱっと見て注目すべき時印が分かり,こうした問題は解消する。領当て上の無駄も無くなり,マウスオーバー時と展開固定時に文字色を濃くすることでかえって確認しやすくなった。
最初,非表示要素に datePublished 等を設定しているのはまずいかと思ったが,こういう時のために meta 要素が利用出来たので問題なかった。time.ts_drw に設定していた構造化出与えは meta 要素に移し,リッチリザルト テストでも認識されることを確認した。
2行表示の前提で領当てを整理しておいたことも無駄にならず,時印部に関しては満足出来る仕上がりとなった。
display: block
}{領当て}{通注}{希哲15年3月2日の開発}(57)途中で終了。
描写部下の描き出しボタン/描き直しボタン,時印の領当てに安定感が無いことがずっと気になっていたため,ひたすら試行錯誤していた。
結果,これらをまとめる aside.etc を導入,Flexbox で下揃えにすることで領当てに関してはかなり満足出来るものになった。
time.ts_drw, time.ts_rdrw をまとめていた時印部の span.ts は display: block にしていたため div.ts に,br 要素を削除し time 要素を display: block にして改行するようにした。この辺は過去の試行錯誤で混乱していた部分だった。
この過程で,実装当初から左寄せにしていた描出ボタンを右寄せにした。描き直しボタンは時印部の左側に下揃えで表示される。
ついでに,新規描出フォームの描き出しボタンは文字色を灰色から黒にし,少し目立つようにした。
描出ボタン左寄せは,知名の先頭や行頭に近く目障りなことが多く,徹案としても後景部左上の安定感の無い位置で美しくない,新規描出フォームの鼻付き吹き描きでは自我アイコンを間違って押さないように中途半端な位置に離す必要があったり,通注に被ったりと問題は多々感じていたが,代替案を考える余裕が無かった。ようやくあるべき所に落ち着いたという感じだ。
厳密に言うと,削除機能は優先順位に対して実装難度が高いだけで,実装しないと決めているわけではありません。簡単にアクセス出来,邪魔にならず,間違って削除しにくいような UI を今のデライトのどこに置くか,というのが難しいのです。
だったら「空欄で上書き」というのは簡単で直感的で,別に悪い代替手段じゃないんじゃないか,ということですね。
一般的な掲示板と比較しても,匿名性が高く,変更履歴を残さす自由に書き換えられるシステムで特別「下手なこと書き込めない」ということはないと個人的には思うのですが,全体の雰囲気としてそう感じさせてしまっているのだとしたら,それはそれで考えなければならないことだと思います。
それとは別に,削除機能が無いことが,特に不慣れなユーザーの心理的障害になっている,というのは確かにあると思います。
それは書き込みにくいというより,単純に投稿頻度が低いと余計な輪郭が目障りなのではないか,と考えています。これは,名前も内容もない輪郭は非表示にするような工夫で対応出来るかもしれません。
アンケートというのは良い案だと思います。個別の課題について意見を集めるということは,結果にかかわらず,ユーザーがどうデライトを見ているか,ということを可視化する良い機会になりそうです。早速実施方法を考えてみます。