共有編集の改善

UX
1

We did some further testings on odd behaviours of the - otherwise great - shared edit mode. Here are some findings:

image

Note that the plugin does not enable edit access per se. This means that if you want non-moderators to be able to collaboratively edit the post you must also make the post a Wiki (green, optional):

If I enabled Shared Edits, I have the option to make it a wiki, too. But if I do so via the Make Wiki option, it still reads “Make Wiki”. It will enter Wiki mode, though. But there is no way to revoke the Wiki.

Moderators can toggle shared edits on a topic (red) via the gear icon on the composer bar

I would like to see an option, where the right to start/stop shared edits is linked to the right to start/end a wiki. The functionality is quite similar, why choosing different rights (mods only)?

Now this is a critical one:

  1. I set a posting into wiki and shared edit mode
  2. Some people start editing away in the shared edit composer
  3. Some other people use the “classic” wiki editor - via the revisions link on the same posting at the same time:

image
image849×235 24 KB

and then at the bottom Edit Post

image
image1163×141 8.16 KB

Now things get ugly real quick. Like - reeeealy ugly. Lots of overwritten stuff, changes not saved, revision conflicts. My understanding is, that shared edits is not designed to work at the same time as classic wiki editing (completely understandable from a technical view).

I figure the best way to solve this would be to redirect the Edit Post button to the new shared edits composer?

Hence the shared edits composer doesn’t offer the option to edit the metadata of the posting (titel, tags etc.), there has to be a solution for that, too.

One could argue “just tell your people to stay away from the revisions-pencil”, but this is not how it works - a lot of our users like this way instead of scrolling down to the end of a long WikiPad posting.

I see this might not an easy one to be fixed, but right now the shared edits feature is quite broken. We’ve tried it on several postings with different people, and always conflicts arose.

「いいね！」 9
2

これに関するニュースはありますか？CSSに以下を追加することで「修正」しましたが、明らかにこれは修正であって解決策ではありません…

div#revision-footer-buttons button:nth-of-type(1) {
    display: none !important;
}
「いいね！」 3
3

ウィキ機能と共有編集がどのように連携するかを非常に明確に説明していただき、それがよろしくないことがわかりました。回避策/修正ありがとうございます!!

ウィキ機能のささやかな強化として、私のささやかな Wikified Posts Component に組み込みました。

「いいね！」 1
5

Ah、コンポーネントのことは知りませんでした。非常に便利ですね（ウィキ投稿の色付けには古いものを使っていましたが、今後は切り替えます）。

「いいね！」 2
7

テーマの common > header タブ（またはリモートコンポーネントの /common/header.html）にこれを追加すると、現在のユーザーが編集できる共有編集投稿の場合に、共有編集投稿に shared-edits-post クラスが追加されます。

<script type="text/discourse-plugin" version="0.8">
  api.addPostClassesCallback((attrs) => {
    if (attrs.shared_edits_enabled && attrs.canEdit) return ["shared-edits-post"];
  });
</script>

次に CSS で

.shared-edits-post {
  // do some work
}
「いいね！」 5
8

完了しました！すべてがWikified Posts Component にまとめられました。

ジョー、ありがとう - すべて可能になりました！
本当にターゲットにしたいのは、最初の revision-footer-button（「Edit Wiki」というテキスト付き）で、Shared Edits の投稿でのみ非表示にしたいです。リビジョンパネル/ダイアログもカバーするクラスを取得する方法はありますか？

「いいね！」 3
9

変更をいくつかプッシュしました。

これは修正されました。共有編集投稿のウィキのオン/オフを切り替えると、正しいラベルが表示されるようになりました。

これも修正されました。リビジョン履歴モーダルからボタンをクリックし、投稿が shared-edit に設定されている場合、デフォルトのコンポーザーではなく共有編集コンポーザーが開きます。

プラグインにクラスを追加しました。そのため、追加したスニペットを削除できます。プラグインは、変更なしでそのクラスを追加するようになりました。

ボタンが以前はデフォルトのコンポーザーを開いていたため、それを必要としていたと推測します。これは現在修正されており、非表示にする必要はなくなりました。

「いいね！」 6
10

これは私たちにとって依然として決定的な問題です。プライバシー上の理由から、できるだけ少ないモデレーターで済ませたいと考えています。そのため、ウィキを開始できる人は誰でも共有編集を開始できるようにするオプションを強く希望します。基本的に同じことです。ちなみに、このモードを「WikiPad」と名付けました。共有編集よりも印象的です。

