移動済み: BS4対応版グローバルメニューについて
移動済み: BS4対応版グローバルメニューについて
- このトピックには2件の返信、2人の参加者があり、最後に
により5年、 3ヶ月前に更新されました。
-
投稿
-
お陰様でBS4版でorigin2でテストして見ました。一応、本ちゃんサイトは怖いので、本当はいますぐ導入したいくらいでしたが、コピーしたサイトでやってみました。
RICKさんのお陰で、先のことが少し見えてきてスッキリです。この先はVektorさん向けの感想文です。
新しいBS4対応のorigin2の見た印象は概ね今よりも洗練されたような良い感じはしました。
問題だったiPad横場面でのグローバルナビはこれで機能するようにはなったものの、iPadプロ１０インチの画面で操作した印象は、下位メニューを出すマークが非常に小さいので、狙って推すのは心地よく無い印象でした。
私が老眼の為かも知れませんし、指も人より太めだからかも知れませんが、快適な操作性では無いと感じました。
現状の小さな下位メニューのアイコンとなった理由は、親メニューの文字数を稼ぐ為だとは思いますので、それは仕方ないご事情だとは思うのですが、親メニュー文字数に余裕がある場合だけでも、もう少し大きなマークに出来たら押しやすいのにと思いました。あるいは、贅沢かもしれませんが、下位メニューを表示するだけで、親メニューは機能させない設定も増やして頂けたら、メニューの動作を考えて（親メニューも生かす・親メニューは機能しない）選択できたら、その場合は、親メニューのどこを触れても下位メニューが出るので、下位メニューのマークが小さくとも問題にならないと思います。
でも、私は子ページ一覧のファンなので、親ページが不要だとは全く思ってませんので。親メニュー文字数に余裕がある場合だけでも、もう少し大きなマークに出来たら押しやすいのにと思いました。
これについては
* 文字数を自動検出するプログラムを作成する必要がある
* → ソースコードの複雑化がさらに進むのでメンテナンス性が落ちる
* → 処理の増加で速度低下に繋がる
* → 何文字を基準とするのかはユーザーによって好みがわかれるので、その実装の上でまた個別に処理を切り替えたいなどの要望が出て泥沼にハマる事が想定される
* → 文字数による制御機構をつける事により、該当部分メンテナンスの際に各デザインスキンで確認作業が増えるという理由により、文字数を検出して処理を切り分けるという実装は見送らせていただきます。
贅沢かもしれませんが、下位メニューを表示するだけで、親メニューは機能させない設定も増やして頂けたら、メニューの動作を考えて（親メニューも生かす・親メニューは機能しない）選択できたら、その場合は、親メニューのどこを触れても下位メニューが出るので、下位メニューのマークが小さくとも問題にならないと思います。
こにらも同様に、
* 第一階層メニューの処理を切り替えるとなると、メニュー部分をごっそり独自実装する事になりかなり大掛かりな工数がかかる。
* 完全独自実装のメニューにしてしまうと、テーマ作者以外の人がカスタマイズを迫られた際に構造を解析する作業からはじめないといけない、開発者にとって極めて「使いづらい」テーマになってしまいます。
* 設定項目が増えるとユーザーにとっても操作がわかりにくくなる。というデメリットがありますので、プログラムでの処理は見送らせていただきます。
一方で、事の本質は「サブメニューの展開がしにくい」という事なので、これが解消できれば良いわけですから、もう少しだけならテーマ側での調整の余地があるのと、それでもダメな場合は個別に展開部分のCSSを数行追加すれば大きく出来ると思いますので、それにてご容赦いただきたく思います。
テスト・ご意見ありがとうございました。
- このトピックに返信するにはログインが必要です。
