開閉状態の...大量の情報を整理して快適に閲覧するには、サイドメニューの見出しを分けて整理し、メニューが長大にわたれば部分部分はfoldで畳む操作を施して、サイト構成とメニューの整理は頭を悩ますところです。最近は見出し代わりにaccordionでカテゴリを括って畳むことが多くなっているのですが、サイドメニューにaccordionを用いるのが適切なのかはあまり了知していません。foldにせよaccordionにせよ、メニューに用いた場合、Wikiwikiではそこからいずれかのページに遷移した場合に、メニュー欄のfoldの開閉状態は記憶はされずopen/closeの元の状態に戻ってしまいます。ページを転々と移り読んでいくときには、メニューにある現在関心のあるカテゴリの開いている部分については開いたままにしておいてほしい欲求があります。Wikiwikiだけでない話をして少し恐縮ですが、実は余所のWikiサービスにあるデータベースからの引っ越し移転をすでに何件かやっていて、移植して再構築の際にこちらで再現が難しい件としてそれがあります。「ページ遷移時にfoldの開閉状態を維持する」設定を求めることができますでしょうか。それか、それに代わる操作があれば教えて頂きたいと思います。タイトル内容Markdownが使えます。大量の情報を整理して快適に閲覧するには、サイドメニューの見出しを分けて整理し、メニューが長大にわたれば部分部分はfoldで畳む操作を施して、サイト構成とメニューの整理は頭を悩ますところです。最近は見出し代わりにaccordionでカテゴリを括って畳むことが多くなっているのですが、サイドメニューにaccordionを用いるのが適切なのかはあまり了知していません。foldにせよaccordionにせよ、メニューに用いた場合、Wikiwikiではそこからいずれかのページに遷移した場合に、メニュー欄のfoldの開閉状態は記憶はされずopen/closeの元の状態に戻ってしまいます。ページを転々と移り読んでいくときには、メニューにある現在関心のあるカテゴリの開いている部分については開いたままにしておいてほしい欲求があります。Wikiwikiだけでない話をして少し恐縮ですが、実は余所のWikiサービスにあるデータベースからの引っ越し移転をすでに何件かやっていて、移植して再構築の際にこちらで再現が難しい件としてそれがあります。「ページ遷移時にfoldの開閉状態を維持する」設定を求めることができますでしょうか。それか、それに代わる操作があれば教えて頂きたいと思います。13:22:01ページ内の全ての開閉記録を保持してページ遷移後、記録をページに反映させる機能でよろしいでしょうか?以下の項目を踏まえて引き続き議論いただけたら幸いです。9de72@c3efa自分の関心では、サイドメニュー以外に上の要求を覚えないので、コンパネから一括ですとメニュー編集を凍結してしまうこととだいたい同じです。その必要は感じません。他からの移植について触れてしまったので挙げると、#region(close,remember,テキスト)rememberと書き足すことでコントロールしている例があります。#treemenu(flag=ex)flag=exとかいう、いかがわしい呪文で指示している例もありますが、できるなら読んでそれと意味のわかる文字にしてほしいです。時間が空くと忘れていちいちマニュアルに戻っていた。2「メニューにしか使ったことがない」と言うように、むしろ特殊な用途なので、tablesortのようにそれを適用したい箇所にだけ{{}}で上下囲むという書き方でも間に合います。一括開閉ボタンはほしいです。4私が利用しているWikiではサイドメニューにaccordionとfoldをどちらも使っていますが特に問題ないと思いますよ使った上で適切かどうか判断してそれをこちらに記載するのがいいと思いますサイドメニューにaccordionを用いるのが適切なのかはあまり了知していません。248b0@b30b0ずっと開きっぱなしがいいのであれば、編集時にそうするではだめなんですか?全部開きっぱなしではメニューが冗長になるが、その中で閲覧者が見たい項目は開いたままにしておきたい。6あ、言葉足らずでした全部closeにするか、主要なものだけopenにして他はcloseにするのではだめなんですか?便利な機能だとは思うんですが、1クリックを面倒くさがるかどうかの話なような気がしています。他の情報を見たい場合はクリックする手間は発生すると思うので、無いことのメリットを考えるほうが難しい気がしていますがあんまり魅力を感じないです。一括開閉ボタンでもいい気がします。設定する場合はコントロールパネルからサブパスワード保持者か管理者ができるようにすればいいと思います。詳しくなくて申し訳ないんですが、wikiwikiってゲストユーザ単位で何かを設定するようの画面ってあるんですかね?あればそちらでオンオフするような形にすればいいのかなと思います。全部closeにして一括開閉ボタンを置いたとしても一括開閉をクリックした後にスクロールする二度手間になってしまうのではないでしょうか?そう考えると私は記憶しておいてくれる方がありがたいと思います。たかが1クリックと言えどメニュー内の開閉は一度二度ではありませんから、それが減るというのは大きなメリットでしょう。一括開閉はメニューよりもむしろページ内で活きる機能なのではないかと思います。何らかの長くなる話題を細かく折り畳んでいる際、掻い摘んで読まずに全てを読みたいという場面で役立つでしょうね。今回の要望内容からは外れますし局地的ですが。9うーん、サイドメニューって主要なものだけ必要最低限載せるイメージがあるんですが折り畳みのみを膨大な数載せる使い方をしていると言われたら、個別のWikiの事情になるのでは?どちらにしてもURLのリンク集的な感じではない限り、1度開いた折り畳みを閉じずにずっと見る状況ってなかなかないと思いますが、僕はどちらでもOKです。07856@bfcb5メニューの開閉を覚えておくことの弊害として思いついたんですが、スマホで見る場合はメニューがサイドではなく下に行ってしまうので開いた下のメニューへ行くためには開いた項目を閉じるかさらにスクロールする必要がでてきます。あと、このトピックの趣旨とは異なりますが、長い本文を見てメニューに行きたくなる場合は上までスクロールで戻る必要があるのでメニューと本文が別フレームになってるといいなと思います。メニューの開閉はそのままに本文だけページが変わるようにできたらいいなと思います。スマホでのメニューは編集のメニューみたいに左からピロっと出るようにしてほしいかも。11スマホでのメニューは編集のメニューみたいに左からピロっと出るようにしてほしいかも。こちらは別にトピック立てた方がいいかな?別トピックで詳しく書いていただけたら幸いです。14スマホのことだけではないですがメニューの表示方法についての要望としてトピックを立てました。02:09:44PC閲覧時に便利そうです。状況によって、PCとモバイルを使い分けしながら同じWikiを利用する方には、PCの操作記憶がモバイルでも適用されてしまうと手間が増えて、使い勝手が悪くなります。そのため、同じネット回線でも使用環境が違えば、個別に記憶される仕様なら良いです。その様に利用することが多いので、機能を追加されるのならば配慮していただけると嬉しいです。20:36:05議論していただきありがとうございます。MenuBarに#foldを多数設置した場合、ユーザーによってはいくつもクリックして開くと思います。これらも全て記録した場合、ページ遷移後に見にくくなる気がします。メニューにある現在関心のあるカテゴリの開いている部分については開いたままにしておいてほしい欲求があります。ページ遷移後、「最後にクリックしたリンク」の位置を確認できるようにして、もし、#foldの中だったら開く。このような動きはいかがでしょうか?引き続き議論いただけたら幸いです。13>11で別フレームで本文を表示して本文だけページ遷移する提案をしましたが、これが実現できる場合はメニューの状態はそのままの方がいいと思います。別フレームが実現できなければそれもありかなと思います。07856@bfcb5たくさん#foldを開いた後、戻すために一括開閉があってもいいですが、初期状態に戻すというのもできればほしいと思います。01:09:22「ページ遷移時にfoldの開閉状態を維持する」をメニューに限定せず意見を述べると次の通りです。記憶型foldはあっても良いが、個人的にはメニューでは使わない。ページ本文のほうは使えるかもしれない。)導入するならpluginのオプション書式で従来型か記憶型か選択式であるべき。閲覧者がそのfoldが従来型か記憶型か判別できること。記憶型を初期状態から変えた場合、田マークが点滅してアピールする。初期状態がOpenの場合もあり。リセットコマンドがあること。どこを触ったのか覚えてられないし目で探すのも大変、入れ子になってるとさらに面倒。コマンドリンクはメニューやHeaderに仕込んでおく。リセットがページ毎のなのかサイト全体なのか選べるとなお良いが。クリック)で開きます。W)、リンクを開いた画面に戻ります。操作の煩雑さが人により異なりますが、マウスのボタンに機能を割り当てれば右手だけで完結します。ページ毎に個別にMenuBarを設定するページ毎にメニューは独自に設置できます。各foldのカテゴリーページにはそれらのをopen状態にしたメニュー(#menu(MenuBar/A)とか#menu(MenuBar/B)とか)を設置すれば要求通りの動作になると思います。ページ数が多いと面倒ですが。関連してSideMenu(#side(ページ名))とか、foldカテゴリーを階層化してるならSideBarなどの機能も使えるかもしれません。19ページ毎のMenuBar、私の要求だけならだいたいこれですね。関連ページは多いですが、逆に多いほど使える気分です。念頭から抜けていたので、助かりました。ありがとうございます。23:22:37私も開閉の記憶機能が欲しいです。私がよく使うのはntbrプラグインなのですが、記憶機能があったほうがどこに何があったのかいちいち覚えておく必要がなくて操作が楽になるだろうなと感じていました。22ページ遷移しても開閉状態を保持は、MenuBarに限定しないでほしいです。掲示板書き込みする際の注意事項など何度も往来がある冗長化しやすいページで有効活用できそうです。使用感を評価していただけたら幸いです。掲示板書き込みする際の注意事項など何度も往来がある冗長化しやすいページで有効活用できそうです。これは注意事項に同意したら、持続的に表示するエリアを設ける機能でしょうか?必要であれば新しいトピックで要望を具体的に書いてください。22実装お疲れ様です。使い心地等を試してます。ありがとうございます。80f5d@c3efaaccordionの開閉状態をカテゴリ別に複数のmenubarを分けつつ、各ページごとにカテゴリを指定するのを既に何千件くらいやってしまったですけど、それでも複雑なところを二階層に分けなくて済みそうだと思え、これは「併用」してみるべきだと思いました。背景によっては、デザインテンプレートにあるblackの類だと開閉アイコンがどうも見えないみたいです。0b3fb@39b62プレビューできないのは仮実装だからでしょうか?(評価(テスト)のしようがないのですが...)背景が黒だと開閉ボタンが見えないという指摘も気になります。本当なら大問題ですが、色指定で回避可能でしょうか。木主の本来の要求は、atwikiのregionのrememberオプション(開閉状態を30日間クッキーに保持)をwikiwikiのfoldでも使えるようにして欲しいというモノだったと理解していますが、シンプルにそれではダメなのでしょうか。プレビューできなかったのは、修正中だったからのようですね。アイコンが小さいからか、foldを使用するよりも、1文字分ズレ量が少ない(左側に無駄なスペースができない)のは良いと思います。見栄え的にも文字数の点からも良いと思うのですが、可能でしょうか。あと、初期状態(open/close)への自動リセットは何日後とかありますでしょうか。27ご確認ありがとうございます。黒背景で見えない不具合を修正しました。新しいプラグインでの実装には理由がありますが、まずは純粋に使用感を教えていただけたら幸いです。06aeb@75a79使用してみた感想ですが、カーソルを合わせた際の下線が浮かび上がってくる動きが、リンクと似通っていて誤操作しやすく諦めました。リンクとの差別化をして頂けると幸いです。83e5c@d7d2dnavfoldはfoldよりも折りたたみされた内容との行間が開くのが不恰好だと思います。foldと同じ行間になると嬉しいです。3ef19@87ed2navfoldのほうがメニューバーで使ったときの見た目が良いので、開閉状態を保存しないnavfoldのオプションがあると嬉しいツリー表示タイムライン次を読む要望は具体的な提案や理由を書いて下さい。不適切なコンテンツとして通報するには以下の「送信」ボタンを押して下さい。現在このグループでは通報を匿名で受け付けていません。管理者グループにはあなたが誰であるかがわかります。どのように不適切か説明したい場合、メッセージをご記入下さい。空白のままでも通報は送信されます。あなたの通報と対応時のメッセージを確認できます。背景色(オプション)#埋め込み先の背景色と馴染まない場合に指定して下さい。通常は埋め込み先の背景色をそのまま利用します。文字サイズ(オプション)pxwikiwikiスタイルでは文字サイズやフォントが自動的に調整されます。次のコードをWIKIWIKIのページに埋め込むと最新のコメントがその場に表示されます。スタイルによって自動的に決まります)ここまでがあなたのコンテンツここからもあなたのコンテンツ。