Grav-plugin-admin: UX: 모듈식 콘텐츠 추가

모듈식 페이지 관리를 개선하는 방법에 대한 몇 가지 계획이 있습니다. 현재의 방식은 사물의 코드 측면에서 단순성과 일관성의 문제일 뿐입니다. 아직 이상적인 설정은 아니지만 작동하며 일부 문서도 상황을 개선하는 데 도움이 될 것입니다.

답변 감사합니다 Andy. 나는 여전히 현재 프리젠테이션의 사용자 경험에 대해 상당히 우려하고 있지만 페이지 생성 측면에서 이 시점에서 고려하려는 변경 범위가 있습니까?

빠른 후속 조치 생각 - 다른 것이 없다면 "모듈식 콘텐츠 추가"에서 "모듈식 콘텐츠를 페이지에 추가"로 모듈식 추가 대화 상자의 텍스트를 변경하는 것이 도움이 될 수 있다고 생각합니다. 장기적으로, 그리고 이미 염두에 두고 있는 계획이 있다는 것을 알고 있지만, 여전히 상위, 하위 또는 모듈식 콘텐츠 페이지를 생성할 수 있는 "페이지 추가" 대화 상자가 있는 것이 탐색할 수 있는 실행 가능한 접근 방식이 될 수 있다고 생각합니다.

또한 "페이지 추가" 및 "모듈 추가"의 첫 번째 항목으로 "상위 페이지" 드롭다운을 두는 것이 실제로 페이지 이름 등을 지정하기 전에 결정이 내려지기 때문에 사용자에게 더 도움이 되는지 궁금합니다. 어떻게 생각하세요?

Admin 플러그인 내부의 모듈식 페이지 처리 개선을 위해 +1

비기술적인 사용자 관점에서는 상위 페이지의 통합에 모듈식 하위 페이지를 갖는 것이 더 논리적이라고 생각합니다. 따라서 아마도 내부(= 모듈식 하위 페이지)는 사용자에게 숨겨져 있고 사용자는 상위 페이지 내부에 별도의 콘텐츠 블록을 보고 추가할 수 있을 뿐입니다.

@Jugibur님 말씀 에 동의합니다.

일반 고객은 "이 페이지를 편집하고 싶다"고 생각할 것입니다. 페이지 이름을 클릭하면 다음과 같이 표시됩니다.

그들이 콘텐츠를 추가하거나 거기에 있는 것을 편집하고 싶어도 여기에서 무엇을 해야 할지 모를 것입니다. 그것을 잘 디자인하는 것은 어려운 일이지만, 각 페이지의 모듈에 대해 나타나는 순서대로 편집 가능한 상자를 스크롤할 수 있는 한 페이지와 새 모듈을 추가하는 버튼을 상상하고 있습니다.

전에 말했듯이 이것은 우리가 다시 방문하고 싶은 것입니다. 이상적이지는 않지만 기능적입니다. 즉, 작동합니다.

우리는 지금 관리자의 전체 JS 재작성 작업을 하고 있습니다. 이를 통해 처음부터 의도했지만 초기 버전에서 제대로 구현할 시간이 없었던 모듈식 페이지 UI를 개발할 수 있습니다.

지금 가장 큰 문제는 UI가 아니라 모듈식 페이지를 수동으로 주문할 수 없다는 것입니다. 모듈식 페이지의 가장 일반적인 사용 사례는 콘텐츠 행이기 때문에 이것이 기본값이어야 한다고 생각합니다. 그리고 날짜 나 이름 순서가있는 사람들에게는 의미가 없습니다.

또한 도움이 되는 것은 https://github.com/getgrav/grav-plugin-admin/issues/735 에 연결되어 있습니다. 또한 클라이언트가 편집할 수 없는 페이지를 정의할 수 있어야 합니다. 이러한 것들을 사용하면 클라이언트가 페이지를 편집하는 것을 매우 안전하게 만들 수 있습니다.

다음과 같은 것이 놀랍습니다.
https://craftcms.com/docs/matrix-fields
https://github.com/benjamminf/craft-neo

최근 #1174 병합과 관련하여 관리자 UI가 이 명확성을 처리하는 방법에 대한 논의가 있었습니다. 그 호의 끝에서 Paul Massendari를 인용하자면:

"모듈 추가"를 "모듈 추가"로 이름을 바꿔야 합니까? https://github.com/getgrav/grav-plugin-admin/blob/develop/languages/en.yaml#L36

콘텐츠 추가를 위한 일반적인 버튼은 다음과 같이 표시됩니다.

