Vbulletin 対 discourse

Vbulletinを利用したことはありますか?DiscourseでVbulletinのどの機能が恋しかったですか?

「いいね!」 2

2001年から2020年までvBulletinを使用し、現在でも「読み取り専用」のリファレンスサイトとしてvB3.8.Xを運用しています。

正直なところ、vBulletinから欠落していると感じるものは何もありません。むしろvBulletinに移行した後に、Ruby on RailsのMVCモデルは、vBulletinが採用していたLAMPモデル(システム管理者およびウェブ開発者の観点から)よりもはるかに優れていると実感しました。

ユーザーエクスペリエンスの面では、私たちのユーザーのほとんどはDiscourseに非常に満足していますが、vBulletinフォーラムのレガシーかつヴィンテージな外観と操作性を愛していた、長年活躍してきた一部の専門家の方々は離れてしまいました。

2021年には、レガシーなvBリファレンスサイトをRailsへ移植する計画を立てていました。具体的には、既存のMySQLデータベースを基盤として、Rails、Redis、Sidekiq、MySQL、jQuery、Bootstrapを用いたリファレンスサイトを構築する(既存のMySQL DBの上にRailsアプリを構築する)つもりでした。しかし、2021年は楽しくて興味深い有料のRailsクライアントワークに忙殺されているため、今年のうちにレガシーサイトの再構築は実現しないでしょう。

Discourseを導入する前は、熱心なPHPプログラマーでしたが、Discourseへの移行とRubyおよびRailsとの関わりを通じて、PHPやLAMPによるウェブ開発の何一つ楽しむことができなくなりました。vBulletinからDiscourseへの移行(そして長年のPHPウェブ開発の後にRailsを学んだこと)のおかげで、私は大いにRailsのファンになりました。

繰り返しになりますが、私たちのvBサイトに関しては、vBulletinとそのLAMPアーキテクチャには「さようなら」であり、Railsの上にDiscourseを構築してくれたDiscourseには「ありがとう」です!

ご参考になれば幸いです、@MKDan

「いいね!」 13

2007年から2016年まで利用していましたが、移行は円滑で、Discourseについて不満を述べたメンバーはごく少数でした。しかし、Discourseとその機能の使い方に慣れると、誰もvBulletinに戻ることを望まなくなりました。

多くのメンバーが欠けていたと感じていたのは、vBulletinのホームページ(一覧表示されたフォーラムとサブフォーラム)やスレッド内のページです。時間の経過とともにその必要性は薄れ、現在では「クラシック」なフォーラムから来た新しいメンバーが当社のDiscourse搭載ボードに参加した際にのみ、その話題が持ち上がります。

その上で申し上げますと、Discourseに既に含まれていないvBulletinの機能で、私が欠けていると感じるものは思い当たりません。DiscourseからvBulletinに戻るのは、大きな後退になると考えています。

「いいね!」 11

長年 vBulletin のライセンスを持っており、Photopost(懐かしいです)も使っていました。

彼らがライセンスを変更した日に、不満をぶつけたところ、多くの他のユーザーと共にフォーラムからBANされました。
私が受けた唯一のBANです(誇りを持って受け止めています):shield:。

これがきっかけで、XenForoが独立することになりました。

それ以来、vBulletin は見ていません。

ギャラリーアドオンが恋しいです。

「いいね!」 5

Discourse は Vbulletin よりもはるかに見栄えがします。ただ一つだけ、Discourse は共有ホスティングにはインストールできないという点があります。

「いいね!」 3

2021 年に共有ホスティングを利用する理由とは?

Discourse はオープンソースであり、月額 5 ドル以下のクラウドサーバーにインストールできます。

特にスタッフや管理者にとって、見た目が優れており、機能面でも優れています。

「いいね!」 6

2008年から2018年までvBulletinを使用していました(それ以前はDisqusを、さらにその前は1996年から1999年まで記憶にない別のサービスを使用していました)。

