{開発}{開発記録}{知名}{描写}{希哲17年1月6日の副日記}{考えなくてはならない}{高くなる}{誤編集}{起きてくる}{横断する}(93)

{希哲17年1月6日の開発 K#F85E/E74C-4249}

深刻な不具合修正ボタン周り挙動改良輪郭削除ボタンでのみ輪郭削除機能するように仕様明確化実装修正装体調整7歩これまでも輪郭削除ボタン押下するのが輪郭削除公式手順だったが,実装上知名描写空にし送信すれば機能した


不具合修正輪郭削除ボタン装体調整きっかけで,やりたかった輪郭選り手変更有無表現する閉じるボタン×ボタン装体イメージまとまった

検討中新規描出フォーム細かい不具合見つけたのでまとめて調整することにした。


第二次用合い改良それ以前にあった「知名欄マウスオーバーすると自動的に捕活全選択する」という機能消えていたが,これを復活させる検討

特に意図したことではなく,当初は単に交度整理後の再実装後回しにしていただけなのだが,これはこれで悪くないかもしれないと様子を見ていたやはり写し取り不都合感じることがく,全知検索窓との挙動整合性もあるので復活傾きかけていたものの,もう少し様子を見ることにした。

マウスカーソル頻繁に横断する部分なので,捕活ころころ移る別の問題色々起きてくるだろう。これをやると描写欄にもマウスオーバー捕活させたくなるが,そうなると誤編集可能性高くなる。その他,スクロールとの干渉など,相互作用色々考えなくてはならない

{進捗記録}{知名}{描写}{進捗}{希哲17年1月6日の進捗}{便利だった}{lightpink}{pink}{誤認しやすかった}{同じ装体}(116)

{希哲17年1月6日7歩 K#F85E/E74C-4A35}

{進捗記録}{『希哲日記』}{日記}{}{}{輪郭整備}{与える}{KNS}{デライト市場戦略}{希哲16年11月6日}(125)

{希哲16年11月6日の日記 K#F85E/E74C-5CA2}

定休日なので輪郭整備をしながらのんびり過ごした

非常に収穫の多い気分転換として輪郭整備時間を割くようになったが,やっているうちにむしろこれこそやるべきことなのではないかという気がしてきた

もともと輪郭量対して輪括量描写量少な過ぎるという問題があったが,優先順位問題でなかなか本格的な輪郭整備進まなかった第二次快調期経て描出効率発信能力飛躍的に向上し,十分な時間対効果期待出来るようになっている。

もう一つ他用者への波及効果意外と大きい感触がある。やはり,私自身活発に描出しているかどうかで他用者賑わい違う気がする。この用者の少なさ一番重用者なので,当然といえば当然だ。

開発に没頭していた期間大きな収穫があっても用者の反応乏しいということがよくあり,違和感を覚えていた一つの理由として,そういう時期待欄進捗記録などの事務的な記録埋まりがちで,献典として面白くないということがあったのかもしれない。


デライト市場戦略についての面白い気付きもあった。

先日の日記では,Twitter騒動利用することに関して消極的な見方をしていたが,よく考えるとそもそもTwitter ではない Twitter のようなもの」が失敗してきた理由は,Twitter との差別化出来ていなかったからだ。この場合,KNS としてのデライトの革新性は,障害ではなく近道として機能するかもしれない。積極的に利用することを考えるべきか。

面白いのは,デライトのキャズムについて最近考えていたこととの対比だ。個人知識管理通類用者層意外と保守的であり,大きな変化望んでいない多い。それはメモ自己保存欲求相性の良さから来ているのではないか,と考えていた。先述の用者の反応乏しい問題にも通じるが,新機能追加しても意外と喜んでもらえない。こうした向けには,印迫よりも安心感与える施策必要なのだろう。

この二方面への売り込み方上手く使い分け組み合わせることで新しい道開けそうだ。

7日振り返り日記

{進捗記録}{}{知番}{輪括弧}{進捗}{希哲16年1月31日}{輪結}{希哲16年1月31日の開発}{希哲16年1月31日13歩}{普通の輪結}(44)

{希哲16年1月31日14歩 K#F85E/E74C-B7D8}

前歩についてまとめながら角括弧知番による輪結可能性気付いたため急遽まとめ終了

多重輪括弧閲覧専用模動後景一覧輪郭ページへの輪結として機能するなら,その閲覧専用模動への輪結手段があってもいい。いま角括弧URL組み合わせ[アンカー https://example.com]対応している輪結記法[アンカー K#XXXX/XXXX] の形で使えるようにするのが自然だろう。

更に,これは閲覧専用模動では同模動普通の輪結になるのが自然なので,前歩書いた閲覧専用模動強調輪括弧表示もせずに輪符輪結化したいという場合」にも上手く対応出来る。

ここまでで若干もやもやしていた閲覧専用模動周りの仕様が大分くっきりしてきた。

{進捗記録}{記号}{進捗}{希哲16年1月23日}{AsciiDoc}{特殊な例}{生じていた}{再確定}{ボタン記法}{希哲16年1月23日の進捗時限}(55)

{希哲16年1月23日4歩 K#F85E/E74C-6C79}

キーボード記法についての再検討終了

キーボード記法に関しては,改めて [_X_] 記法中心にしていく方針再確定した。また,[_X_] + [_Y_] を一つの記法として扱うことも明確化した。


[_X_] 記法導入して一件落着かと思ったキーボード記法だが,その後,少し迷い生じていた

この記法ボタンらしく見え過ぎるせいで,ウィジェットボタンにも応用出来る「ボタン記法」のようなものも可能なのではないかというが出てしまっていたAsciiDoc にはボタンメニュー表現出来るマクロがある)。それが可能なら,[_X_]キーボード記法とすべきではないかもしれない,という気がした

ただ,[_X_]キーボード記法一般化した「ボタン記法」にしようかと考えてみたところで,そもそも千差万別外観を持つウィジェットボタン抽象的表現出来る装体存在しないことに気付いて廃案となった。確かに記号としてみるとボタンらしいのだが,ボタンらしい装体を付けようとすると全くイメージと違うものになってしまう。これではあまり意味が無い。あくまでも言語的に扱うか,視覚的に扱いたければ画像素材行内埋め込み記法挿入するのが適切だろう。

そう考えると,キーボードキーに使う装体キー記号としてちゃんと機能するのは特殊な例だ。

{機能する}

{}