Grav의 세 가지 주요 구조 유형인 일반 페이지, 폴더 및 모듈식 페이지를 고려할 때 예상대로입니다. 그러나 동일한 드롭다운이 다른 컨텍스트에 있을 것입니다. 이는 페이지 및 모듈식 페이지가 무엇인지에 대한 모호성을 유지합니다. Slack의 말을 인용하자면:

개념적으로 모듈식 페이지는 컬렉션이 있는 일반 페이지가 아니며 구성 요소(모듈)를 포함하는 구조이며 이에 종속되는 다른 유형의 페이지가 없어야 합니다. 따라서 모듈식 페이지는 /sample/page와 관련하여 일반 하위 페이지를 가질 수 있지만 그 콘텐츠는 모듈만 그리는 컬렉션에 의해 완전히 정의되며 이러한 모듈은 다른 곳에서 보거나 라우팅할 수 없습니다. 물론 구성 요소로서 이는 구성 요소를 보다 쉽게 ​​관리할 수 있는 Page의 하위 집합일 뿐입니다. Twig 및 YAML을 사용하여 동일한 효과를 얻을 수 있지만 개념적 수준에서는 일반 페이지에서 _혼합해서는 안 됩니다_. 이것이 Grav가 페이지를 정의하는 관점에서 "추가" 드롭다운에서 관심사를 분리하는 것이 바람직한 이유입니다.

그런 관점에서 모듈러에는 모듈 이외의 일반 하위 페이지나 다른 하위 항목이 _없어야 _하지만, 현재 UI에서는 이것들을 아주 자유롭게 혼합할 수 있습니다. Paul Massendari의 예:

- home
- blog
  -_introtext
  -_latestarticles
  - _subscribe  
  - article1
  - article2

그 자체로 의미적으로는 완벽하지만 일반 Page와 Modular 사이의 모호성은 보존됩니다. 따라서 Modular는 Page의 하위 집합이지만 둘 사이의 분리를 위해 UI는 상황에 따라 적절한 것으로 선택을 제한해야 합니다. /admin/pages의 드롭다운은 페이지, 폴더 또는 모듈 추가를 제안해야 하고, 모듈 페이지에서는 모듈 추가를 제안해야 하며, 페이지와 폴더 모두에서 세 가지를 모두 추가하도록 제안해야 합니다.

문맥 분리 요약(8월 28일 업데이트):
@paulhibbitts 및 @paulmassen 과 더 논의했으며 이러한 구분에 도달했습니다. 하지만 명확성을 위해 "Child"가 "Child Page"여야 할 수도 있습니다.

+페이지 목록 보기에 메뉴 항목 추가
페이지 추가
목록 페이지 추가
모듈식 페이지 추가
(폴더 추가)

+표준 페이지 보기에 메뉴 항목 추가
하위 추가
(폴더 추가)

+목록(상위) 페이지 보기에 메뉴 항목 추가
하위 추가
(폴더 추가)

+모듈식(상위) 페이지 보기에서 메뉴 항목 추가
모듈 추가
하위 추가
(폴더 추가)

폴더는 항상 맨 아래에 있어야 하고 위의 페이지 유형과 구분되어 페이지 유형이 _not_임을 나타내는 시각적 표시기를 통해 위의 모든 페이지 유형과 구분되어야 하기 때문에 대괄호 안에 있습니다. 유형. 세; 그러면 Page, Listing, Modular가 기본 표준 유형이며 https://learn.getgrav.org/content/content-pages 가 이를 반영하도록 업데이트되어야 합니다.

가장 명확한 논리는 다음과 같습니다. Page는 모든 Markdown 파일 Grav 렌더링이고, Listing Page는 독립형 하위 페이지를 열거하는 데 사용되는 Page의 하위 집합인 반면, Modular Page는 하위 페이지에 상주하는 Page의 하위 집합입니다. 자신의 일부로. 따라서 Listing은 별도의 하위 항목에 대한 링크를 제공하고 Modular는 해당 항목을 자체적으로 표시합니다. Page 및 Listing에는 일반 하위 페이지가 있으며 Listing은 주로 정렬된 방식으로 나열합니다. 모듈러에만 모듈이 있습니다.

그러나 테마가 특정 페이지 유형을 지원하는 청사진을 통해 통신할 필요도 있습니다. 모든 테마에 기본 템플릿이나 목록 또는 모듈식 템플릿이 있는 것은 아닙니다. 따라서 페이지를 추가하는 대화, 모달, 버튼 또는 기타 방법은 테마가 템플릿을 통해 본질적으로 지원하는 것을 반영해야 합니다.