リクエスト広場

views
5 フォロー
780 件中 281 から 320 までを表示しています。
17
名前なし 2023/05/02 (火) 22:05:02 07856@bfcb5

たくさん#foldを開いた後、戻すために一括開閉があってもいいですが、初期状態に戻すというのもできればほしいと思います。

1つのボタンで開閉
2つのボタンで開/閉
3つのボタンで開/閉/初期化
をオプションで選択できればいいな

16
名前なし 2023/05/02 (火) 21:59:40 07856@bfcb5 >> 13

>11で別フレームで本文を表示して本文だけページ遷移する提案をしましたが、これが実現できる場合はメニューの状態はそのままの方がいいと思います。
別フレームが実現できなければそれもありかなと思います。

15
名前なし 2023/05/02 (火) 21:20:59 07856@bfcb5 >> 14

スマホのことだけではないですが
メニューの表示方法についての要望としてトピックを立てました。

1
名前なし 2023/05/02 (火) 21:17:02 07856@bfcb5

ついでにスマホのメニューの提案からの派生ですが、PCのメニューでも閲覧者が任意にメニューを非表示にして本文を広くできるようにしてもいいかもしれません。
ただし、スマホは本文の上にかぶさって現れるイメージですが、PCの場合は本文の幅自体が変化するということなので動作はちょっと異なります。
また、#nomenubarを使っているページに対する動作をどうするかという問題もあります。

4
WIKIWIKI運営 2023/05/02 (火) 20:40:01

「より細かい角度の調節」ができるようになりました。

14
WIKIWIKI運営 2023/05/02 (火) 20:37:50 >> 11

スマホでのメニューは編集のメニューみたいに左からピロっと出るようにしてほしいかも。
こちらは別にトピック立てた方がいいかな?

別トピックで詳しく書いていただけたら幸いです。

13
WIKIWIKI運営 2023/05/02 (火) 20:36:05

議論していただきありがとうございます。
MenuBarに#foldを多数設置した場合、ユーザーによってはいくつもクリックして開くと思います。
これらも全て記録した場合、ページ遷移後に見にくくなる気がします。

メニューにある現在関心のあるカテゴリの開いている部分については開いたままにしておいてほしい欲求があります。

例えば、ページ遷移後、「最後にクリックしたリンク」の位置を確認できるようにして、
もし、#foldの中だったら開く。このような動きはいかがでしょうか?

引き続き議論いただけたら幸いです。

12
款冬華 2023/05/02 (火) 02:09:44

PC閲覧時に便利そうです。状況によって、PCとモバイルを使い分けしながら同じWikiを利用する方には、PCの操作記憶がモバイルでも適用されてしまうと手間が増えて、使い勝手が悪くなります。そのため、同じネット回線でも使用環境が違えば、個別に記憶される仕様なら良いです。その様に利用することが多いので、機能を追加されるのならば配慮していただけると嬉しいです。

11
名前なし 2023/05/02 (火) 01:00:03 07856@bfcb5

メニューの開閉を覚えておくことの弊害として思いついたんですが、スマホで見る場合はメニューがサイドではなく下に行ってしまうので開いた下のメニューへ行くためには開いた項目を閉じるかさらにスクロールする必要がでてきます。

あと、このトピックの趣旨とは異なりますが、長い本文を見てメニューに行きたくなる場合は上までスクロールで戻る必要があるのでメニューと本文が別フレームになってるといいなと思います。
そしてメニューの開閉はそのままに本文だけページが変わるようにできたらいいなと思います。
スマホでのメニューは編集のメニューみたいに左からピロっと出るようにしてほしいかも。
こちらは別にトピック立てた方がいいかな?

10
Yuu 2023/05/01 (月) 10:12:38 修正 >> 9

うーん、サイドメニューって主要なものだけ必要最低限載せるイメージがあるんですが
折り畳みのみを膨大な数載せる使い方をしていると言われたら、個別のWikiの事情になるのでは?
どちらにしてもURLのリンク集的な感じではない限り、1度開いた折り畳みを閉じずにずっと見る状況ってなかなかないと思いますが、僕はどちらでもOKです。

9
名無し 2023/04/30 (日) 22:02:13 248b0@b30b0 >> 6

レディース・メンズのような"主要なものが閲覧者によって異なる"場合、そしてそれが膨大である場合、
全部closeにして一括開閉ボタンを置いたとしても一括開閉をクリックした後にスクロールする二度手間になってしまうのではないでしょうか?
そう考えると私は記憶しておいてくれる方がありがたいと思います。
たかが1クリックと言えどメニュー内の開閉は一度二度ではありませんから、それが減るというのは大きなメリットでしょう。

