공유 편집 개선 사항

기여 UX
1

그 외에는 훌륭한 공유 편집 모드의 이상한 동작에 대해 몇 가지 추가 테스트를 수행했습니다. 다음은 몇 가지 발견 사항입니다:

image
image423×303 12 KB

참고: 이 플러그인은 편집 접근 권한 자체를 활성화하지 않습니다. 즉, 비モデ레이터가 게시물을 협업 방식으로 편집할 수 있도록 하려면 해당 게시물을 위키로 설정해야 합니다(초록색, 선택 사항):

공유 편집을 활성화하면 위키로 설정할 수도 있는 옵션이 있습니다. 하지만 Make Wiki(위키로 만들기) 옵션을 통해 그렇게 하면 여전히 "Make Wiki"라고 표시됩니다. 위키 모드는 진입하지만, 위키 설정을 해제하는 방법은 없습니다.

モデ레이터는 작성자 바의 기어 아이콘을 통해 주제별로 공유 편집을 켜고 끌 수 있습니다(빨간색)

공유 편집을 시작/중단할 수 있는 권한을 위키를 시작/종료할 수 있는 권한과 연결하는 옵션을 보고 싶습니다. 기능이 꽤 유사한데, 왜 권한 설정(モデ레이터만 가능)이 다른가요?

이제 중요한 문제가 하나 있습니다:

  1. 게시물을 위키 그리고 공유 편집 모드로 설정했습니다.
  2. 일부 사용자는 공유 편집 작성기에서 편집을 시작합니다.
  3. 일부 다른 사용자는 동시에 같은 게시물의 수정 이력 링크를 통해 ‘클래식’ 위키 편집기를 사용합니다:

image
image849×235 24 KB

그리고 하단에는 Edit Post(게시물 편집)

image
image1163×141 8.16 KB

이제 상황이 매우 나빠집니다. 정말로 엉망이 됩니다. 덮어쓰기된 내용, 저장되지 않은 변경 사항, 수정 이력 충돌 등이 발생합니다. 제 이해로는, 공유 편집은 기술적인 관점에서 완전히 이해할 수 있듯이, 클래식 위키 편집과 동시에 작동하도록 설계되지 않았습니다.

이 문제를 해결하는 가장 좋은 방법은 Edit Post 버튼을 새로운 공유 편집 작성기로 리디렉션하는 것이라고 생각합니다.

따라서 공유 편집 작성기가 게시물의 메타데이터(제목, 태그 등)를 편집할 수 있는 옵션을 제공하지 않으므로, 그 부분도 해결책이 필요합니다.

"사람들에게 수정 이력 연필 아이콘을 사용하지 말라고 하세요"라고 주장할 수 있지만, 현실은 그렇지 않습니다. 우리 사용자 중 많은 분들이 긴 WikiPad 게시물의 끝까지 스크롤하는 대신 이 방식을 선호합니다.

이것이 쉽게 수정될 수 있는 문제는 아닐 수 있지만, 현재 공유 편집 기능은 상당히 깨져 있습니다. 여러 게시물에서 다른 사람들과 함께 테스트해 보았지만, 항상 충돌이 발생했습니다.

9개의 좋아요
2

이 문제에 대한 최신 소식은 없나요? 우리는 다음 코드를 CSS에 추가하여 "수정"했습니다.

div#revision-footer-buttons button:nth-of-type(1) {
    display: none !important;
}

하지만 분명히 이것은 해결책이 아니라 임시 수정일 뿐입니다…

3개의 좋아요
3

위키 기능과 공유된 편집이 어떻게 상호작용하는지 정말 명확하게 설명해 주셨습니다. 그리고 그 모습이 그리 아름답지는 않네요. 우회책/수정 방법을 알려주셔서 감사합니다!!

이것은 위키 기능의 좋은 작은 개선 사항이므로, 제 작은 Wikified Posts Component 에 포함시켰습니다.

1개의 좋아요
5

아 - 우리 컴포넌트에 대해 몰랐네요. 정말 유용하네요. (지금까지는 위키 포스트에 색을 입히기 위해 오래된 것을 사용했는데, 이제 바꾸겠습니다.)

2개의 좋아요
7

테마의 common > header 탭(또는 원격 컴포넌트의 /common/header.html)에 아래 내용을 추가하면, 현재 사용자가 해당 포스트를 수정할 수 있는 경우 shared-edit 포스트에 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

몇 가지 변경 사항을 push했습니다.

이 문제는 수정되었습니다. 공유 편집 게시글에서 위키를 켜고 끄면 이제 올바른 라벨이 표시됩니다.

