관리자 사이드바 내비게이션 소개

진화한 이 동작이 정말 마음에 드는 건지 솔직히 확신이 서지 않습니다:

  • 사이드바의 드롭다운 버전에서 admin을 선택하면
  • 이제 SIDEBAR가 열립니다!

드롭다운을 마치 다른 범위를 다루는 것처럼 새로운 드롭다운 옵션 세트로 대체한 것이 100% 직관적이지는 않았다는 점은 이해합니다. 하지만 이제 우리는 … 사이드바로 … 이동해야 하네요 … :thinking:

또한 드롭다운은 꽤 괜찮았던 2열 구조를 제공했지만, 사이드바는 1열 구조입니다.

완전히 싫어하는 것은 아니지만, 이전 실험적 admin 메뉴 방식의 장점은 충분히 이해할 수 있습니다.

2개의 좋아요

제 진짜 불만은 오직 ‘소개’, ‘FAQ’, ‘이용약관’ 항목이 커뮤니티 섹션에 묻혀 있다는 점입니다.

개인적으로, 제 기억이 맞다면 햄버거 메뉴의 푸터에 있던 그 항목들을 위한 전용 상단 섹션을 따로 두는 게 좋다고 생각합니다.

아니면, 최소한 커뮤니티 바로 위나 아래에 자체 헤더 드롭다운 메뉴를 하나 두는 것도 좋습니다.

1개의 좋아요

여기서는 #admin-sidebar에 대한 개선 사항 논의에만 집중합시다. 위 첫 번째 게시물에서 Martin이 소개한 내용 :point_up:과 관련이 있습니다. 2022년에 도입된 메인 사이드바에 대한 피드백을 제공하거나 개선 사항을 제안하고 싶으시다면, sidebar 태그가 달린 주제들을 확인하시거나 해당 태그로 새로운 주제를 시작해 주세요.

참고로, 관리자 사이드바는 admin_sidebar_enabled_groups 설정을 사용하여 메인 사이드바와 독립적으로 활성화할 수 있습니다.

현재 이 기능은 실험 단계이지만, 기존 가로형 내비게이션보다 훨씬 큰 개선이 되었다고 생각하며 현재 더 널리 배포하고 있습니다. 이미 새 사이트의 기본값으로 설정했으며, 셀프 서비스 플랜을 사용하는 고객들도 이 방식으로 전환하고 있습니다. 최종적으로 관리자 섹션의 유일한 내비게이션이 될 것이며, admin_sidebar_enabled_groups 설정은 제거될 예정입니다. 그때까지, 이 기능이 여러분의 필요에 부합하지 않거나 관리자가 마음에 들지 않는다면, 관리자 설정을 통해 누가 이를 볼지 지정할 수 있습니다.

이번 최신 피드백, 특히 Michael의 피드백은 매우 유용합니다. 감사합니다! 계속 보내주세요. 실행 가능한 피드백은 매우 환영하며, 모든 내용을 숙고하고 있습니다. 현재 메뉴 내 위치와 링크 대상이 명확하지 않아 혼란을 주는 항목들이 있다는 점에 동의합니다. 완성되기까지 많은 변경 사항이 있을 것입니다.

그럼에도 불구하고, 현재로서는 관리자 섹션의 다른 측면을 작업하는 동안 중요한 변경 사항을 하지 않을 예정입니다. 이 작업들은 관리자 섹션을, 특히 Discourse를 처음 사용하거나 현재 복잡한 것으로 느끼는 사용자를 위해 더 편리하게 만들 것으로 기대합니다. 여기에는 새로운 관리자 랜딩 페이지, 각 섹션별 랜딩 페이지, 크럼트레일 내비게이션과 3단계 내비게이션을 포함한 일관된 페이지 레이아웃이 포함됩니다. 함께 묶여야 할 항목들을 보고 설정할 수 있는 새로운 설정 페이지도 작업 중입니다.

고급 사용자가 모든 설정을 한꺼번에 보고 설정을 찾는 데 사용할 수 있는 “모든 사이트 설정” 목적지는 항상 사용 가능합니다. 무엇을 찾고 있는지 아는 파워 유저에게는 사이드바 검색 필터도 유용합니다. 사이드바에 있는 항목들을 넘어 필요한 곳으로 빠르게 이동할 수 있도록 이 부분의 개선도 기대하고 있습니다.

이 피드백에 동의합니다.

관리자가 자주 액세스하는 반면, 다른 항목들은 시작 시 한 번만 설정하거나 가끔만 설정하는 설정들이므로, Users(사용자)를 첫 번째 섹션으로 올리는 것을 고려해 볼 수 있다고 생각했습니다.

관리자 섹션에서 매일 액세스하는 다른 항목이有哪些 있나요?

