1歩  2歩  3歩  4歩  5歩
 6歩  7歩  8歩  9歩 10歩
11歩 12歩 13歩 14歩 15歩
16歩 17歩 18歩
{希哲17年1月15日18歩 K#F85E/E74C-2F5F}
宇田川浩行全知検索窓固定機能に吊るし輪郭への輪結と新規描出フォームへの輪結を加えるアイデアについてまとめて終了。
画像素材は,背景用の二輪鎖,上矢印と+のアイコンといずれも既存のものを使い,自我アイコンの左側に配置する。幅狭領当てでは,入力欄への捕活時に隠れ,入力欄が伸長するようにする(開発者通類で作った案)。
新規描出フォームへの素早い握接は長いあいだ課題だったが,これも急に解決してしまった。新規描出フォーム固定機能との関連で考えることが多く,今回も先の検討中に考え始めた。
右下あたりに輪結を固定させるのがよくある方式だが,何度考えてもデザイン的なまとまりに欠ける。何より幅狭領当てでは重なりが気になる。明らかに邪魔だろう。
新規描出フォームの左上にある+ボタンは元々新規描出フォーム固定機能を兼ねていたので,これをスクロールに追随させて,どこでも新規描出フォームを呼び出せるようにするか……等々,これまでとにかくあらゆる案を検討したが,どの案にも何かしら問題があった。さっき方針が固まった全知検索窓固定機能に合わせ,下スクロールで現れるバーにしても,せっかくの占有領域を減らす工夫が相殺されてしまう。
デライトの構造上仕方ないこと,と新規描出フォーム固定機能のように諦めかけたが,こうなったらもう全知検索窓を何とか利用するしかないのではないか,と再び考え出したのが良かった。
<aside>
}{<header>
}{新生デライトの当努}{練ってきた}(54){希哲17年1月15日14歩 K#F85E/E74C-195F}
宇田川浩行{希哲17年1月15日10歩 K#F85E/E74C-36C0}
宇田川浩行ついでに新規描出フォーム固定機能についても検討して終了。
全知検索窓固定機能同様,デライト最初期に実装・削除したものだが,これは広告との相性以前に,用合いとしていまいちだったということが大きい。
新規描出フォームを固定出来れば,輪郭一覧を眺めながら描写を書くことも出来て便利に違いない,と素朴な期待から実装してみたが,これが帯に短し襷に長しという感じで思いのほか使えなかった。
大きな原因は,ページ遷移までのちょっとした間固定されるだけ,という中途半端さにあった。あちこち飛びながら作業しているといちいち解除されるので,自然に使わなくなっていく。
これに対処しようとすると画面分割機能に近い大掛かりな仕掛けが必要になる。画面分割機能は何度も検討したが,やはりデライトには過剰と判断して,複数窓で使いやすくする方向で単純性を保ってきた。今考えてもこれは英断だった。
自動ページ展開や輪郭一覧動的更新がある今なら当時よりは使いようがあるかもしれないが,その分,ページ遷移の条件が分かりにくくなっているので,かえってストレスかもしれない。
複数窓が使いにくいスマートフォンなどでも,新規描出フォームと柔品キーボードで画面がほとんど占有されるため恐らく使いものにならない。当時は諸場で使える状態ではなかったので想像ではあるが,複数タブで使う方がマシだろう。
結局,構造的にデライト向きではないのだろうと思うが,急いで結論を出す必要もない。そのうち適当な活用法が見つかればいいし,見つからなくても問題ない。というわけで,しばらく放置しておくことにした。
{希哲17年1月15日6歩 K#F85E/E74C-C29A}
宇田川浩行新生デライトの要件ではなかったが,デライト最初期に実装・削除してからずっと保留状態にあった全知検索窓固定機能の実装イメージが急速に固まったのでまとめて終了。
全知検索窓では,下スクロールで隠れ上スクロールで現れる固定表示を採用することにした。
昨日,寝る前に Android 版 Chrome を触っていて思いついた(上スクロールでツールバーが現れる)。以前にもこの方式を検討した記憶があるが,その時は流してしまった。昨年,新規描出フォーム固定機能とともに大きく検討を進めたことがあった(開発記録)ので,時期的な噛み合わせだろう。
いったん削除した理由,その後復活させられなかった理由は主に二つあった。
一つは,広告との相性の問題だ。AdSense では広告に固定メニューのようなものが被ることもグレーとされている。実際には悪質でなければそこまで厳しく対応されることはないだろうが,広告頼みのデライトではわずかなリスクでも避けたかった。
もう一つは,画面を広く使いたい場合に邪魔になることがあり,必ずしも便利ではなかったことだ。当然,スマートフォンのような小型端末ではこの問題が顕著になる。
昨年の検討では,広告に近付いたら隠すようにすることと,表示領域の高さが十分ではない場合は固定機能を無効にすることでこれらの問題を回避する方針を固め,復活に向けて一歩前進した。しかし,実装と調整の煩雑さに対して必要性が高まらず,ここまで実作業に至らなかった。
今回採用を決めた方式なら,調整の手間はほとんどかからず,交度も半分くらいで済みそうだ。無くてもそこまで困らない機能ではあるが,これくらい実装コストが下がれば優先順位も上げられる。