카테고리 이름이 너무 길면 태그 버튼이 잘립니다.
하나 이상의 태그가 추가된 경우, 아이콘 옆에 추가된 태그의 수를 숫자로 표시할 수 있을까요? 현재 태그 아이콘이 채워지는 방식(매우 미묘함)보다 훨씬 나을 것 같습니다.
Canapin이 이 문제를 제기한 것으로 기억합니다. 어떤 이유로인지 제목이 꽤 잘려 보이는 것 같습니다. 플로팅 버튼이 방해가 되고 있기 때문일 수도 있습니다.
카테고리 이름이 너무 길면 태그 버튼이 잘립니다.
하나 이상의 태그가 추가된 경우, 아이콘 옆에 추가된 태그의 수를 숫자로 표시할 수 있을까요? 현재 태그 아이콘이 채워지는 방식(매우 미묘함)보다 훨씬 나을 것 같습니다.
Canapin이 이 문제를 제기한 것으로 기억합니다. 어떤 이유로인지 제목이 꽤 잘려 보이는 것 같습니다. 플로팅 버튼이 방해가 되고 있기 때문일 수도 있습니다.
Composer Redesign을 활성화할 때, ‘직원’ 또는 '특정 그룹’을 선택해도 작동하지 않았습니다. '모두’를 선택해야만 작동했습니다.
에러는 보이지 않았지만 재테스트는 해볼 수 있어요. 처음에는 Staff, Guide라는 특정 그룹으로 설정해 보았어요.
컴포저를 테스트했을 때 변경 사항이 없었어요. 그래서 Staff만 선택하는 옵션도 시도해 봤는데 결과는 동일했어요. 모든 사람에게 활성화했을 때에만 모바일에서 재설계된 컴포저가 표시되었어요.
데스크톱에서는 테스트하지 않았어요. 추가 세부 정보를 추가하는 것을 잊어버려서 죄송해요.
모바일: Google Pixel 9 XL.
수정 방금 해당 설정들을 다시 시도해 봤어요. 이제 작동해요! 캐시된 포럼을 보고 있었던 걸까요? 새로고침도 해 봤는데 말이죠. 하지만 지금은 모든 게 정상이에요.
![]()
![]()
![]()
매우 사소한 디자인 누락입니다. 활성화된 상태에서 선택자의 배경에는 둥근 모서리가 적용되어 있지만, 기본 상태에서는 둥근 모서리가 보이지 않습니다:

