リクエスト広場

ご回答ありがとうございます。

そのため、「popular の通算リセット機能」を設けることは、実質的に 管理者が counter をリセットできる機能 と同等の意味合いを持ちます。

管理者が counter をリセットできる機能の実装を希望します。運営側はWiki発足当初からのカウントと利用者側が見れるカウントの2つを用意するなど、運営方針に影響でない形が望ましいです。機能追加していただけるならコントロールパネルにて単一ページを指定してカウントをリセットができたら助かります。システム負荷を考慮の上でテスト/*などのサブディレクトリ対応や複数ページ(hoge1/テスト、hoge2/testなどの指定)を同時にリセットできる機能があれば、さらに嬉しいです。システム的に実際の挙動はタスク同時ではなく、一つひとつ行って遅延処理するなどの対応イメージです。

Wiki利用者(Wiki管理者を含む)は現存しないページや通算カウントを一旦、リセットしたいページがあります。現状は除外しないと現存しないページも表示されて大変、不便です。

さらに、多数のフィルタをかけた場合は負荷が大きくなり、結果として「対象外とするページが多すぎると、文字数が増えてプラグインが『...loading』状態のまま機能しなくなる」ことがあります。

運営側も認識している通りで長く続けられているWikiほど、途中で削除されたページや不要のページも多くなるので当Wikiように除外ページの記述内容がどんどん増えていき、システム負荷も増えて使い勝手が悪くなっていきます。最終的にはカウント機能しなくなるほどに文字数も多くなります。実際に当Wikiは何度も限界に達して、その度に記述内容を見直しています。(①hoge/1、hoge/2などのページ→hoge/.*②二度目の限界後にhoge、hoge/*→hoge(/.*)?
)しかし、https://wikiwiki.jp/WIKIWIKI ID/のようなWIKIWIKI ID直下のページはそれぞれ、指定する必要があるのでこれ以上に増えた場合は現状、回避手段はなく見直しすることはできません。

ご検討のほど、よろしくお願いいたします。

私やはやしさんのように他社サービスであるGoogleアナリティクスを扱い、全員が使いこなせるのであれば必要ないと思います。

プラグインは誰でも気軽にその場で即座に使えます。そのようなWiki内サービスは管理者の手助けツールとして役立ちます。今回、私自身が困ったときに他者が管理するWikiでも使えそうと判断して要望を出しています。

今回の件で言えば、①Googleアナリティクスの利用が何らかの事情で使えていない人でも困らないような調整をしてほしい。②管理者でなくても統計を確認できるプラグインは重宝する。例え、管理者が不在となったWikiでも後継者にとって、このプラグインはページ作りに役立つと考えられます。

また、本件の要望よりも別のことを優先してほしいという意見ですが、それは要望トピックを出された方や賛同意見を出した方は皆、そう思われているのではないでしょうか。どんなに便利で使い勝手の良さそうな要望で多くの意見が飛び交っても、採用を見送りされたりしています。開発の進捗フェーズの状況で運営さんにメンションされていても都合上、未回答のままであるトピックもあります。運営側は実装後のコストの見積りや他サービス・プラグインへの影響の有無、セキュリティ面などを全てクリアできると判断してから要望を一つひとつ叶えてくれていると思います。

話の流れで本件よりも他の要望に目を向けてほしいと暗に示していますが、私は気落ちしました。私だけでなく、>> 1さんや同じく必要とする利用者には感じ悪く思います。

popularは統計としてどの様に役立つのでしょうか。
ページ構成や閲覧者次第でページ閲覧者ののべ人数など如何様にもなりませんか。

ご指摘のように、ページ閲覧者ののべ人数（PV数）はページ構成や閲覧者の行動に依存しますが、これはpopularプラグインの統計的価値を否定しないと思います。

訪問者数を簡単に可視化できるという簡易性、即時性、これまでに利用してきた利用者の関心について、どのコンテンツが注目されているかを「統計」を通じて即座にユーザーのサイト探索を促進することができます。これは、Googleアナリティクスのようなバックエンドツールだと利用者に分かりやすい形にして案内するには相当の時間や手間が掛かります。


ページを編集する立場として考えた場合でもcounterの値のみが役立つケースはごく稀であり、その様なページ作りをしたければGoogleアナリティクス等のツールを使わない理由は考えられません。
仮に使えない理由が存在したとしてBAN等の限定的な話ではありませんか。

編集の優先順位を決める手がかりになります。編集者はそのページの品質向上に注力できます。ボランティアベースの編集に頼っている大半のWikiは重要な動機付けとなります。閲覧者にとって、PV数が多いページは信頼性や関心度が高いと映る場合があり、さらなるサイトの探索や利用者のエンゲージメント(愛着や深い繋がり)を促進します。

すべてのWiki管理者が高度な分析ツールを導入するための技術的知識を新たに吸収して実践できるとは私自身は到底、思えません。popularプラグインは簡易な指標として価値があります。設定やアクセス解析ツールであるGoogleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり、すべてのWiki管理者が利用できる環境を整えたり、普及活動のために技術的知識を手に入れたいとは限りません。私自身も含みますが、PCを持たずしてモバイル端末だけで管理する者もいます。

2005年から運営が始まった現在の独自のwikiwikiになる前の基盤であるPukiwiki1.4(2003年リリース)で標準搭載され、利用者のアクセス傾向を簡単に知ることができます。todayとtotalは共に長年、どのWikiでも作成当初からMenuBar最下部にリンク表示されて使われてきたプラグインですので有用性は十分に裏付けされているでしょう。

削除されたページにおいてcounterの数は原則増えない事を前提とすれば長期的に運営していくにつれ削除されたページはpopularから消えてゆく事でしょう。
短期的であればtodayオプションが存在しますから必要性に疑問が残ります。

トピックに記載しているとおりでpopularプラグインを統計表示するときの話になります。

当Wikiは2009年にatwikiに発足、2016年にwikiwikiへ移行してから10年経過しようとしています。海外利用者も多くなり、国際基準に照らし合わせて日本語URLから英語URLへ統一、変更しています。そのため、現存しない日本語URLは勘違いさせて利便性を損ない、管理がなっていないと利用者からWiki管理者へのクレームにもなり得ます。(すでに過去にpopularプラグインの統計で表示された日本語URLのリンクが存在しないページであることを理由にクレームを頂いて対処)大半の日本語URLが表示されなくなるまで当Wikiの場合は統計10件に表示制限したとしても、現状のアクセス推移では入れ替わるまでに約10〜20年ほどの歳月がかかることを見込んでいます。TOP10の内訳はFrontPageと日本語URLが独占して、現存するページは一つも含まれません。

当Wikiに限ると扱っている作品数83本と多くあり、どれも似たり寄ったりと評されることがよくあります。さらにコンスタントに毎年、3〜5本の新作が発売されます。そこでGoogleアナリティクスだけでなく、popularプラグインも使って利用者の行動心理に影響を与える要素を増やして、さらなるエンゲージメントを促進しています。

当Wikiの例

• 統計300件(フィルタなし版)
  記述内容: #popular(300)
• 統計300件(フィルタあり版)
  記述内容:
  解決した後の記述内容

  #popular(300,RecentChanges|FrontPage|MenuBar|SandBox(/.*)?|others(/.*)?|ゲーム発展国\+\+(/.*)?|箱庭タウンズ(/.*)?|冒険キングダム島(/.*)?|大海賊クエスト島(/.*)?|こだわりラーメン館 全国編(/.*)?|創作パティシエ部(/.*)?|お住まい夢物語(/.*)?|冒険ダンジョン村2(/.*)?|まんが一本道〆(/.*)?|創作♪パティシエ部(/.*)?|お住まい夢物語(/.*)?|喫茶ブレンド物語(/.*)?|海鮮!!すし街道(/.*)?|ジャンボ空港物語(/.*)?|開拓サバイバル島(/.*)?|ソーシャル夢物語(/.*)?|フレンド募集(/.*)?|名門ポケット学院3(/.*)?|大盛グルメ食堂(/.*)?|ゆけむり温泉郷2(/.*)?|その他(/.*)?|開店コンビニ日記(/.*)?|名門ポケット学院3(/.*)?|名門ポケット学院2(/.*)?|財閥タウンズV(/.*)?|その他(/.*)?|ゆけむり温泉郷2(/.*)?|こだわりラーメン館(/.*)?|サッカークラブ物語2(/.*)?|G1牧場ステークス(/.*)?|あおぞら飛行隊(/.*)?|創造タウンズ島(/.*)?|合戦!!にんじゃ村(/.*)?|創作ハンバーガー堂(/.*)?|野球部ものがたり(/.*)?|ミリオン行進曲♪(/.*)?|ゆけむり温泉郷(/.*)?|名門ポケット学院1(/.*)?|バスケクラブ物語(/.*)?|大江戸タウンズ(/.*)?|TVスタジオ物語(/.*)?|南国バカンス島(/.*)?|常夏プールパレス(/.*)?|探検わんぱく動物園(/.*)?|ゆうえんち夢物語(/.*)?|風雲☆ボクシング物語(/.*)?|コメント(/.*)?|アニメスタジオ物語(/.*)?|きらめきスキー白書(/.*)?|開店デパート日記2(/.*)?|冒険ダンジョン村(/.*)?|開幕!!パドックGP2(/.*)?|開幕!!パドックGP(/.*)?|箱庭シティ鉄道(/.*)?|夢おこし商店街(/.*)?|森林キャンプが丘(/.*)?|洞窟ぼうけん団(/.*)?|質問コーナー(/.*)?|大盛りグルメ食堂(/.*)?|クルーズ大紀行(/.*)?|大空ヘクタール農園(/.*)?|映画スタジオ物語(/.*)?|開園ピクセル牧場(/.*)?|開店デパート日記(/.*)?|大魔法クエスト(/.*)?|名門ポケット学院(/.*)?|テニスクラブ物語(/.*)?|発見どうぶつ公園(/.*)?|アパレル洋品店(/.*)?|わいわいクエスト物語(/.*)?|ゲームセンター倶楽部(/.*)?|つくろう！ゴルフの森(/.*)?|発進!!ヒーロー基地(/.*)?|星になったカイロくん(/.*)?|サッカークラブ物語(/.*)?|ふれあい出版局(/.*)?|発掘☆ピラミッド王国(/.*)?|アストロ探検隊(/.*)?|放課後ファイタークラブ(/.*)?|冒険キングダム島(ペット)|雑談|キャラクター紹介|ゲームタイトル人気投票)

直前の投稿内容を鑑みてもpopularにおいてweeklyやmonthlyの表示を行えれば十分ではありませんか。

時間枠の柔軟性は追加されたら便利ですが、今回の要望とは別軸にそれた話です。本件はpopularプラグインの統計(通算)に対するトピックを立てています。また、現存しないオプション機能を新たに追加することで問題の根幹が解決するわけではないことをご理解いただきたいです。

popularは有用です。
私の例で言えば、popularやcounterのアクセス数からメニューの掲載基準や位置の決定に活用しました。
当時メニューが無法地帯だったので私はそれを整理しようとしました。
そのとき私は管理者ではなく来たばかりの新人でしたが、提案を数値に基づいて示したので話がスムーズだったと思います。

counterの仕様はそのようになっているんですね、勉強になります。
(アクアちゃんとは？と思いましたが...)

その上で、counterファイルを手動で弄れるようにする(管理者によるカウンターのリセットや編集を許可する)というのは反対です。
>> 14さんが仰っている通り管理者の無用な手間を増やすことになるうえ、結局の所管理者が荒らしてしまえば元も子もなく、任意リセットはcounterの価値を無くすものと思います。
そうした点では、ページ削除の操作によってcounterファイルに任意の識別子を付与し、popular側ではその識別子を元にフィルターすることを提案します。
リネームに関してはどのような手法を取っても復元不可能となるリスクがありますが、「ページ名の変更」操作を行った場合のみ自動でcounterを書き換えるような処理を追加すればよいのではないでしょうか。

今のお話の中にあったリンク の先のページの一番下に、重要な情報が見られます。

負荷の高いカウンター関連プラグインの非同期処理を行いました。カウンター向けの専用サーバーに集約しております。
WIKIとカウンターを切り離して動いておりますので、削除されたページのカウントも人気のページ表示されます。
また、renameプラグインでページ名を変更してもカウンターは引き継がれません。

どうしても修正したい方
数ページ程度であれば手動で反映いたしますのでお問い合わせください。

つまり、今の動作（削除済みのページも表示される、名前変更後に値が継承されない）は不具合でも想定外でもなく、すべて承知の上での仕様だということです。
また、「数ページ程度であれば手動で反映いたします」ともあります。推測になりますが、利用されることがほとんどないと見込まれるので、削除機能を提供するよりも手動で応じたほうが楽、という判断である可能性があります。

不具合でも想定外でもない意図どおりの仕様に変更を迫ることは、もちろん容易ではありません。周到な準備が必要です。
注目すべきは、運営さんからの返信にある「これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わる」という部分です。
これらをクリアした上での提案でないと、変更には応じてもらえないわけです。ひとつひとつ、考えてみましょう。

利用者全体の公平性

話題の対象が利用者全体なので、「私が必要としている理由はこれです」のような話をしても意味がない、ということです。（逆に「私には全然必要ありません」も無意味です）
新しい機能が自分にとって無縁の機能であっても、他人にとって利用価値がある機能なら、使わない人にとっても納得できます。
逆に、ごく一部の人しか喜ばない機能を作るようでは、不公平感が高まります。
つまり、使う人が多いということを示す必要があります。

これは容易ではありません。簡単に思いつく手段はアンケートですが、統計的に意味のある量のデータを集めることはほとんど不可能に思えます。
となれば、「ほとんど誰も使わないのでは？」という懸念となるような事案をひとつひとつ丁寧に、単なる決めつけではなく確かな理論的背景をもつ説明をしていくしかないように思います。
ここまでの話の中で上がっている懸念を簡単にまとめると、以下のとおりです。

• popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは
• Googleアナリティクスを使えばよいのでは

システム負荷

負荷の量やメカニズムについては、私などより01vさんのほうがよほど詳しいようです。
すこし目線を変えると、「負荷をどう減らすか」も重要ですが別のアプローチとして「要望する機能の価値を明らかにする」という手段も視野に入ります。
負荷が同じでも価値が高いなら、「しない」から「する」に傾かせることができます。
やみくもに「使う・要る・欲しい」と言うのではなく、具体的にどう役立つかを示せれば、提案に有利に働くでしょう。

運営方針

これはちょっと、私には意味がよく分かりません。
ただ、今回の要望が運営方針に対する悪影響の懸念がある、というのは確かに思えます。
この辺を明らかにし、その対策を含んだ提案をする必要があります。

各ページにcounterファイルの編集リンクを設置する(管理者用)

これは&counter_editみたいなプラグインを作って、必要に応じ各ページやメニューに仕込めばよいと考えました。現在の標準レイアウトに手を入れずに、必要な時だけ表に出し、不要になったら外せばいいです。

よくまとまっていると思いますが、補強する余地がいくつかあるようなので、お話させてください。

したがって、総数と直近では差別化がなされています。

はい、総数と直近は中身が違います。これは間違いなく正しいことです。
しかし中身が違うということから、有益であると主張するのは理論の飛躍があります。なぜなら「唯一無二であるが無用なもの」であることを否定できていないからです。
「直近と違うから総数は有用だ」よりも「総数を見ることでしか得られない、こういうメリットがあるので有用だ」という説明のほうが、説得力があるはずです。

今日100と人気100はあらかじめ用意されており

たしかに、そのはずです。
しかし長く運用されてきたシステムは往々にして、「あまり要らないけど外すのも手間だし、何か起こったら嫌だから触らずにそのままにしておく」機能も多いのです。
「昔からあって今もある」ということは必ずしも、積極的に提供する意思があることや有益であることを証明しません。
論拠の一部として添えることは無駄ではありませんが、弱みがある論拠なので尊重されないかもしれません。

Googleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり

Googleアナリティクスに関する「専門知識」とは、いったい何のことでしょうか。
私が使い始めたときの話をすると、事前の学習や訓練に費やした時間はゼロです。
サーバOSの知識やネットワークプロトコルなどの知識は、要求されません。
もっと具体的にハードルの高さを示さないと、いわゆる「食わず嫌い」と見なされて説得力がないように思われます。