{希哲15年3月7日の開発}{0.05秒}{0.3秒}{判定処理}{希哲15年3月7日の進捗時限}{希哲15年3月7日の進捗}{希哲15年3月7日}{通注}{@trap()}{デライト文書構造最適化}=}(35)

{希哲15年3月7日7歩 K#F85E/A-E74C-F9B8}

デライト文書構造最適化事象関連のスクリプト整理,細かい不具合修正

途中で終了。

最低限の形を整えていったん出振るい

色々試してみると,通注は気付きやすく邪魔になりにくい線で0.3秒要素展開0.05秒,その他選択化などは遅来無し,で丁度良い。よく触れる機能は0.1秒でも遅来があると意外にもたつきを感じる。

@trap()タイマー保持重複しないようにする,という修正はいったん差し戻し

干渉で上手く動かない場合があり,これを回避しようと込み入った判定処理を加えると本末転倒なので,タイマー生成しっぱなしの最初実装様子見

=}
{設定時間}{マウスオーバー過敏}{前後景輪符}{描写内輪符}{大輪符}{小輪符}{輪符要素整理}{@trap()}{希哲15年3月6日}{デライト文書構造最適化}=}(27)

{希哲15年3月6日の開発 K#F85E/A-E74C-8979}

Aejs@trap()考案実装し,かねてよりの「マウスオーバー過敏」とでもいうべきデライトの課題が概ね解決

ただ,まだ設定時間調整の余地がある。

事象まわりを弄っているうちに新しい不具合に気付き,修正ついでに輪符要素整理に入ることにした。

輪符は概ね大輪符中景輪符),小輪符前後景輪符描写内輪符)に分けることが出来るが,それぞれが異なる構造挙動を持っているため保守性足枷になっていた。

いずれにせよ,文書構造最適化の最後で片付けるつもりだったので,多少前後しただけでやることは変わらない。

{希哲15年3月6日の開発}{輪符要素整理}{希哲15年3月6日の進捗時限}{希哲15年3月6日の進捗}{希哲15年3月6日}{デライト文書構造最適化}{進捗記録}{進捗時限記録}{進捗時限}{方針}=}(11)
{希哲15年3月6日の開発}{輪符要素整理}{a.knm}{a.ikon}{希哲15年3月6日の進捗時限}{希哲15年3月6日の進捗}{希哲15年3月6日}{デライト文書構造最適化}{中景輪符整理}{中景輪符}=}(35)

{希哲15年3月6日8歩 K#F85E/A-E74C-3B23}

デライト文書構造最適化事象関連のスクリプト整理,細かい不具合修正

途中で終了。

ここで文書構造最適化合流させることにした。スクリプト保守性に大きく関わるため,まずは中景輪符整理で整えた中景輪符以外の輪符要素整理に入る。

ここは初期実装から試行錯誤連続で,かなり混乱しており一貫性も無い。そのせいでスクリプト複雑化してしまっている。

描写部a.oln から展開される a.ikon構造化されておらず,単純に文字列として輪符が入っている。

前後景部spn.ikon はもっとひどくa.knm 内に知番を突っ込んでいる。

=}
{希哲15年3月5日の開発}{構造化出与え}{非表示要素}{省略形式}{%Y-%m-%d %T}{2行}{希哲15年3月5日の進捗時限}{希哲15年3月5日の進捗}{希哲15年3月5日}{時印部}=}(61)

{希哲15年3月5日7歩 K#F85E/A-E74C-C9C1}

デライト文書構造最適化中景部微調整

途中で終了。

これまで再描出日時がある場合は新規描出日時の上に2行表示していた時印部だが,初期状態では新規描出日時を隠しておき,マウスオーバー時に表示させるようにした。クリックタップで表示を固定解除することも出来る。

時印文書としては正確把握出来た方が良く,個人的には時計代わりに見たいことも多いので,昔から SNS 等でよくある「〜前」という表示嫌いだった。デライトでは %Y-%m-%d %T の形式を採用しそれなりに気に入っていたが,難点も感じていた。

特に,時印を2つ並べた時に文字の固まりとして目障りであり,視認性も良くなかった。比較して見たいことも考えると縦2行しかないが,ぱっと見判別しにくい。単純に縦方向の空間無駄に取ってしまうという問題も大きかった。

何らかの省略形式を導入することも考えていたが,例えば新規描出日時と時刻部分だけが違う再描出日時の日付部分を省略したとして,それが新規描出の日付と同じことを意味しているのか,今日の日付であることを意味しているのか,一見して理解してもらえるか怪しかった。正しく意図を解釈したとしても,両方の時印を見比べなければならないのは煩雑な気もしていた。

初期状態では片方だけ表示しておけば,ぱっと見て注目すべき時印が分かり,こうした問題解消する。領当て上の無駄も無くなり,マウスオーバー時と展開固定時に文字色を濃くすることでかえって確認しやすくなった。

最初,非表示要素datePublished 等を設定しているのはまずいかと思ったが,こういう時のために meta 要素利用出来たので問題なかった。time.ts_drw に設定していた構造化出与えmeta 要素に移し,リッチリザルト テストでも認識されることを確認した。

2行表示の前提で領当てを整理しておいたことも無駄にならず,時印部に関しては満足出来る仕上がりとなった。

出振るい済み

=}
{通注}{最初期実装}{希哲15年3月4日の進捗時限}{希哲15年3月4日の進捗}{希哲15年3月4日}{デライト文書構造最適化}{描き直す?}{描き直しボタン}{描き出しボタン}{描出ボタン}=}(55)