![]()
이전에 언급된 내용이지만 모바일에서 미리보기 버튼이 다시 추가되기를 진심으로 바랍니다. 제가 사용하는 포럼 중 하나는 컴포넌트 우회 방법을 설치할 만큼의 커뮤니티 관심이 부족합니다.
약간 화려한 느낌인데, Chromium 특유의 파란색 하이라이트(?) 때문에 확장될 때 파란색으로 깜빡입니다.
그 외에도 키보드가 열렸을 때 최소화하려면 마이너스 버튼을 두 번 눌러야 합니다. (참고: 이전 디자인에서는 이 문제가 없었습니다) 이는 이 동영상 프레임에서 볼 수 있는 이 이상 현상(마이너스 버튼을 처음 눌렀을 때 발생) 때문일 수 있는데, 알 수 없는 이유로 URL 바가 마이너스 버튼 위치로 튀어 오릅니다:
Foundation에서는 잘 동작하는 것 같지만, Horizon에서는 몇 가지 문제가 있습니다: 미리보기 창에 강조 색상의 테두리가 표시됩니다.
Foundation에서 잘 작동해서 기쁩니다! Horizon의 경우, OP에서 말했듯이 알고 있습니다.
아직 작업 중입니다.
AI에게 물어보니, 해당 요소에 -webkit-tap-highlight-color: transparent를 추가하면 파란색 플래시를 수정할 수 있다고 합니다. 편집기 요소에 이 스타일을 적용하는 것을 권장합니다. 편집기가 확장되어 전체 화면을 차지할 때 화면 전체가 파란색으로 깜빡이는 현상이 발생하기 때문에, 시각적으로 좋지 않은 인상을 주기 때문입니다.
Stylus에서 * {-webkit-tap-highlight-color: transparent}를 적용했을 때의 모습입니다 (Android에서 Edge를 사용 중입니다)
경계선이 없는 디자인은 훨씬 직관적이지 않다고 생각합니다.
제목이 게시글 본문 편집기 일부처럼 보입니다. 좋습니다. 하지만 제목을 입력한 뒤 Enter 키를 누르면 커서가 다음 줄로 이동하지 않습니다. 다음 줄로 넘어갈 수 없는 상태에서 게시글의 첫 줄에 갇혀 있는 것처럼 느껴집니다. 사용자가 다음 줄을 클릭하거나 Tab 키를 눌러야 진행할 수 있다는 사실을 직관적으로 이해하지 못할 것 같습니다. 제목 입력을 게시글 본문 편집기의 일부로 만들려면, 편집기의 다른 줄과 똑같이 작동해야 합니다. 여전히 별도의 입력 필드로 취급할 것이라면, 사용자가 그 사실을 시각적으로 인지할 수 있도록 기존 디자인으로 돌아가야 합니다.
게시글 편집기와 미리보기 사이의 경계선이 없는 것(컴포저가 마크다운 편집기 모드일 때)은 너무 혼란스럽습니다. 이는 두 개의 독립된 패널입니다. 두 패널 사이에 경계선을 두어 사용자가 그 사실을 시각적으로 인지할 수 있도록 해야 합니다.
컴포저가 "마크다운 편집기 모드"일 때 표시되는 미리보기에 오른쪽 여백이 없습니다:
컴포저가 "리치 텍스트 편집기 모드"일 때와 마찬가지로, 컴포저 왼쪽에서 볼 수 있는 여백과 유사한 오른쪽 여백이 있기를 기대합니다:
@renato 이건 충분히 쉽게 구현할 수 있다고 생각하시나요?
그렇다면, 다른 방향으로도 적용되어야 할까요? 커서가 텍스트 영역의 시작 부분에 있으면, 뒤로 버튼을 누르면 제목 입력란으로 이동해야 하는 건가요?
이 둘은 별개의 필드인데, 이 전체 동작(제목에서 텍스트 영역으로, 그리고 그 반대)은 다소 기이하게 느껴집니다. 하지만 직접 사용해 보면 생각이 바뀔 수도 있겠네요.
참고로, 아직 이르거나 이미 알려진 내용일 수 있지만, DiscourseHub에서 모바일/iPhone을 사용할 때 툴바가 완전히 보이지 않습니다.
수정
이것은 DiscourseHub와는 무관합니다. 원래 작성기(composer)의 툴바 가시성 상태를 따릅니다.
토글을 통해 툴바를 숨긴 상태에서 새 작성기를 활성화하면 툴바가 표시되지 않으며, AFAIK(제가 아는 한) 이를 다시 표시할 방법이 없습니다. 반대로 원래 작성기에 툴바가 표시되어 있다면, 새 작성기로 전환할 때 툴바가 제공됩니다.
안녕하세요. 지금까지 주신 모든 피드백에 감사드립니다.
구현/수정된 사항들: (병합 대기 중)
제목을 다시 별도의 입력 필드처럼 보이는 섹션으로 포맷팅했습니다. 나중에 다시 검토할 수도 있습니다.
현재 작업 중인 사항:
이 토픽을 계속 지켜보겠습니다 – 다른 피드백 중 일부는 여전히 검토 중입니다.
네, 이것이 문제인 것 같다는 점을 파악했습니다 – 리디자인이 제대로 구현되면(즉, 토글이 더 이상 작동하지 않게 되면) 문제가 되지 않을 것입니다.
조금 주제에서 벗어난 이야기일 수 있지만, “구버전” 편집기에서도 같은 현상이 일어나고 있어서 말씀드립니다. 편집기를 위아래로 드래그하면 커서를 따라오기까지 다소 지연되고, 애니메이션이 끊기는 것처럼 보입니다.
0.25배속으로 재생하면 제가 말씀드리는 현상을 더 잘 보실 수 있습니다.
JS/브라우저의 한계 때문에 쉽게 최적화할 수 없는 것 같다는 생각이 듭니다.
인터페이스 요소가 거의 즉시 반응하고 60fps로 부드럽게 애니메이션되는 모습을 보고 싶습니다.
이 외에도, 새 편집기를 며칠간 사용해보니 전반적으로 더 좋습니다. 마크다운/미리보기 분리, 제목 등 사람들이 공감하는 몇 가지 "결점"은 있지만, 전체적으로는 개선하기 어려운 부분에 대한 매우 훌륭한 향상이라고 생각합니다. 정말 잘하셨네요 ![]()
새로운 작성창이 세로 공간의 상당한 부분을 차지합니다. 이제 새 주제를 작성할 때 크기를 늘려야 합니다. 게시글에 답변을 남길 때는 이런 문제가 덜하거나 아예 없습니다.
참고로,
마크다운 편집기를 사용 중이며, Win11에서 Firefox를 사용하고 있습니다.
안녕하세요, 몇 가지 관찰 사항을 공유합니다.
우리는 메리메이드(mermaid) 플러그인을 사용하여 노드레드(Node-RED) 플로우를 표시합니다. 그러나 이는 새로운 리치 텍스트 에디터나 이전 버전의 리치 텍스트 에디터에서 모두 작동하지 않습니다. 코드가 콘솔 텍스트로 표시됩니다:
이전에는 작성기(composer)를 구형 비(非)리치 텍스트 버전으로 전환하여 이 문제를 우회할 수 있었습니다. 하지만 이제 해당 선택 버튼이 더 이상 작동하지 않습니다.
수정: 괜찮습니다. 페이지를 새로고침하면 버튼이 다시 작동하기 시작했고, 표준 마크업 에디터에서는 메리메이드가 작동하지만 리치 텍스트 버전에서는 작동하지 않습니다.
베타 버전 사파리의 문제인 것 같습니다.
(사파리, Mac OS 27 최신 공개 베타)
이제 수정되었습니다 ![]()
정보 업데이트: 소구(Sogou) 키보드를 샤오미용으로 커스터마이즈했을 때 여전히 발생하지만, Fcitx 키보드에서는 발생하지 않습니다. 어쨌든 특이한 소구 키보드를 더 이상 사용하지 않을 것이므로, 해당 키보드를 우선순위로 다루라고 요청하지는 않겠습니다.