一括開閉はメニューよりもむしろページ内で活きる機能なのではないかと思います。
何らかの長くなる話題を細かく折り畳んでいる際、掻い摘んで読まずに全てを読みたいという場面で役立つでしょうね。
今回の要望内容からは外れますし局地的ですが。

8
まるね 2023/04/30 (日) 12:02:33

一括開閉ボタンいいですね!メニューバーとかに設置できると利便性高そうです

7

あ、言葉足らずでした
全部closeにするか、主要なものだけopenにして他はcloseにするのではだめなんですか?
便利な機能だとは思うんですが、1クリックを面倒くさがるかどうかの話なような気がしています。

他の情報を見たい場合はクリックする手間は発生すると思うので、無いことのメリットを考えるほうが難しい気がしていますがあんまり魅力を感じないです。一括開閉ボタンでもいい気がします。

設定する場合はコントロールパネルからサブパスワード保持者か管理者ができるようにすればいいと思います。
詳しくなくて申し訳ないんですが、wikiwikiってゲストユーザ単位で何かを設定するようの画面ってあるんですかね?あればそちらでオンオフするような形にすればいいのかなと思います。

2
名前なし 2023/04/29 (土) 19:34:49 51981@623a9

結局この仕様(?)不具合(?)は解消されたのでしょうか。個人的にはreset=newが動いているとは思えないのですが…

利用者としては主要な目的はinclude系プラグインの上限緩和であり、こちらは機能しているので差し迫った問題ではないのですが、
>負荷をかけているWIKIについて
>サーバーに負荷をかけているWIKIはサーバーのリソースを食い潰さないようにするため、
>専用の隔離サーバーにダウングレードいたします。
>積極的にecacheプラグインを使用してください
とあり、reset=newでecacheプラグインを導入しているにも関わらずサーバー負荷軽減に寄与できていないケースがあるとすれば互いに損失かと思います。

6
名無し 2023/04/29 (土) 17:38:59 248b0@b30b0

ずっと開きっぱなしがいいのであれば、編集時にそうするではだめなんですか?

全部開きっぱなしではメニューが冗長になるが、その中で閲覧者が見たい項目は開いたままにしておきたい。という話なのだと思います

他所のサービスですが、PSO2:NGS攻略Wikiのように大規模なWikiの場合に必要とされる機能だと思います
例に挙げた作品はクエスト、フィールド、武器防具、キャラクリと分けても要素が相当量あるので、閲覧者側で開閉を記憶しておけないと少々見辛いでしょうね

5

私が利用しているWikiではサイドメニューにaccordionとfoldをどちらも使っていますが特に問題ないと思いますよ
使った上で適切かどうか判断してそれをこちらに記載するのがいいと思います

サイドメニューにaccordionを用いるのが適切なのかはあまり了知していません。

4
Yuu 2023/04/28 (金) 19:27:08 修正

一括開閉ボタンはほしいです。

利用者目線だと1クリックを面倒くさがるかどうかになるんでしょうか?
ずっと開きっぱなしがいいのであれば、編集時にそうするではだめなんですか?

4

私が利用しているWikiでもここで要望されてる機能はめちゃくちゃほしいです

2
WIKIWIKI運営 2023/04/26 (水) 20:34:26

faプラグインを作成しました。
お試しいただけたら幸いです。

faプラグイン
https://wikiwiki.jp/sample/fa

記事は調整中です。
後日正式にリリースします。

2
名無し 2023/04/26 (水) 16:24:14 248b0@b30b0 >> 1

既知。このトピックの目的と異なる。

6
WIKIWIKI運営 2023/04/26 (水) 13:41:39 >> 4

ご確認ありがとうございます。
要望は「画像やテキストを垂直方向に揃えたい」とのことなので、
お手数ですが、新たにトピックの作成していただいてもよろしいでしょうか。

5
あくあ 2023/04/26 (水) 13:18:53 >> 4

お目通しありがとうございます。

例えば、文字のはじめにアイコンなどを表示したい場合、テキストが下揃えになってしまいます。
表を使用すればその問題は解消することができますが、不要な表の枠が出てきてしまいます。
画像1

他にも01vさんが仰っているような使い方や、下記のサイトのように線を減らし見栄えをよくするような使い方も挙げられます。
https://tsutawarudesign.com/miyasuku1.html

