{進捗記録}{方向}{}{以前}{描写}{進捗}{デライト}{希哲17年1月15日の進捗}{希哲17年1月15日の開発}{希哲17年1月15日}(116)

{希哲17年1月15日10歩 K#F85E/E74C-36C0}

進捗時限記録中略

ついでに新規描出フォーム固定機能についても検討して終了

こちらは「限りなく廃案近い保留」となった。


全知検索窓固定機能同様デライト最初期実装削除したものだが,これは広告との相性以前に,用合いとしていまいちだったということが大きい

新規描出フォーム固定出来れば,輪郭一覧眺めながら描写書くことも出来便利違いない,と素朴な期待から実装してみたが,これが帯に短し襷に長しという感じ思いのほか使えなかった

大きな原因は,ページ遷移までのちょっとした固定されるだけ,という中途半端さにあった。あちこち飛びながら作業しているといちいち解除されるので,自然に使わなくなっていく

これに対処しようとすると画面分割機能近い大掛かり仕掛け必要になる画面分割機能何度も検討したが,やはりデライトには過剰判断して,複数窓使いやすくする方向単純性保ってきた今考えてもこれは英断だった。

自動ページ展開輪郭一覧動的更新がある今なら当時よりは使いようがあるかもしれないが,その分,ページ遷移条件分かりにくくなっているので,かえってストレスかもしれない。

複数窓使いにくいスマートフォンなどでも,新規描出フォーム柔品キーボード画面ほとんど占有されるため恐らく使いものにならない当時諸場使える状態ではなかったので想像ではあるが,複数タブ使う方がマシだろう。

結局構造的にデライト向きではないのだろうと思うが,急いで結論を出す必要もない。そのうち適当な活用法見つかればいいし,見つからなくても問題ない。というわけで,しばらく放置しておくことにした。

迷い一つ消えたのは収穫言える

{開発}{開発記録}{輪括弧}{👀}{👍}{希哲16年8月28日}{希哲16年8月27日}{< おつかれさまです!!!}{想定より}{操作体系}(224)

{希哲16年8月28日の開発 K#F85E/E74C-FC4D}

第二次用合い改良輪郭小窓実装

じっくり調整して満足出来る仕上がりになったため,輪郭小窓実装ここで一段落とすることにした。まだこまごまとした課題残っているため第二次用合い改良継続する

また,次の当努包括的な全知検索整備決めた検索結果改良はもちろん,大幅な高速化望めるまた大工事になるが,一応月内完了目標とする次の全知検索整備も「第〜次〜」と呼ぶことを考えたが,ちょくちょく手を入れているため区切り難しいとりあえず新生全知検索整備」と呼んでおくことにした。

輪郭候補窓輪郭小窓の無番輪符対応については少し迷ったが,どちらも全知検索利用するため作業効率考えて新生全知検索整備後に回すことにした。

輪郭小窓雑感

輪郭小窓については,機能見触れともに十分な完成度達した言える昨日手こずったタッチ事象上手く整理出来るようになった。

装体関しては初回出振るい時には小さめにした前後景部閉じるボタン大きめ修正した輪郭小窓の様子・完成形視覚的な無駄削ったつもりだったが,他要素被るものなので小さい視認操作難がある見た目思ったより良い感じ出来た

アンカーテキスト輪符展開するだけだった従来の用合い比べると劇的な進歩だ。デライトの用合い転換点になるだろう。

第二次用合い改良雑感

読み込み中...
{開発}{開発記録}{描写部}{輪郭小窓}{希哲15年7月23日の日記}{難がある}{総合的に勝る}{開始操作}{二度押し}{希哲15年7月23日}(42)

{希哲15年7月23日の開発 K#F85E/E74C-8F83}

輪郭小窓引き入れボタンに加え,輪郭小窓から引き放ち出来るようにすることを考え始めた。タッチ端末での引き放ち式再現難しいという課題があったが,これで解決しそうだ。特に開始操作長押し舞覧機能干渉二度押しダブルタップダブルクリックに合わせたい)採用しにくかった。

引き放ち式個人機でも操作性挙動難があり,調整必要を感じていたため奇跡的丁度良かった

これが決め手となり,描写部に限らず前後景輪符輪郭小窓統一諸場も統一することを決めたタッチ操作ではページ移動に二回タップ必要になってしまうことから少し迷いがあったが,輪郭小窓利点総合的に勝るだろう。

{進捗記録}{進捗}{描写部}{用者}{溶暗付きスクロール}{iOS 13}{希哲15年3月11日の開発}{位置調整}{mask-image}{スクロール可能}(44)

{希哲15年3月11日9歩 K#F85E/E74C-21E2}

デライト装体調整

諸場ブラウザではスクロールバーが常時表示されないため,描写部スクロール可能なことが分かりにくいという問題があったが,これは続きがある方向に内容溶暗するような効果を付けることで上手く解決しそうだ。線を引く,印を付けるなどよりもさりげなく直感的分かりやすい

諸場でなくても,内容が途中で切れるのが美観的に気になっていたので丁度良い。

これなら描写後略機能透過的実現出来る。用者は普通にスクロールを続ける感覚で続きを取得することが出来る。

最初は -webkit-scrollbar 等を適当に設定して済ませるつもりだったが,iOS 13 以降の Safari では無効らしく,代替手段を探していた。結果的にはより洗練された手段が見つかった。

mask-image を使えばこの手の効果を付けるのは簡単だが,スクロールバーにまでマスクがかかってしまうのが気に入らなかった。

linear-gradient()背景にした独自のマスク要素を作り,位置調整スクリプトで行うことにした。

急ぐことではないため装体のみ作っておいて終了。

{進捗記録}{進捗}{捕活}{希哲15年2月27日の開発}{ソフトウェアキーボード}{希哲15年2月27日の進捗時限}{希哲15年2月27日の進捗}{希哲15年2月27日}{前後景部整理}{デライト文書構造最適化}(21)

{希哲15年2月27日5歩 K#F85E/E74C-4ED2}

デライト文書構造最適化引き入れ欄挙動調整

いったん終了。

捕活し直すようにしたことで今度は諸場貼り付けソフトウェアキーボードが表示されてしまう問題が発生。これは一時的に readonly 属性を付けることで解決

思ったより落とし穴が多く時間がかかったが,視認性はそれなりに向上した。

捕活が外れた時に引き入れ欄の内容を削除出来るようにしたかったが,表示上,引き入れに成功したのか取り消したのか分かりにくいこともあり,今は欲張らず中景輪符整理後の前後景部整理に回すことにした。

{諸場}

{}