1週前に更新されました。#19157momo参加者お陰様でBS4版でorigin2でテストして見ました。一応、本ちゃんサイトは怖いので、本当はいますぐ導入したいくらいでしたが、コピーしたサイトでやってみました。RICKさんのお陰で、先のことが少し見えてきてスッキリです。この先はVektorさん向けの感想文です。新しいBS4対応のorigin2の見た印象は概ね今よりも洗練されたような良い感じはしました。問題だったiPad横場面でのグローバルナビはこれで機能するようにはなったものの、iPadプロ10インチの画面で操作した印象は、下位メニューを出すマークが非常に小さいので、狙って推すのは心地よく無い印象でした。私が老眼の為かも知れませんし、指も人より太めだからかも知れませんが、快適な操作性では無いと感じました。現状の小さな下位メニューのアイコンとなった理由は、親メニューの文字数を稼ぐ為だとは思いますので、それは仕方ないご事情だとは思うのですが、親メニュー文字数に余裕がある場合だけでも、もう少し大きなマークに出来たら押しやすいのにと思いました。贅沢かもしれませんが、下位メニューを表示するだけで、親メニューは機能させない設定も増やして頂けたら、メニューの動作を考えて(親メニューも生かす・親メニューは機能しない)選択できたら、その場合は、親メニューのどこを触れても下位メニューが出るので、下位メニューのマークが小さくとも問題にならないと思います。私は子ページ一覧のファンなので、親ページが不要だとは全く思ってませんので。1週前に変更しました。1週前に変更しました。親メニュー文字数に余裕がある場合だけでも、もう少し大きなマークに出来たら押しやすいのにと思いました。文字数による制御機構をつける事により、該当部分メンテナンスの際に各デザインスキンで確認作業が増えるという理由により、文字数を検出して処理を切り分けるという実装は見送らせていただきます。贅沢かもしれませんが、下位メニューを表示するだけで、親メニューは機能させない設定も増やして頂けたら、メニューの動作を考えて(親メニューも生かす・親メニューは機能しない)選択できたら、その場合は、親メニューのどこを触れても下位メニューが出るので、下位メニューのマークが小さくとも問題にならないと思います。第一階層メニューの処理を切り替えるとなると、メニュー部分をごっそり独自実装する事になりかなり大掛かりな工数がかかる。完全独自実装のメニューにしてしまうと、テーマ作者以外の人がカスタマイズを迫られた際に構造を解析する作業からはじめないといけない、開発者にとって極めて「使いづらい」テーマになってしまいます。設定項目が増えるとユーザーにとっても操作がわかりにくくなる。いうデメリットがありますので、プログラムでの処理は見送らせていただきます。一方で、事の本質は「サブメニューの展開がしにくい」という事なので、これが解消できれば良いわけですから、もう少しだけならテーマ側での調整の余地があるのと、それでもダメな場合は個別に展開部分のCSSを数行追加すれば大きく出来ると思いますので、それにてご容赦いただきたく思います。テスト・ご意見ありがとうございました。kurudriveが編集しました。素人の発言なのにも関わらず、真剣に検討頂き、ご丁寧な説明を頂きまして、ありがとうございます。(全3件中)このトピックに返信するにはログインが必要です。