一括開閉ボタンはほしいです。
利用者目線だと1クリックを面倒くさがるかどうかになるんでしょうか？ ずっと開きっぱなしがいいのであれば、編集時にそうするではだめなんですか？
私が利用しているWikiでもここで要望されてる機能はめちゃくちゃほしいです
faプラグインを作成しました。 お試しいただけたら幸いです。
faプラグイン https://wikiwiki.jp/sample/fa
記事は調整中です。 後日正式にリリースします。
既知。このトピックの目的と異なる。
ご確認ありがとうございます。 要望は「画像やテキストを垂直方向に揃えたい」とのことなので、 お手数ですが、新たにトピックの作成していただいてもよろしいでしょうか。
お目通しありがとうございます。
例えば、文字のはじめにアイコンなどを表示したい場合、テキストが下揃えになってしまいます。 表を使用すればその問題は解消することができますが、不要な表の枠が出てきてしまいます。
他にも01vさんが仰っているような使い方や、下記のサイトのように線を減らし見栄えをよくするような使い方も挙げられます。 https://tsutawarudesign.com/miyasuku1.html
是非検討の程お願い致しますm(_ _)m
ガシャが具体的にどんなものか分かりませんが。 別ページに記述された1000行の中からアタリ行を抽選するようなゲームであるならば、それは参加者がひたすらページをリロードする状況になるのではないですか。行数の拡張以前にF5アタック同様なのでその使い方を止めたほうが良いでしょう。
行頭にスペースなり適当なエスケープ文字列を入れて一旦保存。 プラグインとして認識させなけれはページ名に置換される。 改めて編集してエスケープ文字を取り除く。
「メニューにしか使ったことがない」と言うように、むしろ特殊な用途なので、tablesortのようにそれを適用したい箇所にだけ{{}}で上下囲むという書き方でも間に合います。
自分の関心では、サイドメニュー以外に上の要求を覚えないので、コンパネから一括ですとメニュー編集を凍結してしまうこととだいたい同じです。その必要は感じません。
他からの移植について触れてしまったので挙げると、 #region(close,remember,テキスト) rememberと書き足すことでコントロールしている例があります。
また、 #treemenu(flag=ex) flag=exとかいう、いかがわしい呪文で指示している例もありますが、できるなら読んでそれと意味のわかる文字にしてほしいです。時間が空くと忘れていちいちマニュアルに戻っていた。
同様の上限にかかる件に最近当たりましたので報告します。それなりに重要なテーマを含んでいると思います。まず、自分の編集者/管理者としての関心は、テキスト情報の収集、整理編纂、その快適な閲覧に集中しており、情報をまとめる記事を作成し関連項目への誘導整理を行う際に「何事かをランダムに表示すること」に興味が寄りません。
randommesについては存在は知っていましたが、所詮おまけのお遊びの機能だと思っていました。Wiki上でゲームや何かのシミュレーターを作る必要もないです。ですが、このたび扱った内容が「多数のキャラクター(人物)のプロフィール」であったことと、そのプロフィール作成の作業中にキャラクターのポートレートに当たる画像を挿むように進んだとき、多数の中から無作為に選んだワンショットをちら見せ、そういうものを常時表示させておくことで、閲覧者の関心を惹く目的ではそこそこ意味がある。固有の利用形態だと思いました。
それでヘッダエリアに入れてみたところ、なかなか面白い。「まず目を引き、最初に読み始める興味関心をそこから始める」意味で、これは使えます。
作成中なりに8000件のようなシャッフルをのほほんと想像してしまいましたが、やってみると早速500上限に当たりました。案の定かと臍を噛んだものの、管理者としては上の方針であり、このコンテンツ自体サイトの主目的では絶対になく、「本当に必要か」といえば不要なことはあらためて言います。また、上限があることについてはWIKIWIKI運営の方の通りにすぐに腑に落ちました。
「500」という具体的な数については判断できないものの、判断できないものは運営の方針にお任せすればよく、制限があればその制限にしたがうべきとの考えに至り、その後は500以内でシャッフルの条件を適宜可変にする形に収めています。8000を空想し、実用的に要るのは300くらいでした。その際に意識に昇ったのは、情報の編集・編纂は常にその操作より、操作を行う意図が重要という基本です。扱う対象が多ければ何ブロックかに分けてそこそこの数ごとに仕分けるようにすれば、その仕分けの意図を考え直す機会にもなるかと思います。実際に馬鹿げた操作をしかけてから上限に気づくので、上限数についてはマニュアルに載せておいてください。
AVIF image format につきまして、検討いたします。
WikiWikiはアップロードサイズの容量制限が厳しいため、数秒間のショート動画を掲載する際にこのような高圧縮形式に対応していただけていると非常に助かります。
本来の目的がショート動画の埋め込みなら別の要望になると思います。
ページ内の全ての開閉記録を保持してページ遷移後、記録をページに反映させる機能でよろしいでしょうか？ 以下の項目を踏まえて引き続き議論いただけたら幸いです。
動的に動かす機能はコストがかかります。 WIKIの機能として本当に必要なのかも踏まえて、引き続き議論をお願いします。
同様のトピックが作成されましたので、 こちらで議論をお願いします。 https://zawazawa.jp/wikiwiki-request/topic/188
同様のトピックがありましたのでまとめます。
プラグインの引数にプラグインを指定することは非推奨です。
都度ページ名をコピペする手間を省けるので、置換されるようになると嬉しいです。
本来のやりたいことを別のトピックで要望として、議論していただけたら幸いです。
例えば1500x1500でアップロードした画像もサイズを100x100に指定したら100x100の画像になって転送量を削減できるということですか？
はい、極端な例ですとそうなります。 実際は妥当な画像サイズに最適化されます。
また、一度読み込んだ画像はキャッシュに保存されブラウザ更新してもキャッシュから読み込まれますか？
はい、ブラウザのキャッシュがあればそちらから読み込みます。
画像の最適については、以下のトピックもご確認ください。
表示画像の最適化について https://zawazawa.jp/wikiwiki-request/topic/184
どのような場面で表組の枠線を消したいのでしょうか？ レイアウトでの使用なら、別の要望になると思います。
例えば1500x1500でアップロードした画像もサイズを100x100に指定したら100x100の画像になって転送量を削減できるということですか？ また、一度読み込んだ画像はキャッシュに保存されブラウザ更新してもキャッシュから読み込まれますか？
「最近更新されたWiki」は必要ないからやめてくれということなのか、「一日単位での追記件数」ランキングを作ってくれというのか 結局、何を要望しているのか分かりにくいです。
以下は昔のWIKIWIKIのよくある質問を抜粋したものです。
WIKIWIKI.jp*トップの「最近更新されたWIKI」に載らないようにするにはどうすればいいの？ 現在「最近更新されたWIKI」に載らないようにする設定はございません。 情報公開された開放的な形での運用となりますので、閉鎖的なコミュニティの使用には向いておりません。 （全体的に大手検索エンジンに比較的早く上位表示されているようです。）
WIKIWIKI.jp*トップの「最近更新されたWIKI」に載らないようにするにはどうすればいいの？
現在「最近更新されたWIKI」に載らないようにする設定はございません。 情報公開された開放的な形での運用となりますので、閉鎖的なコミュニティの使用には向いておりません。 （全体的に大手検索エンジンに比較的早く上位表示されているようです。）
これを見て「最近更新されたWIKI」って検索サイトのクローラーに見つけてもらうためにあるんじゃないかと勝手に思ってます。 更新しても数時間で埋もれてしまうのでタイミングが合わなければだめですけどね。 自分の作ったWikiも一切宣伝してませんが訪問者が来るようになりましたし。 関係ないですが、WIKIWIKIにはいくつのWikiがあるんでしょうね。どこかで公表してましたっけ？
話がそれましたが「ネットに存在するあらゆるWikiに関心を持ちながらその通知を見ている人」とはまさに「検索サイトのクローラー」なんじゃないでしょうか。(人じゃないけど) ということで「最近更新されたWIKI」は必要だと思いますよ。
こちらの希望としてはrecent・zrecentと全く同じ表示ですので、>> 2はその場しのぎとしてはありかなぁ、という印象です。 類似の話題で言及されている通りlsxは重めのものですので、長年愛用して数万ページに達しているとまた話は別なのかなと。 zawazawaのより手軽な利用方法要望については別トピックで議論したほうがいいと思います。
Wiki編集ってボランティア活動の一種だと思いますが、その行為を評価するのって必要なんですか？というか確認できる仕組みを求めてることに強い疑問を感じます。 そちらが積極的に編集に参加していて、他の編集者のアクティビティを見たいという意見なら分からなくもないですが、編集に参加しない人側からの視点での意見ということであれば取り下げたほうがいいです。
調べたらでてくるボランティアの4原則などを一度見てみてください。
ご対応ありがとうござます。Headerが意図したとおり表示されることを確認しました。
この不具合の対応で上記の現象が発生しました。🙇♂️
大変遅くなり申し訳ございません。 :Header でも flexbox が動作するように対応いたしました。
実は :Header や MenuBar はスタイルに「特別ルール」が実装されています。 例えば、:Header は表組の枠線が表示されません。
昔からレイアウトを組む方法として表がよく使われてきました。 :Header では 表組にデータを入れる用途で使われないため、レイアウト専用として枠線を消していました。
このガラケー時代の名残が原因で flexbox が動作しておりませんでした。 今は flexbox があるので、不具合の原因になりやすい :Header の「特別ルール」を無くすことを検討しております。 もし、:Header で表組でレイアウトを組んでおられる方は flexbox でレイアウトを組むようにしてください。
対応いたしました。 大変ご迷惑をおかけいたしました。🙇♂️
【不具合解消のお知らせ】不具合の原因となっている箇所を修正し、2023年4月19日(水)20時43分に不具合が解消されました。大変ご迷惑をおかけしました。— WIKIWIKI【公式】 (@WIKIWIKI_Japan) April 19, 2023
【不具合解消のお知らせ】不具合の原因となっている箇所を修正し、2023年4月19日(水)20時43分に不具合が解消されました。大変ご迷惑をおかけしました。
時間を置いて元の内容を記述したところ、直りました。 一時的に発生した不具合の模様です。
ご不便をおかけして申し訳ございません。 対応しておりますので、今しばらくお待ちください。
【不具合のお知らせ】2023年4月19日(水)20時20分頃から、レイアウトが一部崩れる現象が発生しております。現在、調査しております。ご不便をおかけして申し訳ございません。今しばらくお待ちください。— WIKIWIKI【公式】 (@WIKIWIKI_Japan) April 19, 2023
【不具合のお知らせ】2023年4月19日(水)20時20分頃から、レイアウトが一部崩れる現象が発生しております。現在、調査しております。ご不便をおかけして申し訳ございません。今しばらくお待ちください。
ChromeとFirefoxで瞬時に表示されることを確認しました。 ご対応ありがとうございました。
申し訳ございません。 アイコンが常時表示される不具合が発生しておりました。 修正し、正常に動作するようにいたしました。
特定の文字列の「表記ゆれ文字の対応処理」でブラウザに負荷がかかっていたようです。 この機能を無効化して対処いたしました。
共有ありがとうございます。 結論から申し上げますと、負荷は問題ないと思われます。
外部画像も最適化を行っています。 実際にインラインで表示されている画像は最適化済みです。(413KB) もとの画像サイズと比較して十分最適化されています。
相手側(cdn.discordap)へのアクセスはインライン表示では、ほぼゼロです。 クリック時に拡大表示させた時だけ相手側のCDNから直接読み込みます。(6.6MB) ここだけ相手側とユーザー側に負荷(転送量含む)が発生します。
相手側の画像は、閉じられた空間でのアクセスを想定されていると思いますので、一度ご確認いただけたらと思います。
参考: 「外部サービスの画像コンテンツの貼り付けについて」
もし回避できる方法があればご教示いただければ対応いたします。
例えばこのページの上部に設置している画像になります。 現在は閲覧数は落ち着いてますが、6月～8月くらいになると閲覧数が爆上がりします。 https://wikiwiki.jp/eft/CUSTOMS
別の機能で提供できることもあるので、 その機能がどのような目的で必要なのかを教えていただければと思います。
上記の現象を確認しました。 調査いたしますので、今しばらくお待ちください。 ご不便をおかけして申し訳ございません。
具体的にどの画像でしょうか？ 掲載しているページのURLと表示させている画像を教えてください。
同感です。 フラッシュ機能は、使い方によっては、かつてのポケモンショック同様、 閲覧者に対し光過敏性発作を引き起こしかねません。 チカチカ鬱陶しいだけですし、個人的にも要りません。
点滅文字は設定次第で目にダメージが入ります。 そもそもスクロール文字を実装しているのは昔からの名残であると認識しており、その観点からも新たな追加は不要であると思っています。
どうしてもというのであれば、フェードイン/フェードアウトかつ、フェードインからフェードアウトまで3秒以上など、目に優しい形で制限するならば構いません。
応答不能になる例のリンク先は、ほんらいハイライトされるべきURLの文字列がハイライトされませんね。 タスクマネージャを見ていると表示が完了するまでブラウザーのCPU使用率が高いままです。 HTML Convert timeは短いことから、クライアント側の処理が上手く行ってないように見えます。 ただ普通にブラウザー側の機能の文字列検索を使えば一瞬で対象がハイライトされます。wikiwikiがhtmlに仕込ませてるscript処理になにか問題があるのだと思います。
一括開閉ボタンはほしいです。
利用者目線だと1クリックを面倒くさがるかどうかになるんでしょうか？
ずっと開きっぱなしがいいのであれば、編集時にそうするではだめなんですか？
私が利用しているWikiでもここで要望されてる機能はめちゃくちゃほしいです
faプラグインを作成しました。
お試しいただけたら幸いです。
faプラグイン
https://wikiwiki.jp/sample/fa
記事は調整中です。
後日正式にリリースします。
既知。このトピックの目的と異なる。
ご確認ありがとうございます。
要望は「画像やテキストを垂直方向に揃えたい」とのことなので、
お手数ですが、新たにトピックの作成していただいてもよろしいでしょうか。
お目通しありがとうございます。
例えば、文字のはじめにアイコンなどを表示したい場合、テキストが下揃えになってしまいます。
表を使用すればその問題は解消することができますが、不要な表の枠が出てきてしまいます。
他にも01vさんが仰っているような使い方や、下記のサイトのように線を減らし見栄えをよくするような使い方も挙げられます。
https://tsutawarudesign.com/miyasuku1.html
是非検討の程お願い致しますm(_ _)m
ガシャが具体的にどんなものか分かりませんが。
別ページに記述された1000行の中からアタリ行を抽選するようなゲームであるならば、それは参加者がひたすらページをリロードする状況になるのではないですか。行数の拡張以前にF5アタック同様なのでその使い方を止めたほうが良いでしょう。
行頭にスペースなり適当なエスケープ文字列を入れて一旦保存。
プラグインとして認識させなけれはページ名に置換される。
改めて編集してエスケープ文字を取り除く。
「メニューにしか使ったことがない」と言うように、むしろ特殊な用途なので、tablesortのようにそれを適用したい箇所にだけ{{}}で上下囲むという書き方でも間に合います。
自分の関心では、サイドメニュー以外に上の要求を覚えないので、コンパネから一括ですとメニュー編集を凍結してしまうこととだいたい同じです。その必要は感じません。
他からの移植について触れてしまったので挙げると、
#region(close,remember,テキスト)
rememberと書き足すことでコントロールしている例があります。
また、
#treemenu(flag=ex)
flag=exとかいう、いかがわしい呪文で指示している例もありますが、できるなら読んでそれと意味のわかる文字にしてほしいです。時間が空くと忘れていちいちマニュアルに戻っていた。
同様の上限にかかる件に最近当たりましたので報告します。それなりに重要なテーマを含んでいると思います。まず、自分の編集者/管理者としての関心は、テキスト情報の収集、整理編纂、その快適な閲覧に集中しており、情報をまとめる記事を作成し関連項目への誘導整理を行う際に「何事かをランダムに表示すること」に興味が寄りません。
randommesについては存在は知っていましたが、所詮おまけのお遊びの機能だと思っていました。Wiki上でゲームや何かのシミュレーターを作る必要もないです。ですが、このたび扱った内容が「多数のキャラクター(人物)のプロフィール」であったことと、そのプロフィール作成の作業中にキャラクターのポートレートに当たる画像を挿むように進んだとき、多数の中から無作為に選んだワンショットをちら見せ、そういうものを常時表示させておくことで、閲覧者の関心を惹く目的ではそこそこ意味がある。固有の利用形態だと思いました。
それでヘッダエリアに入れてみたところ、なかなか面白い。「まず目を引き、最初に読み始める興味関心をそこから始める」意味で、これは使えます。
作成中なりに8000件のようなシャッフルをのほほんと想像してしまいましたが、やってみると早速500上限に当たりました。案の定かと臍を噛んだものの、管理者としては上の方針であり、このコンテンツ自体サイトの主目的では絶対になく、「本当に必要か」といえば不要なことはあらためて言います。また、上限があることについてはWIKIWIKI運営の方の通りにすぐに腑に落ちました。
「500」という具体的な数については判断できないものの、判断できないものは運営の方針にお任せすればよく、制限があればその制限にしたがうべきとの考えに至り、その後は500以内でシャッフルの条件を適宜可変にする形に収めています。8000を空想し、実用的に要るのは300くらいでした。その際に意識に昇ったのは、情報の編集・編纂は常にその操作より、操作を行う意図が重要という基本です。扱う対象が多ければ何ブロックかに分けてそこそこの数ごとに仕分けるようにすれば、その仕分けの意図を考え直す機会にもなるかと思います。実際に馬鹿げた操作をしかけてから上限に気づくので、上限数についてはマニュアルに載せておいてください。
AVIF image format につきまして、検討いたします。
本来の目的がショート動画の埋め込みなら別の要望になると思います。
ページ内の全ての開閉記録を保持してページ遷移後、記録をページに反映させる機能でよろしいでしょうか？
以下の項目を踏まえて引き続き議論いただけたら幸いです。
例えば一括開閉ボタンを作るとか
動的に動かす機能はコストがかかります。
WIKIの機能として本当に必要なのかも踏まえて、引き続き議論をお願いします。
同様のトピックが作成されましたので、
こちらで議論をお願いします。
https://zawazawa.jp/wikiwiki-request/topic/188
同様のトピックがありましたのでまとめます。
プラグインの引数にプラグインを指定することは非推奨です。
本来のやりたいことを別のトピックで要望として、議論していただけたら幸いです。
はい、極端な例ですとそうなります。
実際は妥当な画像サイズに最適化されます。
はい、ブラウザのキャッシュがあればそちらから読み込みます。
画像の最適については、以下のトピックもご確認ください。
表示画像の最適化について
https://zawazawa.jp/wikiwiki-request/topic/184
どのような場面で表組の枠線を消したいのでしょうか？
レイアウトでの使用なら、別の要望になると思います。
例えば1500x1500でアップロードした画像もサイズを100x100に指定したら100x100の画像になって転送量を削減できるということですか？
また、一度読み込んだ画像はキャッシュに保存されブラウザ更新してもキャッシュから読み込まれますか？
「最近更新されたWiki」は必要ないからやめてくれということなのか、「一日単位での追記件数」ランキングを作ってくれというのか
結局、何を要望しているのか分かりにくいです。
以下は昔のWIKIWIKIのよくある質問を抜粋したものです。
これを見て「最近更新されたWIKI」って検索サイトのクローラーに見つけてもらうためにあるんじゃないかと勝手に思ってます。
更新しても数時間で埋もれてしまうのでタイミングが合わなければだめですけどね。
自分の作ったWikiも一切宣伝してませんが訪問者が来るようになりましたし。
関係ないですが、WIKIWIKIにはいくつのWikiがあるんでしょうね。どこかで公表してましたっけ？
話がそれましたが「ネットに存在するあらゆるWikiに関心を持ちながらその通知を見ている人」とはまさに「検索サイトのクローラー」なんじゃないでしょうか。(人じゃないけど)
ということで「最近更新されたWIKI」は必要だと思いますよ。
こちらの希望としてはrecent・zrecentと全く同じ表示ですので、>> 2はその場しのぎとしてはありかなぁ、という印象です。
類似の話題で言及されている通りlsxは重めのものですので、長年愛用して数万ページに達しているとまた話は別なのかなと。
zawazawaのより手軽な利用方法要望については別トピックで議論したほうがいいと思います。
Wiki編集ってボランティア活動の一種だと思いますが、その行為を評価するのって必要なんですか？というか確認できる仕組みを求めてることに強い疑問を感じます。
そちらが積極的に編集に参加していて、他の編集者のアクティビティを見たいという意見なら分からなくもないですが、編集に参加しない人側からの視点での意見ということであれば取り下げたほうがいいです。
調べたらでてくるボランティアの4原則などを一度見てみてください。
ご対応ありがとうござます。Headerが意図したとおり表示されることを確認しました。
この不具合の対応で上記の現象が発生しました。🙇♂️
大変遅くなり申し訳ございません。
:Header でも flexbox が動作するように対応いたしました。
実は :Header や MenuBar はスタイルに「特別ルール」が実装されています。
例えば、:Header は表組の枠線が表示されません。
昔からレイアウトを組む方法として表がよく使われてきました。
:Header では 表組にデータを入れる用途で使われないため、レイアウト専用として枠線を消していました。
このガラケー時代の名残が原因で flexbox が動作しておりませんでした。
今は flexbox があるので、不具合の原因になりやすい :Header の「特別ルール」を無くすことを検討しております。
もし、:Header で表組でレイアウトを組んでおられる方は flexbox でレイアウトを組むようにしてください。
対応いたしました。
大変ご迷惑をおかけいたしました。🙇♂️
時間を置いて元の内容を記述したところ、直りました。
一時的に発生した不具合の模様です。
ご不便をおかけして申し訳ございません。
対応しておりますので、今しばらくお待ちください。
ChromeとFirefoxで瞬時に表示されることを確認しました。
ご対応ありがとうございました。
申し訳ございません。
アイコンが常時表示される不具合が発生しておりました。
修正し、正常に動作するようにいたしました。
特定の文字列の「表記ゆれ文字の対応処理」でブラウザに負荷がかかっていたようです。
この機能を無効化して対処いたしました。
共有ありがとうございます。
結論から申し上げますと、負荷は問題ないと思われます。
外部画像も最適化を行っています。
実際にインラインで表示されている画像は最適化済みです。(413KB)
もとの画像サイズと比較して十分最適化されています。
相手側(cdn.discordap)へのアクセスはインライン表示では、ほぼゼロです。
クリック時に拡大表示させた時だけ相手側のCDNから直接読み込みます。(6.6MB)
ここだけ相手側とユーザー側に負荷(転送量含む)が発生します。
相手側の画像は、閉じられた空間でのアクセスを想定されていると思いますので、一度ご確認いただけたらと思います。
参考: 「外部サービスの画像コンテンツの貼り付けについて」
例えばこのページの上部に設置している画像になります。
現在は閲覧数は落ち着いてますが、6月～8月くらいになると閲覧数が爆上がりします。
https://wikiwiki.jp/eft/CUSTOMS
別の機能で提供できることもあるので、
その機能がどのような目的で必要なのかを教えていただければと思います。
上記の現象を確認しました。
調査いたしますので、今しばらくお待ちください。
ご不便をおかけして申し訳ございません。
具体的にどの画像でしょうか？
掲載しているページのURLと表示させている画像を教えてください。
同感です。
フラッシュ機能は、使い方によっては、かつてのポケモンショック同様、
閲覧者に対し光過敏性発作を引き起こしかねません。
チカチカ鬱陶しいだけですし、個人的にも要りません。
点滅文字は設定次第で目にダメージが入ります。
そもそもスクロール文字を実装しているのは昔からの名残であると認識しており、その観点からも新たな追加は不要であると思っています。
どうしてもというのであれば、フェードイン/フェードアウトかつ、フェードインからフェードアウトまで3秒以上など、目に優しい形で制限するならば構いません。
応答不能になる例のリンク先は、ほんらいハイライトされるべきURLの文字列がハイライトされませんね。
タスクマネージャを見ていると表示が完了するまでブラウザーのCPU使用率が高いままです。
HTML Convert timeは短いことから、クライアント側の処理が上手く行ってないように見えます。
ただ普通にブラウザー側の機能の文字列検索を使えば一瞬で対象がハイライトされます。wikiwikiがhtmlに仕込ませてるscript処理になにか問題があるのだと思います。