是非検討の程お願い致しますm(_ _)m

4
01v 2023/04/26 (水) 00:34:34

ガシャが具体的にどんなものか分かりませんが。
別ページに記述された1000行の中からアタリ行を抽選するようなゲームであるならば、それは参加者がひたすらページをリロードする状況になるのではないですか。行数の拡張以前にF5アタック同様なのでその使い方を止めたほうが良いでしょう。

1
01v 2023/04/26 (水) 00:10:06

行頭にスペースなり適当なエスケープ文字列を入れて一旦保存。
プラグインとして認識させなけれはページ名に置換される。
改めて編集してエスケープ文字を取り除く。

3

「メニューにしか使ったことがない」と言うように、むしろ特殊な用途なので、tablesortのようにそれを適用したい箇所にだけ{{}}で上下囲むという書き方でも間に合います。

2

自分の関心では、サイドメニュー以外に上の要求を覚えないので、コンパネから一括ですとメニュー編集を凍結してしまうこととだいたい同じです。その必要は感じません。

他からの移植について触れてしまったので挙げると、
 #region(close,remember,テキスト)
rememberと書き足すことでコントロールしている例があります。

また、
 #treemenu(flag=ex)
flag=exとかいう、いかがわしい呪文で指示している例もありますが、できるなら読んでそれと意味のわかる文字にしてほしいです。時間が空くと忘れていちいちマニュアルに戻っていた。

3

同様の上限にかかる件に最近当たりましたので報告します。それなりに重要なテーマを含んでいると思います。まず、自分の編集者/管理者としての関心は、テキスト情報の収集、整理編纂、その快適な閲覧に集中しており、情報をまとめる記事を作成し関連項目への誘導整理を行う際に「何事かをランダムに表示すること」に興味が寄りません。

randommesについては存在は知っていましたが、所詮おまけのお遊びの機能だと思っていました。Wiki上でゲームや何かのシミュレーターを作る必要もないです。ですが、このたび扱った内容が「多数のキャラクター(人物)のプロフィール」であったことと、そのプロフィール作成の作業中にキャラクターのポートレートに当たる画像を挿むように進んだとき、多数の中から無作為に選んだワンショットをちら見せ、そういうものを常時表示させておくことで、閲覧者の関心を惹く目的ではそこそこ意味がある。固有の利用形態だと思いました。

それでヘッダエリアに入れてみたところ、なかなか面白い。「まず目を引き、最初に読み始める興味関心をそこから始める」意味で、これは使えます。

作成中なりに8000件のようなシャッフルをのほほんと想像してしまいましたが、やってみると早速500上限に当たりました。案の定かと臍を噛んだものの、管理者としては上の方針であり、このコンテンツ自体サイトの主目的では絶対になく、「本当に必要か」といえば不要なことはあらためて言います。また、上限があることについてはWIKIWIKI運営の方の通りにすぐに腑に落ちました。

「500」という具体的な数については判断できないものの、判断できないものは運営の方針にお任せすればよく、制限があればその制限にしたがうべきとの考えに至り、その後は500以内でシャッフルの条件を適宜可変にする形に収めています。8000を空想し、実用的に要るのは300くらいでした。その際に意識に昇ったのは、情報の編集・編纂は常にその操作より、操作を行う意図が重要という基本です。扱う対象が多ければ何ブロックかに分けてそこそこの数ごとに仕分けるようにすれば、その仕分けの意図を考え直す機会にもなるかと思います。実際に馬鹿げた操作をしかけてから上限に気づくので、上限数についてはマニュアルに載せておいてください。

1
WIKIWIKI運営 2023/04/25 (火) 13:30:39

AVIF image format につきまして、検討いたします。

WikiWikiはアップロードサイズの容量制限が厳しいため、数秒間のショート動画を掲載する際にこのような高圧縮形式に対応していただけていると非常に助かります。

本来の目的がショート動画の埋め込みなら別の要望になると思います。

1
WIKIWIKI運営 2023/04/25 (火) 13:22:01

ページ内の全ての開閉記録を保持してページ遷移後、記録をページに反映させる機能でよろしいでしょうか?
以下の項目を踏まえて引き続き議論いただけたら幸いです。

  • 設定はゲストユーザーかコントロールパネル内で一括か
  • それぞれのゲストユーザーが設定する場合のやり方
  • 常時開閉が記録されることについて不便なことはないか
  • 他の機能で代用することができるか
    例えば一括開閉ボタンを作るとか