이 문제도 수정되었습니다. 수정 이력 모달에서 버튼을 클릭하고 해당 게시글이 shared-edit으로 설정되어 있으면 기본 작성기가 아닌 공유 편집 작성기가 열립니다.

플러그인에 해당 클래스를 추가했습니다. 따라서 추가한 스니펫을 제거할 수 있습니다. 이제 수정 없이 플러그인이 자동으로 해당 클래스를 추가합니다.

그 버튼이 기본 작성기를 열기 때문에 숨기려고 했던 것 같습니다. 이제 그 문제가 수정되었으므로 더 이상 숨길 필요가 없습니다.

6개의 좋아요
Wikified Posts Component
10

이것은 여전히 우리에게 결정적인 장애물입니다: 사생활 보호를 위해 가능한 한 적은 수의 관리자를 두려고 노력하고 있습니다. 따라서 위키를 시작할 수 있는 모든 사람이 공유 편집도 시작할 수 있는 옵션을 정말로 원합니다 - 기본적으로 동일한 기능입니다. 참고로: 우리는 이 모드를 "WikiPad"라고 이름 붙였습니다. 공유 편집보다 더 인상적입니다.

4개의 좋아요
11

네, "공유 편집을 시작할 수 있는 그룹"에 대한 설정을 추가하는 것에 완전히 동의합니다. 기본값은 "스태프"로 설정하되, 원하는 값으로 변경할 수 있도록 하겠습니다.

8개의 좋아요
Discourse Shared Edits
13

이것이 실현될 가능성은 얼마나 될까요? 다시 한번 말씀드리지만, 이 작은 조정은 우리의 일상 업무에 게임체인저가 될 것입니다.

5개의 좋아요
14

이 훌륭한 플러그인에 감사합니다. Discourse를 사용하여 협업으로 노트를 작성하고, 브레인라이팅(자유로운 아이디어 기록) 등을 하는 우리의 사용 사례에 매우 잘 맞습니다. 다만 플러그인을 검토하는 동안 간헐적으로 버그가 발생했는데, 불행히도 일관되게 재현하기가 어렵습니다.

경험한 문제는 사용자 A가 수행한 변경 사항이 사용자 B가 문서를 업데이트할 때 되돌려지는 것입니다. 두 변경 사항 모두 저장 버튼을 사용하여 명시적으로 저장되었습니다. 이는 네트워크 연결 문제로 인해 발생할 수 있다고 추측하며, 다음과 같은 방식으로 해당 동작을 재현할 수 있었습니다:

  • 두 브라우저 모두 문서의 공유된 상태에서 시작합니다:
    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

여전히 system에 할당되어 있지만, "xy가 편집함"이라는 추가 정보가 있습니다. 이상하네요.

1개의 좋아요
17

안녕하세요 @Ralf_Stockmann :slight_smile:

포스트들이 토픽 타이머에 의해 삭제되지 않도록, 새 Contribute > UX 토픽으로 분리했습니다. 별도로 추적할 가치가 있는 몇 가지 문제가 포함되어 있을 수 있다고 생각합니다(@Johani의 수정으로 일부가 해결되었을 것 같기도 하고요). 만약 그렇다면 알려주시면 해당 문제를 위한 새 토픽을 만들 수 있습니다. :+1:

3개의 좋아요
18

감사합니다 - 하지만 이 토픽에서 @literarymachine(제 동료)의 게시물을 찾을 수가 없습니다. 그는 이 플러그인의 네트워크 관련 레이스 컨디션 문제를 지적했는데, a) 아직까지 수정되지 않았고 b) 이 덕분에 이 놀라운 플러그인이 진지한 작업에서는 사실상 쓸모없게 되었습니다…?

3개의 좋아요
Test our new composer!
19

그게 전부인 것 같아요. :crossed_fingers:

3개의 좋아요
20

우리에게도 이런 문제가 있었고, 정말 도움이 될 것 같습니다.

이 기능을 위해 PR을 제출하는 것이 유용할까요? 공식 플러그인 PR은 저 같은 해커에게는 꽤 도전적인데, 더 많은 설정과 제가 쉽게 활용할 수 있는 전문 지식이 필요하기 때문이죠!

21

Tl4 사용자는 이제 공유 편집을 켜고 끌 수 있으며, 이를 통해 훨씬 더 많은 유연성을 확보할 수 있습니다.

Pr은 이를 그룹 기반 사이트 설정으로 전환할 수 있습니다.

2개의 좋아요
22

그렇다면 중재자(Moderator)는 어떨까요? 아니면 TL4로 승급해야 하나요?

중재자는 본인이 TL4로 승급할 수 있으므로, 공유 편집 활성화 권한을 부여하는 것이 합리적일 것입니다.

1개의 좋아요