그럼에도 불구하고, 모든 사이트는 고유하며 모든 사람의 필요와 선호가 다르므로, 여기의 답은 메인 사이드바에서와 같은 사용자 정의 사이드바 섹션일 가능성이 높습니다. 그렇게 하면 누구나 원하는 것을 손쉽게 사용할 수 있습니다.

저도 그렇게 생각합니다. 그리고 네, Hawk가 말한 대로 커뮤니티 섹션은 커뮤니티 구축 작업을 위한 장소로 의도되었습니다.

5개의 좋아요

게시물 3개가 기존 주제에 병합되었습니다: Topic Voting enabled for our #contribute:feature category! :partying_face:

만약 목표가 정말로 커뮤니티 구축 도구에 초점을 맞추는 것이라면, 해당 영역에 초점을 맞추기 위해 "커뮤니티 도구"나 "커뮤니티 구축"이라는 이름을 사용하는 것은 어떨까요? 그렇게 하면 여기에는 맞지 않는 임의의 항목들을 넣는 유혹을 줄일 수 있을 것 같습니다.

사이트 내비게이션 설정은 그 부분에 포함되지 않아야 합니다. 사용자 및 그룹은 포함될 수 있지만, 실제로는 계정 아래에 배치하는 것이 의미론적으로 더 적절하다고 생각합니다.

1개의 좋아요

이 주제는 더 엄격한 조사가 필요할 수도 있지만, 대략 다음과 같은 순서라고 봅니다:

매우 자주 (아마도 매일, 오차 범위 포함)[1]