vBulletinで利用していた機能の中で、Discourseには(正確には)存在しないものとして、ブログ、ギャラリー、グループ(vBulletinのグループはFacebookのグループに似ていました)がありました。Discourseへの移行当初、これら3つの機能の欠如が感じられましたが、それらのほとんどがコミュニティに不要な雑多さを加え、議論の焦点をずらしていたことがわかりました。

メンバーの創作活動にはブログを使っていましたが、代わりにフォーラムトピックを採用しました。

コミュニティの特定の側面に関心を持つチーム向けにグループを利用していました。しかし、これらは段階的に廃止し、議論をメインのフォーラムに移行させました。その結果、むしろ全トピックへの関与と認知度が向上しました。

ギャラリーについても同様でした。

つまり、結論はこうです:コミュニティに直接的な価値をもたらさず、むしろ議論の一体性を損なう場合さえある、過剰な雑多さだったのです。

いいえ、全く惜しみません!

「いいね!」 8

Discourse では、テーマコンポーネントを使用してブログとギャラリーの両方を利用できることを知っておくと、役立つ場合もあれば、そうでない場合もあります。

「いいね!」 2

vBulletin との違いは、ブログとギャラリーの両方がユーザースコープだったという点です。つまり、それぞれユーザーのプロファイルに紐付いていました。

もちろん、本当に必要であれば、Discourse でもそれを達成できます。いくつかの高度なカテゴリ設定を使うか、必要であればプラグインを使って実現することも可能です。

「いいね!」 5

これは、10 年以上にわたり vBulletin フォーラムを利用してきた私の経験とも一致します。10 年経って気づいたのは、vBulletin のページでクリック可能な可能性のある「数百」もの項目のうち、画面中に散りばめられたすべてのリンクのうち、実際に私がクリックしたのはせいぜい十数個に過ぎなかったということです。10 年間の利用期間を通じて、本当にたったそれだけでした!

これは完全に狂気の沙汰ですね :zany_face::jeans:

「いいね!」 8

Discourse の利用を検討しているなら、迷わず使ってください!Discourse は現在最も優れたフォーラムプラットフォームであり、今後もそうであり続けるでしょう。ここでは開発のスピードに度々驚かされますし、チームには信じられないほど才能ある人々が揃っています(例えば Sam Saffron は、私が知る限り最も経験豊富な Ruby 開発者の一人です)。

vBulletin に何が欠けているかという点については、両者は異なるプラットフォームなので、その視点で考えるのは適切ではないかもしれません。ただし、あなたのサイトが主にフォーラムである場合、ユーザーは Discourse の方がずっと満足すると確信しています。

vBulletin から「フォーラム」的な機能として唯一見当たらないのは、トピック作成者と管理者/モデレーターチームのみがスレッドを閲覧できるセクションを作成できることです。私たちはこれらのセクションを「フォーラムへのフィードバック」や「スタッフへの連絡」などに利用しており、これらは PM(プライベートメッセージ)よりもそのような用途に適しています(PM は一度読まれると忘れられやすく、後から分類したり確認したりするのが難しいためです)。

Discourse には他にも多くの機能を追加して欲しいと考えています。その一つは、ブログ、記事、ニュースなど、他のセクションを Discourse で動かせるようにすることです。Discourse のコメント・議論システムは、おそらくその最大の強みの一つでしょう。Discourse のコメント機能を活用した WordPress 型のブログを想像してみてください。それがフォーラムのユーザープロフィールとシームレスに統合されているとすれば、Discourse は WordPress(や他の CMS)を置き換えることができるかもしれません。実際、vBulletin ではいくつかのセクションを Discourse で動かしており、必要なものは以下の 2 つだけでした:1) 各セクションの最新のアイテムを取得できるカスタムインデックスページ、2) 最初の投稿とそれ以降の投稿で異なるスタイルを設定できる機能(vBulletin では簡単な条件分岐で実現できました)。これにより、メイン記事とコメントを別々の見た目に表示できます。

