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

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

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


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

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


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

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

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

{進捗記録}{十分}{曖昧}{輪郭整備}{希哲16年9月}{進捗}{デライト市場戦略}{Firefox}{希哲17年1月7日の開発}{希哲17年1月7日の進捗}(210)

{希哲17年1月7日20歩 K#F85E/E74C-370E}

進捗時限記録中略

知名欄描写欄捕活フォーカス関する仕様検討結果ともにマウスオーバー捕活する仕様確定実装した出振るい手定め済み

なお,知名欄自動全選択については正式に廃止決定した


仕様というほど明確なものではなく,時期によって実装上機能しないこともあったものの,デライト初期実装からのマウスオーバー時の挙動は,知名欄では捕活全選択描写欄では捕活,という方針だった。これは実用上の都合というのも大きく,こうでなければ単純に描出効率悪かった

昨年9月までの第二次用合い改良中の交度整理で,知名欄捕活全選択機能しなくなっていた。これは確か中景輪符事象イベント改良したことで干渉懸念があり,再実装後回しにしたという経緯だった気がするもっと地味な描写欄捕活過去に何度か再実装した記憶があるものの,どの時点機能しなくなっていたのかは曖昧だが,いずれにせよ第二次用合い改良後はどちらもマウスオーバーでの捕活すら機能しなくなっていた

もしかしたらこれはこれで今のデライトでは悪くないのかもしれないと少し様子を見ていたが,輪郭整備のように描出効率重要な作業になると,クリックでの捕活やはりまどろっこしく,鈍重感じる。そこで最近はかつての挙動復活させる機会窺っていた

懸念は,他要素他機能との干渉誤操作だったが,これは昨日の検討から急速に氷解した今のデライトで,マウスオーバー捕活移動すること自体前提のようなところがあるので用者体験大きな悪影響はないだろうということ,むしろほとんどの要素マウスオーバー反応するのに知名欄描写欄無反応なことが直感性損ねているとも言えること,スクロールとの干渉実際の舞覧ブラウザでは生じないこと,誤編集問題については,そもそも閲覧編集用合い切り分けていることが一定の保護機能になっており,更に取り消しボタン変更有無分かるようになることで大きく軽減されること,などの理由で,大きな問題はないという結論に達した

そこでまず,知名欄全選択含めてマウスオーバーでの捕活機能復活させてみたところが知名欄全選択については数十分廃止決定することになった。実装上の問題としては,選択状態やはり周辺要素干渉する干渉しないようにマウスアウト解除すると,今度は選択状態意図せず解除されやすくなる。もっと問題なのは,誤入力上書きしてしまいやすいということだった。全知検索窓では再検索のためにも上書きしやすい全選択状態好都合だが,知名欄での利点写し取り素早く行えることくらいでさほど大きくない

これは,今のデライトで,慣れ切ったこの挙動からいったん離れなければ気付かなかったことかもしれない。今のデライト市場戦略から考えても熟練用者向け過ぎ採用出来ない

次に知名欄全選択機能し,捕活だけにしてみると,これはむしろ想像以上に好感触だった。地味ながら編集軽快感明らかに向上している捕活さえしてくれれば Ctrl + A写し取り十分効率的に行える今のデライトとの相性でいえば理想形とすら思えた。ここで正式な仕様として確定することにした。なお,捕活時発生するスクロール意図しない場合多く考えられるため抑止する

どこまで普遍的な現象分からないが,常用している LinuxFirefox では,<textarea>選択状態残して捕活解除すると,再選択のつもりが未捕活状態のせいで)意図しない文字列ドラッグ発生しやすいため,これがなくなったのは個人的に嬉しかった近頃多用している複数輪符引き入れ欄への写し貼り障害になっていた。

とにかく第二次用合い改良後に残っていたもやもやしたものを払拭出来たのは大きかった

{開発}{開発記録}{希哲16年9月30日}{希哲16年9月30日の副日記}{嬉しい結果}{全文検索時}{索引更新}{非標準機能}{導入しやすかった}{移行過程}(59)

{希哲16年9月30日の開発 K#F85E/E74C-10E9}

{開発}{開発記録}{方向}{希哲16年5月30日}{高さ制限}{内容の高さ}{機能的に}{混乱させない}{用者層}{利用率}(93)

{希哲16年5月30日の開発 K#F85E/E74C-DB91}

自動ページ展開機能実装一段落した細部に課題はあるが,実用出来る水準に達した出振るい手定め済み

これに伴い正式離立前試していた全知検索窓新規描出フォームの固定表示復活させる検討大きく進んだ。また,輪郭一覧動的追加仕組み整えたことで,検索新規描出時にも応用出来るようになった。輪郭一覧の更新効率的に行えるようになり,高速化にも大きく貢献するだろう。


AutoPagerize 対応どうするかというのが難しい問題だったが,これは挿入監視して削除注意書き表示する方向落ち着いた最初以外 .autopagerize_page_elementdisplay: none設定しておくことで表示には影響しない

AutoPagerize は,ウェブ利用者全体ではわずかな利用率だが,デライト用者使っているのを見て私自身使うようになったというのもあり,用者層重なり小さくない出来るだけ混乱させないようにしたかった。


今後広告の調整重要になってくるため,ここで運営者開発者向けダミー広告表示する仕組み整えたダミー広告の様子

AdSense は,設置者によるクリックもちろん無闇に表示させることも避けるべきとされているので,これまでは単に非表示にしていた


機能的に自動ページ展開機能似たところがある描写後略機能実装方針検討ほぼ完了

内容の高さ高さ制限足りない場合どうするか最後の課題だったが,これは舞覧側で追加取得すればいいことに気付いて解決した


{復活させる}

{}