「いいね！」 4
11

「共有編集を開始できるグループ」の設定を追加することに完全にオープンです。デフォルトは「スタッフ」ですが、好きなものに変更できます。

「いいね！」 8
13

この件が実現する可能性はどのくらいですか？これは、私たちの日常業務において、まさにゲームチェンジャーとなるようなささやかな変更です。

「いいね！」 5
14

この素晴らしいプラグインは、Discourse を使用して共同でメモを取ったり、ブレインストーミングを行ったりするというユースケースに非常によく適合しています。プラグインを調べているうちに、時折グリッチが発生することがありましたが、残念ながら一貫して再現するのが難しいものでした。

ユーザー A が行った変更が、ユーザー B がドキュメントを更新したときに元に戻されてしまうという現象が発生しました。どちらの変更も Save ボタンで明示的に保存されていました。ネットワーク接続が原因である可能性があり、以下の手順でその動作を再現することに成功しました。

  • 両方のブラウザは、ドキュメントの共有状態から開始します。
    image
    image726×578 29.1 KB
  • ブラウザ 2 が接続を失います（ただし、ユーザーはそれに気づきません）。
    image
    image1911×865 178 KB
  • ブラウザ 1 が変更を保存します。
    image
    image789×577 164 KB
  • ブラウザ 2 がオフラインのまま変更を加えます。
    image
    image1102×594 80.7 KB
  • ブラウザ 2 がオンラインに戻り、変更を保存します。
    image
    image1918×866 173 KB
  • ブラウザ 2 で行われた変更が保存され、ブラウザ 1 で行われた以前の変更が元に戻されます。
    image
    image852×753 290 KB

これはかなり人工的な状況ですが、時折発生する動作を再現できた唯一の方法です。他にこの問題に遭遇した人はいますか？修正方法はありますか？

「いいね！」 5
15

はい、悪いインターネット接続で同様の問題に遭遇しました。時にはかなりの量の編集を失うこともあります。これは非常にイライラします。おそらく、切断検出が機能し、localStorageバッファなどに切り替えることができるでしょう。おそらく、localStorageを最初に使い、後で同期する…技術的にどのように実装されているかはわかりませんが、同期が数ミリ秒遅延しても、テキストを失うよりも良い場合があります。

「いいね！」 3
16

これは私たちのサイトで依然として大きな問題です。この情報がお役に立つかもしれません。履歴のこの編集をご覧ください。

image
image1177×229 14.6 KB

「system」はシステムルートアカウントです。ユーザーアカウントが表示されないのはなぜですか？別のバリエーションは次のとおりです。

image
image1187×188 14.8 KB

これはまだシステムに割り当てられていますが、「xyによって編集済み」という追加情報が付いています。奇妙です。

「いいね！」 1
17

こんにちは @Ralf_Stockmann さん :slight_smile:

トピックのタイムアウトで失われないように、投稿を新しい UX トピックに分割しました。いくつか別々に追跡する価値のある問題があるように思われます（@Johani さんの修正でいくつか対処されたと思いますか？）。もしそうなら、お知らせください。新しいトピックを作成できます。 :+1:

「いいね！」 3
18

ありがとうございます。しかし、このトピックに関する同僚の @literarymachine による投稿が現在見当たりません。彼はこのプラグインのネットワーク関連の競合状態について指摘していましたが、a) それらはまだ修正されておらず、b) このそうでなければ素晴らしいプラグインを真剣な作業にはほとんど役に立たないものにしています。

「いいね！」 3
19

これで全部だと思います。:crossed_fingers:

「いいね！」 3
20

これは私たちにとっても課題となっており、非常に役立つでしょう。

PR（プルリクエスト）は役に立ちますか？公式プラグインのPRは、私のようなハッカーにとっては非常に困難です。なぜなら、私がすぐに利用できる以上のセットアップと専門知識が必要だからです！

21

Tl4は共有編集の切り替えが可能になり、より柔軟性が向上しました。

PRはサイト設定をグループベースに変更できます。

「いいね！」 2
22

モデレーターはどうですか？それともTL4に昇格する必要がありますか？

彼らはすでにTL4に自分で昇格できるため、共有編集を有効にするすべての権限を付与するのが理にかなっています。

「いいね！」 1