また、適切なブロック機能の実装も望んでいます。これにより、モデレーターの業務が大幅に楽になるでしょう。

これら 2 つの機能については以前もフォーラムで議論されましたが、追加される可能性は低いようです(個人的には非常に残念に思っており、チームがいつかこの件を見直してくれることを願っています)。

「いいね!」 5

現在、ユーザー単位で「ミュート」と「無視」の両方が用意されていることはご存知ですね?

「いいね!」 2

これも、いずれ実装されればいいなと思っています。さらに、トピック作成者にそのトピック内で限定的なモデレーション権限を付与できるカテゴリも欲しいですね(少なくとも、他の投稿の削除、自分の投稿の即時削除、自分の投稿の編集時間制限なし)。

これはおそらく、vB の複雑極まりない権限設定ダイアログのどこかに実装可能な機能として埋もれているはずです。

「いいね!」 1

とはいえ、それでは他のユーザーが特定の人の投稿に返信したり応答したりすることを防げるわけではありませんよね?

以前もこの件について議論しましたが、その時はご関心が薄かったと記憶しています。この点についてご再考いただければ幸いです。

https://meta.discourse.org/t/ability-to-ignore-a-user/110254/75?u=astonj

それにはかなり説得が必要です。この奇妙な権限の慣習は、vBulletin が誤って世界に押し付けたものであり、その結果として私たちが苦しんでいると感じています。基本的には、「ほら、私たちのフォーラムをチケット対応ヘルプデスクソリューションに見せかけるための『ある奇抜な裏技』があるぞ!営業チームにそう売れるように言え!」といった感じでした。

(もしチケット対応ヘルプデスクシステムが必要なら、専用のものを使ってください!さらに「権限をトピックごとに変更できるようにしたらどう?」という提案もありますが、それは…極めて大規模で不要な作業です)

すでにこの手の基本的な形は存在します。例えば、トピックの作成者は自分のトピックに対して無制限に返信できます。

「いいね!」 2

現在のソフトウェアでもこの機能をかなり幅広く利用しており、私はあなたの方向に傾いています。ユーザーが「サポート」のために作成するスレッドの多くは、投稿が削除されたことなどに対してスタッフに文句を言うための手段に過ぎません。ただし、他のユーザーによるハラスメントの歴史を報告したり、実際の議論が必要な他のトピックなど、正当な利用例もいくつかあります。

繊細なやり取りが必要な場合もありますが、チケットシステムを無理やり付け加えるのは過剰です。Discourse へ移行する際には、このような対応はプライベートメッセージに移行する必要があると思いますが、すべてのスタッフが同じページに合わせるために全スタッフをトピックに追加する必要があるため、それが煩わしくなるでしょう。

「いいね!」 3

これはそのようなシステムにとって非常に優れたユースケースです。そうでなければ、人々はより公開性の高い「フォーラムフィードバック」セクションを利用し、往々にして単に混乱を招くために使います。「スタッフに連絡する」セクションに移行したことで、そのような無駄なやり取りは約90%減少しました。

「いいね!」 1

グループページにはメッセージボタンがあり、ユーザーは個別の受信トレイでやり取りを追跡できることに気づきました。これは「自分のスレッドのみ表示」権限と比較してどう感じるか確信が持てませんが、この仕組みが機能するかもしれません。

また、スタッフ連絡用とは別に、この種の設定を「プライベートワークショップ」のような用途でも活用しています。ユーザーはここで投稿し、フォーマットのテストを行ったり、徐々に構築・編集して後で公開する予定のコンテンツを保存したりできます。

「いいね!」 1

はい、議論を非公開にする必要がある場合は、@moderators のグループ受信トレイをご利用ください。

「いいね!」 2

https://trends.builtwith.com/cms/Discourse/Market-Share

「いいね!」 3