要望を受け,中景輪符写し取りアイコンの下余白をクリック/タップしても写し取り出来るようにして終了。写し取りアイコン部分の height
を20px増やした。
輪括弧とアイコンだけが機能するというのは理論上特に不自然ではないが,単純に押しやすくはなる。余白をクリックしてしまう心理は正直よく分からなかったが,「要素が横に広がっているのだから余白に見えるところも矩形要素の一部に違いない」という高度な先入観なのかもしれない。
@elm.bld.
}(52)再描出後の描写縮小ボタンが機能していないことに気付き修正して終了。未出振るい。
@elm.bld..init_scrl_shdw()
による多重初期化が発生していた。必要以上に呼び出されていることも問題だが,同様のことはいくらでも起こりうるので,.init_scrl_shdw()
に多重初期化防止の仕組みを導入しておいた。流石に @elm.bld.
に余計な変数は持たせられないため,出与え属性で初期化済みフラグを持たせておく。
描写拡大の状態で輪郭選り手を開き,取り消しボタンで閉じると描写拡縮ボタンの挙動がおかしくなる問題も発見し修正。未出振るい。
描写拡縮は機能するがボタンが反転しなかった。こちらは単純な選択子の問題だった。
深刻な不具合修正とボタン周りの挙動改良,輪郭削除ボタンでのみ輪郭削除が機能するように仕様を明確化・実装修正し装体調整(7歩)。これまでも輪郭削除ボタンを押下するのが輪郭削除の公式手順だったが,実装上は知名・描写を空にして送信すれば機能した。
不具合修正と輪郭削除ボタンの装体調整がきっかけで,やりたかった輪郭選り手の変更有無を表現する閉じるボタン(×ボタン)の装体イメージもまとまった。
検討中に新規描出フォームの細かい不具合も見つけたのでまとめて調整することにした。
第二次用合い改良でそれ以前にあった「知名欄にマウスオーバーすると自動的に捕活・全選択する」という機能が消えていたが,これを復活させるか検討。
特に意図したことではなく,当初は単に交度整理後の再実装を後回しにしていただけなのだが,これはこれで悪くないかもしれないと様子を見ていた。やはり写し取りに不都合を感じることが多く,全知検索窓との挙動の整合性もあるので復活に傾きかけていたものの,もう少し様子を見ることにした。
マウスカーソルが頻繁に横断する部分なので,捕活がころころ移ると別の問題が色々起きてくるだろう。これをやると描写欄にもマウスオーバーで捕活させたくなるが,そうなると誤編集の可能性も高くなる。その他,スクロールとの干渉など,相互作用を色々考えなくてはならない。
lightpink
}{pink
}{誤認しやすかった}{同じ装体}(116)スマホから連続タップで輪郭が削除されてしまったという深刻な不具合報告を受け,修正作業と輪郭削除ボタンの装体調整。
不具合については,描き直しボタンの連打で読み込み中に送信が発生し,知名・描写が空の状態なので輪郭削除と認識してしまう,という可能性が濃厚だったため,以下の修正を行った。
b_cfm_udrw
のような求頼変数を付けて後縁でも確認させることを検討したが,現時点では過剰と判断し見送った。どの道,前縁が間違った出与えを送れば危険性は大して変わらない。むしろ,上書きされるより輪郭削除が間違って動作してくれた方が取り返しがつく。
非常に収穫の多い気分転換として輪郭整備に時間を割くようになったが,やっているうちに,むしろこれこそ今やるべきことなのではないかという気がしてきた。
もともと輪郭量に対して輪括量・描写量が少な過ぎるという問題があったが,優先順位の問題でなかなか本格的な輪郭整備は進まなかった。第二次快調期を経て描出効率も発信能力も飛躍的に向上し,十分な時間対効果が期待出来るようになっている。
もう一つ,他用者への波及効果が意外と大きい感触がある。やはり,私自身が活発に描出しているかどうかで他用者の賑わいも違う気がする。この用者の少なさで一番の重用者なので,当然といえば当然だ。
開発に没頭していた期間,大きな収穫があっても用者の反応に乏しいということがよくあり,違和感を覚えていた。一つの理由として,そういう時期は待欄が進捗記録などの事務的な記録で埋まりがちで,献典として面白くないということがあったのかもしれない。
先日の日記では,Twitter の騒動を利用することに関して消極的な見方をしていたが,よく考えると,そもそも「Twitter ではない Twitter のようなもの」が失敗してきた理由は,Twitter との差別化が出来ていなかったからだ。この場合,KNS としてのデライトの革新性は,障害ではなく近道として機能するかもしれない。積極的に利用することを考えるべきか。
面白いのは,デライトのキャズムについて最近考えていたこととの対比だ。個人知識管理通類の用者層は意外と保守的であり,大きな変化を望んでいない人が多い。それはメモと自己保存欲求の相性の良さから来ているのではないか,と考えていた。先述の用者の反応に乏しい問題にも通じるが,新機能を追加しても意外と喜んでもらえない。こうした層向けには,印迫よりも安心感を与える施策が必要なのだろう。
この二方面への売り込み方を上手く使い分け,組み合わせることで新しい道が開けそうだ。
前歩についてまとめながら,角括弧と知番による輪結の可能性に気付いたため急遽まとめて終了。
多重輪括弧が閲覧専用模動で後景一覧・輪郭ページへの輪結として機能するなら,その逆に閲覧専用模動への輪結手段があってもいい。いま角括弧と URL の組み合わせ([アンカー https://example.com]
)に対応している輪結記法を [アンカー K#XXXX/XXXX]
の形で使えるようにするのが自然だろう。
更に,これは閲覧専用模動では同模動で普通の輪結になるのが自然なので,前歩で書いた「閲覧専用模動で強調も輪括弧の表示もせずに輪符を輪結化したいという場合」にも上手く対応出来る。
ここまでで若干もやもやしていた閲覧専用模動周りの仕様が大分くっきりしてきた。
キーボード記法に関しては,改めて [_X_]
記法を中心にしていく方針で再確定した。また,[_X_] + [_Y_]
を一つの記法として扱うことも明確化した。
[_X_]
記法を導入して一件落着かと思ったキーボード記法だが,その後,少し迷いが生じていた。
この記法がボタンらしく見え過ぎるせいで,ウィジェットのボタンにも応用出来る「ボタン記法」のようなものも可能なのではないかという欲が出てしまっていた(AsciiDoc にはボタンやメニューを表現出来るマクロがある)。それが可能なら,[_X_]
をキーボード記法とすべきではないかもしれない,という気がした。
ただ,[_X_]
をキーボード記法を一般化した「ボタン記法」にしようかと考えてみたところで,そもそも千差万別の外観を持つウィジェットボタンを抽象的に表現出来る装体が存在しないことに気付いて廃案となった。確かに記号としてみるとボタンらしいのだが,ボタンらしい装体を付けようとすると全くイメージと違うものになってしまう。これではあまり意味が無い。あくまでも言語的に扱うか,視覚的に扱いたければ画像素材を行内埋め込み記法で挿入するのが適切だろう。
そう考えると,キーボードのキーに使う装体がキーの記号としてちゃんと機能するのは特殊な例だ。