Grav-plugin-admin: UX: Adicionando conteúdo modular

Definitivamente, temos alguns planos sobre como melhorar o gerenciamento de páginas modulares. Do jeito que está agora, é apenas uma questão de simplicidade e consistência do lado do código das coisas. Ainda não é a configuração ideal, mas funciona e alguma documentação também ajudará a melhorar a situação.

Obrigado pela resposta Andy. Ainda estou bastante preocupado com a experiência do usuário com a apresentação atual, embora apenas em termos de criação de página, há algum escopo de mudanças que você consideraria neste momento?

Apenas um rápido pensamento de acompanhamento - se nada mais, acho que alterar o texto da caixa de diálogo Adicionar Modular de "Adicionar conteúdo modular" para "Adicionar conteúdo modular à página" pode ser útil aqui. A longo prazo, e sei que você já tem planos em mente, ainda acho que ter uma caixa de diálogo "Adicionar página" com a capacidade de criar páginas de conteúdo Pai, Filho ou Modular pode ser uma abordagem viável para explorar.

Também me pergunto se colocar o menu suspenso "Página pai" como o primeiro item em "Adicionar página" e "Adicionar modular" também seria mais útil para os usuários, pois essa decisão realmente vem antes de nomear a página etc. O que você acha?

+1 para melhorar o manuseio com páginas modulares dentro do plugin Admin

De uma perspectiva de usuário não técnico, acho que seria mais lógico ter as subpáginas modulares em uma união da página pai. Então, talvez os internos (= subpáginas modulares) estejam ocultos do usuário e ele possa ver e adicionar blocos separados de conteúdo dentro da página pai.

Eu concordo com @Jugibur

Um cliente normal só vai pensar "quero editar esta página". Eles provavelmente clicarão no nome da página e verão isto:

Se eles quiserem adicionar algum conteúdo ou editar o que está lá, eles não saberão o que fazer a partir daqui. Seria um desafio desenhá-lo bem, mas estou imaginando uma página onde posso rolar pelas caixas editáveis ​​para cada um dos módulos da página na ordem em que aparecem e um botão para adicionar um novo.

Como eu disse antes, isso é algo que queremos revisitar. Sabemos que não é o ideal, mas é funcional. Ou seja, funciona.

Estamos agora trabalhando em uma reescrita completa do JS do admin. Isso nos permitirá desenvolver a interface do usuário da página modular que pretendíamos desde o início, mas não tivemos tempo de implementar adequadamente na versão inicial.

Acho que o maior problema agora não é a interface do usuário, mas não poder solicitar páginas modulares manualmente. Eu acho que isso deveria ser o padrão, já que o caso de uso mais comum para páginas modulares são linhas de conteúdo. E para quem tem a ordem de data ou nome não faz sentido.

Além disso, o que ajudaria está conectado a este https://github.com/getgrav/grav-plugin-admin/issues/735 . Também devemos ser capazes de definir páginas que não são editáveis ​​para clientes. Com essas coisas, você pode tornar bastante seguro para o cliente editar as páginas.

Algo assim seria incrível:
https://craftcms.com/docs/matrix-fields
https://github.com/benjamminf/craft-neo

Em relação à recente mesclagem do #1174, houve alguma discussão sobre como a interface do usuário do Admin lida com essa desambiguação. Para citar Paul Massendari no final dessa edição:

Devemos renomear "Adicionar modular" para "Adicionar módulo"? https://github.com/getgrav/grav-plugin-admin/blob/develop/languages/en.yaml#L36

O botão típico para adicionar conteúdo apresenta-se assim:

O que é esperado, considerando os três principais tipos de estruturas que o Grav possui: Página Regular, Pasta e Página Modular. No entanto, o mesmo Dropdown estará lá em outros contextos - o que persiste a ambiguidade do que é uma Página e o que é uma Página Modular. Citando-me do Slack:

Conceitualmente uma página Modular não é uma página normal com uma coleção, é uma estrutura que contém componentes - Módulos - e não deve ter nenhum outro tipo de Página subordinada a ela. Assim, enquanto uma página Modular pode ter páginas filhas regulares em termos de /sample/page, seu conteúdo é totalmente definido pela coleção que só desenha em Módulos, e esses módulos não são visíveis ou roteáveis ​​em outro lugar. Claro, como uma construção é realmente apenas um subconjunto de uma página permitindo um gerenciamento mais fácil de componentes - o mesmo efeito pode ser alcançado com Twig e YAML - mas no nível conceitual ele _deve_ não misturar em páginas regulares. É por isso que uma separação de interesses no menu suspenso "Adicionar" seria preferível, do ponto de vista de como o Grav define as páginas.

A partir dessa perspectiva, um Modular _deve_ não ter páginas-filho regulares ou outros itens-filho que não sejam Módulos, mas com a UI atual, eles podem ser misturados livremente. Um exemplo de Paul Massendari:

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

O que por si só faz todo o sentido semanticamente, mas a ambiguidade entre uma página regular e um Modular é preservada. Assim, para a separação entre os dois - embora um Modular seja um subconjunto de Página - a interface do usuário deve limitar as escolhas ao que é contextualmente apropriado. O menu suspenso em /admin/pages deve oferecer Adicionar página, pasta ou Modular, em uma página Modular deve oferecer Adicionar módulo e em Página e Pasta também deve oferecer adicionar todos os três.

Um resumo da separação contextual (atualizado em 28 de agosto):
Discutido mais com @paulhibbitts e @paulmassen , e meio que chegamos a essa distinção - embora talvez "Child" deva ser "Child Page" para maior clareza.

+Adicionar itens de menu na visualização de lista de páginas
Adicionar Página
Adicionar página de listagem
Adicionar página modular
(Adicionar pasta)

+Adicionar itens de menu na visualização de página padrão
Adicionar filho
(Adicionar pasta)

+Adicionar itens de menu na visualização de página de lista (pai)
Adicionar filho
(Adicionar pasta)

+Adicionar itens de menu na visualização de página modular (pai)
Adicionar módulo
Adicionar filho
(Adicionar pasta)

Onde a pasta está entre colchetes porque deve estar sempre na parte inferior e separada dos tipos de página acima por meio de um indicador visual, como uma borda superior fina para indicar que _não_ é um tipo de página, enquanto todos os itens acima são adequados ao contexto tipos. Os três; Page, Listing, Modular são os tipos padrão padrão e https://learn.getgrav.org/content/content-pages provavelmente deve ser atualizado para refletir isso.

A lógica mais clara parece ser: uma página é qualquer arquivo Markdown renderizado pelo Grav, enquanto uma página de listagem é um subconjunto de página usado para enumerar suas páginas filhas independentes, enquanto uma página modular é um subconjunto de página que habita suas páginas filhas como partes de si mesmo. Assim, Listing links para separar os itens-filho e o Modular os exibe dentro de si mesmo. Page e Listing têm páginas filhas regulares, onde Listing as lista principalmente de alguma forma ordenada. Apenas Modular possui Módulos.

No entanto, também é necessário que os temas se comuniquem por meio de blueprints que dão suporte a tipos de página específicos. Nem todos os temas têm um modelo padrão, ou um para listagem ou modular. Assim, os diálogos, modais, botões ou outro método de adicionar páginas devem refletir o que o tema suporta inerentemente por meio de seus modelos.