Grav-plugin-admin: UX: Agregar contenido modular

Creado en 8 ago. 2015  ·  9Comentarios  ·  Fuente: getgrav/grav-plugin-admin

Estoy descubriendo que la ubicación del botón "Agregar modular" en el nivel de "Administrar páginas" presenta un modelo conceptual poco claro de cuál es su funcionamiento. Inicialmente pensé que crearía una "Nueva página" de tipo modular a la que luego agregaría Contenido modular dentro de la página misma, pero ese no parece ser el caso (si entiendo las cosas correctamente).

Hay varios enfoques alternativos posibles. Un enfoque podría ser tener solo el botón "Agregar página" en el nivel de "Administrar páginas" y en ese cuadro de diálogo resultante tener una opción para crear una página estándar (secundaria) o modular. Otra opción podría ser dejar el cuadro de diálogo "Agregar página" tal como está, pero dentro de una página incluir la opción para luego agregar contenido modular con ese mismo nivel, por ejemplo, cómo puede agregar medios a una página.

Espero escuchar los comentarios y opiniones de otros sobre este tema.

Gracias,
Pablo

evaluating ux

Comentario más útil

Coincido con @Jugibur

Un cliente normal solo va a pensar "quiero editar esta página". Probablemente harán clic en el nombre de la página y luego verán esto:

screen shot 2016-02-27 at 1 10 19 pm

Ya sea que quieran agregar algún contenido o editar lo que hay allí, no van a saber qué hacer desde aquí. Sería un desafío diseñarlo bien, pero estoy imaginando una página en la que puedo desplazarme por cuadros editables para cada uno de los módulos de la página en el orden en que aparecen, y un botón para agregar uno nuevo.

Todos 9 comentarios

Definitivamente tenemos algunos planes sobre cómo mejorar la administración de páginas modulares. Tal como está ahora, es simplemente una cuestión de simplicidad y coherencia desde el punto de vista del código. Todavía no es la configuración ideal, pero funciona y alguna documentación también ayudará a mejorar la situación.

Gracias por la respuesta Andy. Todavía estoy bastante preocupado por la experiencia del usuario con la presentación actual, aunque solo en términos de creación de páginas, ¿hay algún cambio que consideraría en este momento?

Solo un pensamiento de seguimiento rápido: al menos, creo que cambiar el texto del cuadro de diálogo Agregar modular de "Agregar contenido modular" a "Agregar contenido modular a la página" podría ser de ayuda aquí. A largo plazo, y sé que ya tiene planes en mente, sigo pensando que tener un cuadro de diálogo "Agregar página" con la capacidad de crear páginas de contenido principal, secundario o modular podría ser un enfoque viable para explorar.

También me pregunto si poner el menú desplegable "Página principal" como el primer elemento tanto en "Agregar página" como en "Agregar modular" también sería más útil para los usuarios, ya que esa decisión realmente viene antes de nombrar la página, etc. ¿Qué piensas?

+1 para mejorar el manejo con páginas modulares dentro del complemento de administración

Desde la perspectiva de un usuario no tecnológico, creo que sería más lógico tener las subpáginas modulares en una unión de la página principal. Entonces, quizás las partes internas (= subpáginas modulares) están ocultas para el usuario y él solo puede ver y agregar bloques separados de contenido dentro de la página principal.

Coincido con @Jugibur

Un cliente normal solo va a pensar "quiero editar esta página". Probablemente harán clic en el nombre de la página y luego verán esto:

screen shot 2016-02-27 at 1 10 19 pm

Ya sea que quieran agregar algún contenido o editar lo que hay allí, no van a saber qué hacer desde aquí. Sería un desafío diseñarlo bien, pero estoy imaginando una página en la que puedo desplazarme por cuadros editables para cada uno de los módulos de la página en el orden en que aparecen, y un botón para agregar uno nuevo.

Como dije antes, esto es algo que queremos revisar. Sabemos que no es ideal, pero es funcional. es decir, funciona.

Ahora estamos trabajando en una reescritura completa de JS del administrador. Esto nos permitirá desarrollar la interfaz de usuario de la página modular que pretendíamos desde el principio, pero que no tuvimos tiempo de implementar correctamente en la versión inicial.

Creo que el mayor problema en este momento no es la interfaz de usuario, sino no poder ordenar páginas modulares manualmente. Creo que esto debería ser predeterminado, ya que el caso de uso más común para las páginas modulares son las filas de contenido. Y para los que tienen la fecha o el nombre el orden no tiene sentido.