자주

  • Users (참고로, 저는 'People’으로 이름을 바꿨습니다. Discourse 사이트 사용자와 Fedora Linux 사용자의 모호성을 피하기 위해서요)[3]
  • 태그 그룹 관리 (현재 접근하기가 꽤 번거롭습니다)
  • 테마 컴포넌트 (실제 업무 우선순위에서 벗어나 사이트 만지작거릴 영감에 따라 변동이 큽니다)
  • 스태프 작업 로그 [4]

가끔 (예를 들어, 월 1회 정도?)

  • 폼 템플릿 (그런 것 같습니다. 실제로 사용하는 건 처음이라서요.)
  • 데이터 탐색기 (솔직히 빠른 링크가 있으면 더 많이 사용할 것 같습니다)
  • AI (새로운 것을 시도하면서)
  • 자동화 (더 유연하다면 더 자주 사용할 것입니다. Pie-in-the-sky idea: arbitrary automation scripts via docker image 참고)
  • 웹훅 (항상 뭔가 깨지니까, 한숨)
  • 검색 로그 (사실, 공개 보고서를 만들기 위해 데이터 탐색기의 반복 쿼리를 설정해야 하는데…)

드물게 — 특정 상황이 생길 때

  • 영구 링크 (permalinks)
  • 신뢰 수준 설정[5]
  • 사용자 필드
  • 감시 단어 (watched words)[6]
  • 텍스트 사용자 정의
  • 채팅 통합
  • 백업
  • API 키
  • 이메일 템플릿 / 스타일
  • 커스텀 이모지
  • 스크리닝된 이메일 / IP
  • 게시 (실제로, 사이트가 정상 운영되면 대부분의 이런 설정은 매우 드물지만, 처음에는 제대로 맞추기 위해 많은 조정이 필요합니다)
  • 파일 (同上)
  • 개발자 (흥미로운 새로운 실험이 나타날 때…)
  • 기타 (同上)
  • 기본 사용자 환경 설정

초기, 그리고 아마도 5년에 한 번 정도

  • 필수 설정
  • 기본 설정
  • 브랜딩
  • 로그인/인증 설정
  • 사용자 이름 / 그룹 구성 및 규칙 세부 사항
  • 법적 / 정책 URL
  • 내비게이션 관련 설정
  • 이메일 설정
  • 색상
  • 임베딩 (embeddings)
  • 보안 설정
  • 스팸 설정
  • 속도 제한 (rate limits)
  • 검색 설정
  • api 설정
  • 사용자 api
  • 태그 설정 (설정 페이지, 태그 목록이 아님)
  • 대시보드 (이것이 존재하는지 몰랐습니다. 이제 몇 가지를 설정해 보겠습니다!)

거의 절대

  • 배지 설정 (외부 통합을 사용하고 있기 때문에)
  • 캘린더 플러그인 설정
  • rss 폴링 (현재 이 기능을 사용하지 않기 때문에)
  • 스크리닝된 URL (이것은 단순히 보고서인 것 같습니다? 저희 경우, 대부분 실수로 스팸으로 태그된 도메인입니다. 이 목록을 어떻게 편집할 수 있을까요?)
  • 에러 로그 (호스팅 비용을 지불하는 이유가 있지 않나요? :slight_smile: )
  • onebox (솔직히 기본값이 이걸 제대로 처리해 줄 것이라고 기대합니다)

  1. probably daily, give or take ↩︎

  2. 알아요, 이건 제가 절대 포기하지 않을 또 다른 항목입니다 :slight_smile: ↩︎

  3. 사실 이건 거짓말입니다. 저는 이 기능을 자주 사용할 수 있지만, 대신 보통 일반 사이트 검색으로 이름을 찾습니다. 제 워크플로우의 인체공학적 측면에 대해 자아성찰이 필요할지도 모르겠네요 ↩︎

  4. “그건 누구 탓이지?” … “아, 나였구나. 문제는 나였어” ↩︎

  5. 예를 들어, 이제 리액션(Reactions)이 좋아요(Likes)로 계산될 수 있게 되면서… ↩︎

  6. 이 기능이 Automation 플러그인과 더 잘 통합되면 좋겠습니다! ↩︎

4개의 좋아요

2개의 게시물이 새로운 주제로 분리되었습니다: 헤더 드롭다운 내비게이션 선택 시 관리자 사이드바 피드백

최근 2.4에서 3.4beta로 업그레이드했는데, 새로운 관리자 사이드바를 활성화하는 설정을 찾을 수 없습니다. 'admin_sidebar_enabled_groups’나 'admin_sidebar’를 검색해도 결과가 나오지 않습니다.

3개의 좋아요

해당 설정은 최근에 숨겨졌습니다:

Using Hidden Site Settings

4개의 좋아요

저희 호스팅에서는 모든 사이트가 새 사이드바를 받도록 하겠습니다. 셀프 호스터를 위한 지침을 추가하도록 OP를 업데이트했습니다:

5개의 좋아요

정말 2년 전에 만들어진 거였다는 걸 알기 위해 계정을 하나 새로 만들었네요

2개의 좋아요

저는 3.5.0.beta1-dev를 사용 중인데, 아직 기존 상단 내비게이션을 사용하고 있습니다.

이 기능이 제거될 구체적인 향후 버전 번호를 알 수 있을까요?

4개의 좋아요

이렇게 묻는 이유는, ‘무시’ 버튼을 아무리 많이 눌러도 이 경고가 사라지지 않기 때문입니다. 관리자 패널을 열 때마다 항상 표시되거든요:

2개의 좋아요

네, 여기에서도 같은 문제입니다.

1개의 좋아요

변경 사항은 곧 적용될 예정입니다.

이 안내가 불편하다면, 관리자 사이드바로 전환하는 것을 권장합니다.

1개의 좋아요

여전히 이 시스템이 마음에 들지 않습니다. 특히 모바일에서는 사용이 매우 불편합니다.

기존 시스템에서는 '관리자’를 선택하면 즉시 하위 항목을 선택할 수 있는 메뉴가 나타났습니다.

하지만 지금은 '관리자’를 누르면 대시보드만 표시되고 끝입니다. 하위 메뉴가 없습니다.

현재는 (직관적이지 않은 방식으로) 한 번 더 클릭해야 관리자 메뉴가 열립니다.

이 과정은 너무 자주 반복되어 상당한 마찰을 유발합니다.

모바일에서 '관리자’를 누르면 대시보드를 표시하면서 즉시 사이드 메뉴를 펼치는 것은 어떨까요? 만약 (비일상적인) 목적이 단순히 대시보드에 도달하는 것이라면, 해당 항목을 클릭하거나 메뉴 바깥을 클릭하면 됩니다.

핵심은, 과거에 두 번의 클릭(관리자 → 하위 메뉴)으로 충분했던 작업을 이제 세 번의 클릭(관리자 → 메뉴 → 하위 메뉴)을 강요하고 있다는 점입니다.

6개의 좋아요

저와 제 팀은 결국 모바일에서는 관리자 기능을 사용하지 않기로 마음을 먹었습니다.

팀원 중 일부는 실제로 고장 난 것이라고 생각하기도 했습니다. 이후 버거 메뉴를 클릭해야 한다는 사실을 몰랐기 때문이죠 :confused:

이것도 별로 마음에 들지 않습니다:

이제 아무것도 찾기 너무 어렵습니다 :cry:

3개의 좋아요

전적으로 동의합니다! 실수로 잘못된 상자를 검색하려고 한 적이 몇 번 있었는데, 정말 짜증납니다.

2개의 좋아요

아니면 더 직관적으로, 관리자 메뉴 항목을 클릭할 때 관리자 사이드 메뉴를 펼치되, 아직 어디로든 이동하지 않는 방식이 좋을 수도 있습니다.

1개의 좋아요

모바일에서는 대시보드로 이동했다가 다시 여는 것보다 패널을 전환하는 방식이 더 좋을 것 같습니다.

2개의 좋아요