{高さ制限}{内容の高さ}{機能的に}{混乱させない}{用者層}{利用率}{ウェブ利用者}{影響しない}{設定しておく}{最初以外}...=}(92)

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

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

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


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

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


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

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


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

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


=}
{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{Aejs_DG_rev}{長期的視野に立って}{更新方法}...=}(224)

{希哲16年5月23日の開発 K#F85E/E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

=}
{なおかつ}{制御しやすい}{握接出来る}{選り手を開く}{操作手順}{複製輪郭}{ボタンを押す}{ずっと考えていた}{視認出来る}{スクロール完了}...=}(116)

{希哲16年5月18日の開発 K#F85E/E74C-2BA8}

長い間課題だった描写拡縮ボタン輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発最大化アイコン出来たことをきっかけに,描写拡縮ボタン実装イメージ固まり,実装手定めまで概ね完了した想像以上に早く上手くまとまった下見機能との相性も良い。ただし輪郭選り手抜控機能整備途中であるため未出振るい

描写拡縮機能的には単純だが,用合い特に領当て難しかった最近描写部下境界重ねる形での実装考えていたが,描写部飛び出す他の要素干渉してしまう。かといって余白無駄に広げたくない。これは,下部陰影重ねつつ,初期化時点スクロール可能な場合は下余白追加することで解決した文字暗い背景色重なっても視認出来るように,半透明白背景付けた

拡大ボタンスクロール可能であることの目印としても効果的なので,これを活かしてスクロール完了時には透明度を上げ,それと分かるようにした。

これで,外観操作感ともにデライト調和した描写拡縮ボタン出来た描写部高さ固定一覧性確保するために必要なものだったが,用合い上弊害小さくなかった陰影付きスクロール最大化アイコン,そして描写拡縮ボタンによって,ようやくこの問題解決した

輪郭複製機能

輪郭複製機能課題としてずっと考えていたが,用合い上難しさがあった。

ボタンを押すことで複製輪郭出来る,というのは使用頻度考える誤操作懸念の方が大きい。となると,目立たないように置くしかない。かといって,操作手順増えると,選り手を開いて写し貼りするのと大差ない

簡単に握接出来て,なおかつ制御しやすい用合い必要だった。ここで,「知名描写複製して新規描出フォーム移動するボタン」があればいいことに気付いた。これなら,自輪郭常に表示しておいてもいいだろう。

輪郭選り手では×ボタンがある位置置けそうだ。

{表示}

{}