Además, lo que ayudaría está conectado a este https://github.com/getgrav/grav-plugin-admin/issues/735 . También deberíamos poder definir páginas que no sean editables para los clientes. Con estas cosas, puede hacer que sea bastante seguro para el cliente editar las páginas.

Con respecto a la fusión reciente de #1174, ha habido cierta discusión sobre cómo la interfaz de usuario del administrador maneja esta desambiguación. Para citar a Paul Massendari del final de ese número:

¿Deberíamos cambiar el nombre de "Agregar modular" a "Agregar módulo"? https://github.com/getgrav/grav-plugin-admin/blob/develop/languages/en.yaml#L36

El botón típico para agregar contenido se presenta así:

Dropdown

Lo cual es como se esperaba dados los tres tipos principales de estructuras que tiene Grav: página normal, carpeta y página modular. Sin embargo, el mismo menú desplegable estará allí en otros contextos, lo que persiste en la ambigüedad de qué es una página y qué es una página modular. Para citarme a mí mismo de Slack:

Conceptualmente, una página modular no es una página normal con una colección, es una estructura que contiene componentes (módulos) y no debe tener ningún otro tipo de página subordinada. Por lo tanto, mientras que una página Modular puede tener páginas secundarias regulares en términos de /muestra/página, su contenido está completamente definido por la colección que solo se basa en Módulos, y estos módulos no son visibles ni enrutables en ningún otro lugar. Por supuesto, como construcción, en realidad es solo un subconjunto de una página que permite una gestión más sencilla de los componentes; se puede lograr el mismo efecto con Twig y YAML, pero en el nivel conceptual, _no debe_ mezclarse en páginas normales. Es por eso que sería preferible una separación de preocupaciones en el menú desplegable "Agregar", desde el punto de vista de cómo Grav define las páginas.

Desde esa perspectiva, un Modular _no debería_ tener páginas secundarias regulares u otros elementos secundarios que no sean Módulos, pero con la interfaz de usuario actual, estos se pueden mezclar con bastante libertad. Un ejemplo de Paul Massendari:

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

Lo cual en sí mismo tiene mucho sentido semánticamente, pero se conserva la ambigüedad entre una página normal y una modular. Por lo tanto, para la separación entre los dos, aunque Modular es un subconjunto de Page, la interfaz de usuario debe limitar las opciones a lo que es contextualmente apropiado. El menú desplegable en /admin/pages debe ofrecer Agregar página, carpeta o modular, en una página modular debe ofrecer Agregar módulo, y tanto en Página como en Carpeta también debe ofrecer agregar los tres.

Un resumen de la separación contextual (actualizado el 28 de agosto):
Discutido más a fondo con @paulhibbitts y @paulmassen , y más o menos llegamos a esta distinción, aunque tal vez "Niño" debería ser "Página infantil" para mayor claridad.

+ Agregar elementos de menú en la vista de lista de páginas
Añadir página
Agregar página de listado
Añadir página modular
(Agregar carpeta)

+ Agregar elementos de menú en la vista de página estándar
Agregar niño
(Agregar carpeta)

+ Agregar elementos de menú en la vista de página de lista (principal)
Agregar niño
(Agregar carpeta)

+ Agregar elementos de menú en la vista de página modular (principal)
Agregar módulo
Agregar niño
(Agregar carpeta)

Donde la carpeta está entre paréntesis porque siempre debe estar en la parte inferior y separada de los tipos de página anteriores a través de un indicador visual, como un borde superior delgado para indicar que _no_ es un tipo de página, mientras que todo lo anterior se adapta al contexto tipos El tres; Page, Listing, Modular son entonces tipos estándar predeterminados, y https://learn.getgrav.org/content/content-pages probablemente debería actualizarse para reflejar esto.

La lógica más clara parece ser: una página es cualquier archivo Markdown que Grav renderiza, mientras que una página de listado es un subconjunto de la página que se usa para enumerar sus páginas secundarias independientes, mientras que una página modular es un subconjunto de la página que habita en sus páginas secundarias. como partes de sí mismo. Por lo tanto, Listing vincula elementos secundarios separados y Modular los muestra dentro de sí mismo. Page y Listing tienen páginas secundarias regulares, donde Listing las enumera principalmente de forma ordenada. Solo Modular tiene Módulos.

Sin embargo, también existe la necesidad de que los temas se comuniquen a través de planos que admiten tipos de página específicos. No todos los temas tienen una plantilla predeterminada, o una para listado o modular. Por lo tanto, los diálogos, modales, botones u otros métodos para agregar páginas deben reflejar lo que el tema soporta inherentemente a través de sus plantillas.

¿Fue útil esta página
0 / 5 - 0 calificaciones