2
WIKIWIKI運営 2023/04/25 (火) 13:10:43

動的に動かす機能はコストがかかります。
WIKIの機能として本当に必要なのかも踏まえて、引き続き議論をお願いします。

1
WIKIWIKI運営 2023/04/25 (火) 13:07:27

同様のトピックが作成されましたので、
こちらで議論をお願いします。
https://zawazawa.jp/wikiwiki-request/topic/188

1
WIKIWIKI運営 2023/04/25 (火) 13:06:18

同様のトピックがありましたのでまとめます。

リクエスト広場
randommesの上限
randommesプラグインの上限が500行までになってますが この上限を開放するか上げてほしいです。
zawazawa

1
WIKIWIKI運営 2023/04/25 (火) 12:52:11

プラグインの引数にプラグインを指定することは非推奨です。

都度ページ名をコピペする手間を省けるので、置換されるようになると嬉しいです。

本来のやりたいことを別のトピックで要望として、議論していただけたら幸いです。

4
WIKIWIKI運営 2023/04/25 (火) 12:36:18 >> 3

例えば1500x1500でアップロードした画像もサイズを100x100に指定したら100x100の画像になって転送量を削減できるということですか?

はい、極端な例ですとそうなります。
実際は妥当な画像サイズに最適化されます。

また、一度読み込んだ画像はキャッシュに保存されブラウザ更新してもキャッシュから読み込まれますか?

はい、ブラウザのキャッシュがあればそちらから読み込みます。


画像の最適については、以下のトピックもご確認ください。

表示画像の最適化について
https://zawazawa.jp/wikiwiki-request/topic/184

4
WIKIWIKI運営 2023/04/25 (火) 12:12:47 >> 3

どのような場面で表組の枠線を消したいのでしょうか?
レイアウトでの使用なら、別の要望になると思います。

3
あくあ 2023/04/24 (月) 23:51:44 修正 >> 2

例えば1500x1500でアップロードした画像もサイズを100x100に指定したら100x100の画像になって転送量を削減できるということですか?
また、一度読み込んだ画像はキャッシュに保存されブラウザ更新してもキャッシュから読み込まれますか?

2
名前なし 2023/04/23 (日) 19:20:45 修正 07856@bfcb5

「最近更新されたWiki」は必要ないからやめてくれということなのか、「一日単位での追記件数」ランキングを作ってくれというのか
結局、何を要望しているのか分かりにくいです。

以下は昔のWIKIWIKIのよくある質問を抜粋したものです。

WIKIWIKI.jp*トップの「最近更新されたWIKI」に載らないようにするにはどうすればいいの?

現在「最近更新されたWIKI」に載らないようにする設定はございません。
情報公開された開放的な形での運用となりますので、閉鎖的なコミュニティの使用には向いておりません。
(全体的に大手検索エンジンに比較的早く上位表示されているようです。)

これを見て「最近更新されたWIKI」って検索サイトのクローラーに見つけてもらうためにあるんじゃないかと勝手に思ってます。
更新しても数時間で埋もれてしまうのでタイミングが合わなければだめですけどね。
自分の作ったWikiも一切宣伝してませんが訪問者が来るようになりましたし。
関係ないですが、WIKIWIKIにはいくつのWikiがあるんでしょうね。どこかで公表してましたっけ?

話がそれましたが「ネットに存在するあらゆるWikiに関心を持ちながらその通知を見ている人」とはまさに「検索サイトのクローラー」なんじゃないでしょうか。(人じゃないけど)
ということで「最近更新されたWIKI」は必要だと思いますよ。

4
名前なし 2023/04/23 (日) 10:27:43 f94fd@7752b

こちらの希望としてはrecent・zrecentと全く同じ表示ですので、>> 2はその場しのぎとしてはありかなぁ、という印象です。
類似の話題で言及されている通りlsxは重めのものですので、長年愛用して数万ページに達しているとまた話は別なのかなと。
zawazawaのより手軽な利用方法要望については別トピックで議論したほうがいいと思います。

1
Yuu 2023/04/21 (金) 22:31:11 修正

Wiki編集ってボランティア活動の一種だと思いますが、その行為を評価するのって必要なんですか?というか確認できる仕組みを求めてることに強い疑問を感じます。
そちらが積極的に編集に参加していて、他の編集者のアクティビティを見たいという意見なら分からなくもないですが、編集に参加しない人側からの視点での意見ということであれば取り下げたほうがいいです。

調べたらでてくるボランティアの4原則などを一度見てみてください。