{希哲15年3月4日5歩 K#F85E/A-E74C-2402}

デライト文書構造最適化中景部微調整

途中で終了。

統一感の無かった描出ボタン描き出しボタン描き直しボタン)と通注表現調整

ラベルには「描き直す?」と表示しておき,押すと「描き直す」に変わっていた描き直しボタンを「描き直す」と「完了」の組み合わせ修正。これに合わせ通注も「〜で編集」から「〜で描き直す」,「〜で保存」から「〜で完了」という表現統一

新規描出フォームでは描き出しボタンに合わせ通注の「〜で保存」を「〜で描き出す」に統一。

通注最初期実装から分かりやすさ重視し「編集」と「保存」の表現を使っていたが,その後,描出ボタン実装するにあたってボタンのラベルには「描き出す」,「描き直す」を使い,通注の方を放置していたことでこうした不統一が生じていた。

いずれにせよ描き出し描き直しデライトのごく基本的用語なので必ず理解してもらう必要があり,Twitter における「ツイート」同様ブランディング一環でもあるため,常に表示されているボタンには使わざるをえない(ここで使わなくて済むならそもそも特別な用語自体必要ない)。

ここで「編集」や「保存」などの用語が混在していることは好ましくないとは感じていたが,微妙に使い分けたいこともあり難しいところだった。

描き出しはともかく,描き直し編集欄を開く操作保存する操作があるため,これのために「」を使うという苦肉の策を取ったりしていた。後者のために「保存」を残すかとも考えたが,「完了」が一番自然であることに気付き決着

ちょっとしたことのようで大分すっきりしたように感じる。

=}
{非録入り状態}{デライト語体}{希哲15年3月4日の進捗時限}{希哲15年3月4日の進捗}{希哲15年3月4日}{×輪結}{デライト文書構造最適化}{共有ボタン}{自我アイコン}{くぐり検索}=}(43)

{希哲15年3月4日4歩 K#F85E/A-E74C-27F9}

デライト文書構造最適化中景部微調整

途中で終了。

輪郭ページくぐり検索同様中景部右上に表示していた×輪結削除し,非録入り状態ではデライト語体を表示しへの輪結とすることにした。ここに置く予定の共有ボタン未実装なため,録入り中は何も表示されないことになる。

検索流入急増してきている今,この動線が無いのは問題だった。

これまで輪郭ページは単なるくぐり検索転用だったため,検索演心等から来た訪問者が何のサイトなのか分からないという問題はずっと認識していたが,意外に難しかった。

非録入り状態×輪結を扉への輪結に置換するという考えは以前からあったものだが,くぐり検索輪郭ページ未分化だったため,検索上の便宜との兼ね合いで見送っていた。

代替案として全知検索窓左部分にデライト語体を表示するというのもあったが,やはり自我アイコンの表示部分という役割が分からなくなるのでこれも使えなかった。

最近,輪郭ページ閲覧共有向けという役割明確になってきたこともあり,昨日,寝る前に×輪結自体が輪郭ページでは不要なのではないかと気付いた。

これで最低限処置は出来ただろう。

=}
{希哲15年3月4日の進捗時限}{希哲15年3月4日の進捗}{希哲15年3月4日}{鼻部整理}{デライト文書構造最適化}{中景部}{進捗記録}{進捗時限記録}{進捗時限}{微調整}=}(12)
{良い傾向}{実り多い}{希哲15年3月3日}{うなぎのぼり}{デライト文書構造最適化}{『希哲日記』}{デライト開発}{デライト}{宝の持ち腐れ}{検索演心最適化}=}(14)

{希哲15年3月3日の日記 K#F85E/A-E74C-5CC8}

今日もデライト開発実り多かった。

文書構造最適化を始めた頃から,デライトSEO 関連指標うなぎのぼりになっている。まだその先に繋がっていないが,非常に良い傾向だ。

そもそも構造的に SEO に強くないわけがないので,これまでが宝の持ち腐れだったのだろう。ここから本領発揮ということにしたい。

=}
{鼻部}{鼻部整理}{デラングの交度対応}{デラング}{デライトのオフライン対応}{希哲15年3月3日}{デラングの数式対応}{デライト文書構造最適化}{出振るい}{領当て}=}(23)

{希哲15年3月3日の開発 K#F85E/A-E74C-67F1}

デラングの数式対応デラングの交度対応デライトのオフライン対応,今後のデラング方向性について検討1歩2歩3歩4歩)。

その後,デライト文書構造最適化中景部微調整の続きに入り,出振るい

領当ては概ね満足出来るものとなったが,一部の場面で鼻部ずれがひどくなった。

兼ねてよりブラウザによっては滑らかに見えないことが気になっていたので,明日以降「鼻部整理」として抜本的改良取り組むことにした。