Integración con la interfaz de usuario de WordPress: conceptos básicos
Spanish (Español) translation by Esther (you can also view the original English article)
Desde hace mucho tiempo se acepta que una de las mayores ventajas de WordPress sobre sus competidores es su interfaz de usuario de administración. En general, es muy fácil e intuitivo de usar. Además está siendo constantemente refinado y mejorado, con la pantalla de carga de los medios ahora una de las muchas cosas bajo escrutinio. Desafortunadamente, hay algo que el equipo de WordPress-UI no tiene control, lo que deshace consistentemente todo su duro trabajo: plugins y temas.
La interfaz de usuario de tu plugin (usaré el término plugin en este artículo, pero lo mismo se aplica a la interfaz de usuario de tu tema) es uno de los aspectos más importantes de tu plugin. Define la forma en que la gente interactúa con él, lo fácil que es de usar, y tal vez incluso lo mucho que disfrutan usándolo. Este es el objetivo final de tu plugin: hacer una o varias tareas particulares más fáciles para el usuario final (de hecho, este es el objetivo aparentemente olvidado de los propios ordenadores). La interfaz de usuario debe ser atractiva, pero en última instancia debe ser funcional. Cuando decidas cómo diseñar tu plugin, tienes que decidir cómo hacer que tu plugin sea fácil de usar, mejor aún, obtener retroalimentación, esto es esencialmente lo que está haciendo WordPress.
Introducción
En las últimas semanas y meses se ha discutido mucho sobre cómo se podría mejorar la usabilidad de WordPress, desde mejoras generales de la interfaz de usuario hasta la accesibilidad (si no crees que la accesibilidad sea un problema ni para WordPress ni para tu plugin, te recomiendo que eches un vistazo a la excelente charla de Graham Armfield en WordCamp Edimburgo). Más recientemente, Tom McFarlin provocó un gran debate sobre la integración con la interfaz de usuario de WordPress. La discusión se centró en la necesidad de una guía de interfaz de usuario para los autores de plugins, para ayudarles a asegurar que sus plugins se integren perfectamente en WordPress. Esta pauta está empezando a tomar forma en la forma de las Directrices de la Interfaz de Usuario de WordPress.
En esta serie veremos los pasos que puedes seguir para ayudar a integrar tu plugin en la interfaz de usuario de WordPress. En este artículo, nos centraremos en algunas pautas básicas, así como en algunas de las API de la interfaz de usuario disponibles para ti. Por favor, toma nota de que estas directrices no son de ninguna manera "oficiales". En los artículos siguientes veremos ejemplos más "prácticos", incluyendo el uso de metaboxes en páginas de administración personalizadas, y el uso de punteros de administración de WordPress.
Por qué es importante la integración con WordPress
La experiencia del usuario
Esta es la razón más importante. El propósito principal tanto de la interfaz de usuario de WordPress como de tu plugin o tema es facilitar la gestión y producción de contenidos para el usuario final. Es para permitir que el usuario logre un propósito específico. Si tu plugin o tema introduce una interfaz que es muy diferente a la de WordPress, entonces estás forzando al usuario a aprender una interfaz completamente nueva. Al hacerlo, se lo estás poniendo más difícil y probablemente te desinstalen el plugin y encuentren otro. La consistencia es la clave aquí.
En segundo lugar, es feo cuando un plugin o tema sobresale como un pulgar adolorido. El administrador de WordPress es (en su mayoría) bellamente consistente, y los plugins que no encajan son solo una llaga en el ojo. Esto no quiere decir que la propia interfaz de usuario del plugin sea particularmente fea. Puede ser que la interfaz del plugin sea ingeniosa, pero aún así se verá fuera de contexto.
Los mejores plugins encajan perfectamente en WordPress hasta el punto de que es casi imposible saber dónde se detiene el propio WordPress y se inicia el plugin. Son estos plugins los que los usuarios disfrutan usando, en gran parte porque parece que están destinados a estar ahí. Los plugins deberían ampliar WordPress, no convertirlo en un CMS que el Dr. Frankenstein produciría.
Prueba de futuro de tu plugin
WordPress ofrece muchas maneras de ayudarte a "encajar" con WordPress. También proporciona un montón de CSS en las páginas de administración que puedes aprovechar. Hacer ambas cosas es una forma efectiva de "probar el futuro" de la interfaz de usuario de tu plugin. Cualquier cambio que se haga en WordPress se reflejará en tu plugin también. Por otra parte, si "vas solo" con tu interfaz de administración, cada actualización de WordPress trae consigo una mayor probabilidad de que la interfaz de tu plugin entre en conflicto con WordPress. Usando los estilos y diseños de WordPress, haces la vida un poco más fácil para ti, así como para tus usuarios.
Directrices administrativas no oficiales de la interfaz de usuario
Reduce tu huella de plugin
Podrías pensar que tu plugin es lo más importante en el repositorio, y podría ser el mejor de su clase ahí fuera. ¿Pero realmente necesita un lugar privilegiado en el menú de administración? Un aspecto importante de cualquier interfaz de usuario es la simplicidad que permite a los usuarios encontrar lo que quieren rápidamente. El desbarajuste del menú es lo opuesto a esto.
Tu plugin puede que ni siquiera necesite su propia subpágina. A todas las páginas de configuración predeterminada se les pueden añadir secciones. Si tu plugin solo tiene unos pocos ajustes, y no estarían fuera de lugar en una página de ajustes existente, deberías considerar esto.
Si tu plugin requiere un lugar en el menú de nivel superior, piensa cuidadosamente dónde debe ir. El menú de administración está dividido en tres secciones: el tablero, la administración de contenidos y la configuración. El lugar donde debe ir el elemento del menú de nivel superior depende del propósito principal del plugin. Si se trata de producir, editar y gestionar el contenido, debe ir en el medio. Si su propósito es el mantenimiento, el rendimiento o la configuración (por ejemplo, la integración con un software de terceros, el almacenamiento en memoria caché o los plugins de respaldo), éstos probablemente deberían ir en la parte inferior.
Finalmente, tu plugin no debería imponerse demasiado. Llenar tu plugin con enlaces de 'donación', anuncios o feeds de tu blog no hará que tu plugin se gane la simpatía de tus usuarios. La "marca" del plugin debe ser evitada, o al menos lo suficientemente sutil para no entrar en conflicto con la interfaz de usuario de WordPress.


Aunque esto no afecte a la usabilidad del plugin, la integración en el aspecto de WordPress hace que la experiencia del usuario sea mejor y más fluida. No es que la marca del plugin sea terrible (algunos se ven fantásticos), sino más bien que se ven fuera de lugar.
Decisiones, no opciones
La mayoría de los autores de plugins, comprensiblemente, quieren que su plugin atraiga a la mayor cantidad de usuarios posible. Un desafortunado efecto secundario es que al usuario se le presenta un abanico de opciones. Parte de la filosofía de WordPress son las decisiones, no las opciones:
Como desarrolladores, a veces sentimos que dar opciones para todo es algo bueno, nunca puedes tener demasiadas opciones, ¿verdad? En última instancia, estas opciones terminan siendo técnicas, opciones en las que el usuario final promedio no tiene interés. Es nuestro deber como desarrolladores tomar decisiones de diseño inteligentes y evitar poner el peso de las opciones técnicas en nuestros usuarios finales.
Hay dos cosas que deben ser equilibradas: por un lado quieres que los usuarios puedan modificar el comportamiento de tu plugin. Por otro lado, demasiadas opciones pueden dificultar la búsqueda de cualquiera de ellas y pueden dejar al usuario desconcertado y frustrado. No hay una talla única para todos aquí, y es un juicio que debe hacerse sobre tus experiencias de lo que tus usuarios piden.
Sin embargo, las opciones no son la única manera de permitir que tu plugin sea ajustado:
- Usa ganchos de plugin. A veces, sobre todo cuando se trata de los aspectos más técnicos de tu plugin, es más apropiado introducir un gancho, para permitir que se cambie un ajuste, o que se desencadene una acción, que introducir una serie de opciones para lograr el mismo propósito.
- Proporcionando plantillas de plugins anulables. Por ejemplo, en mi plugin Organizador de Eventos, se incluyen plantillas básicas, que por defecto, se utilizan. El usuario puede copiarlos en su tema y editarlos allí para anularlo. Esto le da al usuario un control completo, pero no necesita una página de configuración extensa.
- Sé inteligente. Por ejemplo, hace poco creé un registro de pagos que incluía una columna de fechas para ser formateada usando solo números. Pero los usuarios americanos a menudo esperan que las fechas estén en formato mm-dd-yyyy, mientras que los europeos esperan que las fechas estén en formato dd-mm-yyyy. El registro daba formato a las fechas según la zona horaria del sitio (aunque se añadió una opción de pantalla en caso de que fuera necesario modificarla).
La configuración del plugin va bajo...
¿La opción de menú de ajustes? ¿O tu propio menú de nivel superior? Incluso he encontrado algunos en el menú de "Plugins" antes de ahora. Hay mucho debate sobre esto. Para la mayoría de los plugins, que no necesitan su propio menú de nivel superior, la decisión se toma por ellos. ¿Pero qué hay de los plugins que sí lo hacen? Solo puedo dar mi opinión aquí. Un punto convincente es que algunos usuarios esperan encontrar la configuración del plugin en el menú del mismo. En algunos casos, sin embargo, creo que esto expone un mal uso del menú de administración, el menú no debería ser el "menú de los plugins", sino un menú asociado a algún tipo de tarea (como crear y editar posts, ver comentarios, etc). Así como WordPress separa las tareas de los ajustes, también lo hacen los plugins.
En segundo lugar, cambiar la configuración es una tarea en sí misma, que se hace raramente, a menudo solo después de instalar WordPress o un plugin. Como no es visitado regularmente, al colocarlo en el menú de ajustes, se ordena el submenú de tu plugin para el uso diario.
Si quieres asegurarte de que no se pierda la página de configuración, te animo a que añadas un enlace a ella bajo el nombre de tu plugin en la página "Plugins". Esta es la página en la que el usuario aterrizará cuando active el plugin, y así le será más fácil encontrar tu configuración.


Aquí hay un ejemplo de cómo lograrlo:
1 |
add_filter('plugin_action_links', 'wptuts_plugin_settings_link', 10, 2); |
2 |
function wptuts_plugin_settings_link($links, $file) { |
3 |
|
4 |
if ( $file == 'myplugin/myplugin.php' ) { |
5 |
/* Insert the link at the end*/
|
6 |
$links['settings'] = sprintf( '<a href="%s"> %s </a>', admin_url( 'options-general.php?page=my_plugin_settings' ), __( 'Settings', 'plugin_domain' ) ); |
7 |
}
|
8 |
return $links; |
9 |
|
10 |
}
|
Pestañas de la página
Si la configuración de tus plugins no se ajusta cómodamente a una página, debes considerar el uso de pestañas para dividirlos. WordPress utiliza pestañas en la página Apariencia -> Temas, y éstas pueden añadirse a tu configuración (o a páginas de administración personalizadas, si es necesario). Cuando se usan pestañas de páginas hay muy pocas razones para no usar las pestañas de WordPress. Cómo hacer esto fue cubierto en la serie de APIs de Tom McFarlin aquí en Wptuts+.
¿Pero qué pasa si necesitas demasiadas pestañas? Las pestañas horizontales no se escalan particularmente bien, y las pestañas desbordantes pueden parecer confusas y feas. Este plugin hace un buen intento de lidiar con un montón de páginas de ajustes, pero las líneas de ajustes todavía lo hacen abrumador:


Supongamos que todas estas pestañas son necesarias (que probablemente no lo sean), entonces puedes decidir que las pestañas verticales son una solución más adecuada. He visto algunos temas que implementan pestañas verticales (a menudo mal), usualmente usando su propio estilo. Aunque WordPress no utiliza pestañas verticales (con la excepción de las pestañas de ayuda), debes basar tus diseños en lo que está disponible para ti. Siéntete libre de experimentar, pero trata de mantenerlo como algo nativo de WordPress, será interesante ver lo que se le ocurre a la gente.
Avisos de la administración
WordPress tiene dos tipos de avisos de administración: avisos generales, y mensajes de error, estilizándolos en amarillo y rojo respectivamente. Si tu plugin necesita mostrar un aviso al usuario, debes usar uno u otro dependiendo del contexto del mensaje.


El uso de la API de avisos de WordPress es una forma muy fácil de dar al usuario una experiencia consistente. Un ejemplo de cómo hacerlo es:
1 |
/*
|
2 |
* Admin notice nag - displays a message
|
3 |
*/
|
4 |
/* Display a notice that can be dismissed */
|
5 |
add_action( 'admin_notices', 'wptuts_admin_notices' ); |
6 |
function wptuts_admin_notices() { |
7 |
|
8 |
printf( '<div class="updated"> <p> %s </p> </div>', esc_html__( 'This is a yellow notice', 'plugin_domain' ) ); |
9 |
|
10 |
printf( '<div class="error"> <p> %s </p> </div>', esc_html__( 'This is a red error warning', 'plugin_domain' ) ); |
11 |
|
12 |
}
|
Obviamente, solo debes mostrar mensajes que sean relevantes, lo que significa mostrar tus avisos condicionalmente solo en ciertas pantallas, y para ciertos usuarios. Para ello puedes usar get_current_user_id() y get_current_screen():
1 |
function wptuts_admin_notices() { |
2 |
|
3 |
// Display notice if user has '_wptuts_display_notice' stored and on screen with id 'portfolio'
|
4 |
$screen_id = get_current_screen()->id; |
5 |
$display_notice = get_user_meta( get_current_user_id(), '_wptuts_display_notice', true ); |
6 |
|
7 |
if ( $display_notice && 'portfolio' == $screen_id ) { |
8 |
// Display notices
|
9 |
}
|
10 |
|
11 |
}
|
En el caso de las notificaciones persistentes, debes incluir un enlace de desestimación que permita al usuario ocultar el mensaje. Como el siguiente ejemplo:
1 |
/* Conditionally display notice */
|
2 |
add_action( 'admin_notices', 'wptuts_persistant_notice' ); |
3 |
function wptuts_persistant_notice() { |
4 |
|
5 |
/* Check that the user hasn't already clicked to ignore the message */
|
6 |
if ( ! get_user_meta( get_current_user_id(), '_wptuts_hide_notice', true ) ) { |
7 |
|
8 |
printf( '<div class="updated"> <p> %1$s | <a href="%2$s"> %3$s </a> </p> </div>', __( "This is a persistent notice. To hide it click 'dismiss'", 'plugin_domain' ), esc_url( add_query_arg( 'wptus_nag', wp_create_nonce( 'wptus_nag' ) ) ), __( 'Dismiss', 'plugin_domain' ) ); |
9 |
}
|
10 |
}
|
11 |
|
12 |
/* Hide notice */
|
13 |
add_action( 'admin_init', 'wptuts_hide_notice' ); |
14 |
function wptuts_hide_notice() { |
15 |
if ( ! isset( $_GET['wptus_nag'] ) ) { |
16 |
return; |
17 |
}
|
18 |
|
19 |
// Check nonce
|
20 |
check_admin_referer( 'wptus_nag', 'wptus_nag' ); |
21 |
|
22 |
// updated user meta to indicate dismissed notice
|
23 |
update_user_meta( get_current_user_id(), '_wptuts_hide_notice', 1 ); |
24 |
}
|
También puedes usar el ajax para desestimar los avisos de la administración, pero también debes proporcionar un respaldo que no sea de JavaScript.
Botones
WordPress proporciona el estilo para dos "tipos" de botones: "primarios" y "secundarios". El primero aparece como un botón azul y solo debería haber uno de estos botones en una página determinada. El botón secundario es un botón blanco. WordPress proporciona un par de funciones de ayuda para crear botones: funciones get_submit_button() / submit_button().
1 |
submit_button( |
2 |
__( 'Submit text', 'plugin_domain' ), |
3 |
'primary', |
4 |
'submit'
|
5 |
);
|
Enlaces
Las acciones que son "destructivas", por ejemplo un enlace que borra algo, deben ser rojas. A menudo hay clases que puedes usar (como trash) que harán esto por ti. Para otros enlaces, WordPress establece automáticamente los colores y esto no debe ser anulado.
Los enlaces en las tablas (como la tabla de entradas) deben filtrar la tabla, y no redirigir al usuario. La excepción son los "enlaces de acción", que aparecen cuando se pasa el cursor por encima de una fila (por ejemplo, los enlaces "editar" y "basura").
Iconos de la pantalla y del menú
Puedes (y debes) usar los iconos de las páginas en tus páginas de administración. Lo ideal sería que fueran personalizados (evitar la reutilización de los mismos iconos para fines diferentes). Para cambiar el icono de un tipo de mensaje personalizado puedes (condicionalmente) imprimir CSS en el cabezal de administración para anular la imagen del icono por defecto.
Debes asegurarte de que solo lo haces para las páginas de tu post-type, para no anular los iconos de otras páginas. Aquí hay un ejemplo de cómo:
1 |
<?php
|
2 |
// Add screen icon
|
3 |
add_action( 'admin_head', 'wptuts_event_screen_icon' ); |
4 |
function wptuts_event_screen_icon() { |
5 |
$post_type = get_current_screen()->post_type; |
6 |
|
7 |
if ( 'event' == $post_type ) { |
8 |
?>
|
9 |
<style type="text/css"> |
10 |
#icon-edit { |
11 |
background: url(<?php echo plugin_dir_url(__FILE__ ); ?>css/images/icon-32.png); |
12 |
}
|
13 |
</style>
|
14 |
<?php
|
15 |
}
|
16 |
}
|
17 |
?>
|
Para las páginas de administración personalizadas también puedes usar screen_icon(). Esto imprime el HTML para los iconos de la pantalla. Requiere un argumento (opcional): una cadena (utilizada en el atributo ID del contenedor de iconos) o un objeto de pantalla que se utiliza para crear un atributo ID apropiado. Por ejemplo: screen_icon('myplugin'); imprimirá algo como:
1 |
<div id="icon-myplugin" class="icon32"> |
2 |
<br /> |
3 |
</div> |
Usando el gancho admin_head como arriba, puedes apuntar a #icon-myplugin y proporcionar una imagen de fondo.
En el caso de los tipos de correo personalizados, el menú se puede especificar cuando se registra el tipo de correo:
1 |
register_post_type( 'event', array( |
2 |
...
|
3 |
'menu_icon' => plugin_dir_url( __FILE__ ) . 'css/images/icon-32.png'; |
4 |
...
|
5 |
));
|
Para las pestañas añadidas al menú usando add_menu_page puedes especificar el icono como uno de los argumentos:
1 |
add_menu_page( |
2 |
__( 'Page title', 'plugin_domain' ), // Used for the title tags of the page |
3 |
__( 'Page title', 'plugin_domain' ), // Page as it appears on the menu |
4 |
'manage_options', // Capabilities to access this page |
5 |
'wptuts_custom_page_callback', // Callback which prints the content of the page |
6 |
plugin_dir_url( __FILE__ ) . 'css/images/icon-32.png' |
7 |
);
|
Los iconos de la pantalla y del menú deben ser en escala de grises. Un colorido icono del menú sobresale más obviamente, y se ve "raro" por decir lo menos. Independientemente de lo bueno que sea el icono, arruina la estética de la barra lateral de administración. Peor aún, un colorido icono de menú me dice que no te preocupa "jugar limpio" con la interfaz de usuario de WordPress, así que voy a sospechar que el código del plugin tampoco "juega limpio" con WordPress.
Recuerda que el icono de la pantalla debe funcionar bien en tres fondos diferentes:
Pestañas de ayuda
Siempre es una buena idea dar a tus usuarios una guía extra en caso de que la necesiten. Sin embargo, incluirlo en la página puede introducir desorden, (y el texto de ayuda nunca es una alternativa al diseño intuitivo de la interfaz de usuario). WordPress te permite añadir contenido a la pestaña de "ayuda" que aparece en la parte superior derecha de la pantalla. (Las opciones de pantalla y las pestañas de ayuda a menudo pueden ser pasadas por alto por los usuarios, sin embargo hay discusiones tempranas sobre cómo mejorarlas. Por favor, ten en cuenta que solo se trata de discusiones y que no se ha decidido nada).
La capacidad de añadir "ayuda contextual" existe desde el 2.7, pero desde el 3.3 la pestaña de ayuda se renovó un poco, introduciendo una barra de ayuda con pestañas.


Puedes añadir tu propia pestaña con el siguiente código. Es importante que solo añadas la ayuda contextual en las pantallas apropiadas. También debes comprobar que el método WP_Screen::add_help_tab existe, ya que de lo contrario las versiones anteriores a la 3.3 de WordPress arrojarán un error fatal.
1 |
add_filter( 'contextual_help', 'wptuts_contextual_help', 10, 3 ); |
2 |
function wptuts_contextual_help( $contextual_help, $screen_id, $screen ) { |
3 |
|
4 |
// Only add to certain screen(s). The add_help_tab function for screen was introduced in WordPress 3.3.
|
5 |
if ( $screen_id != 'screen_id' || ! method_exists( $screen, 'add_help_tab' ) ) |
6 |
return $contextual_help; |
7 |
|
8 |
$screen->add_help_tab( array( |
9 |
'id' => 'wptuts-overview-tab', |
10 |
'title' => __( 'Overview', 'plugin_domain' ), |
11 |
'content' => '<p>' . __( 'Some help text here', 'plugin_domain' ) . '</p>', |
12 |
));
|
13 |
return $contextual_help; |
14 |
}
|
Tablas
Cuando se usan tablas en el lado del administrador de tu plugin es casi siempre mejor usar el mismo estilo que WordPress usa para sus tablas. El diseño y la apariencia son ideales para presentar datos como ventas de productos, registros de actividad, etc., proporcionando a sus usuarios una interfaz coherente. Lo importante es que los usuarios esperarán instintivamente que al pasar el cursor sobre una fila se revelen los "enlaces de acción", y que los enlaces de las columnas filtren la tabla. No tengas miedo de adaptar tu tabla a tus necesidades específicas (cambiar el ancho de las columnas, personalizar el estilo de las imágenes de la columna, etc.), pero es importante presentar tus datos de una manera que sea ampliamente familiar e intuitiva para tus usuarios.
La forma más fácil de replicar la tabla de administración de WordPress es extendiendo la clase WP_List_Table. Hay numerosos artículos que explican cómo hacerlo, pero el mejor "tutorial" es el plugin Custom List Table, que te proporciona un ejemplo trabajado y está increíblemente bien comentado. Sin embargo, se advierte que aunque el Codex dice que la clase WP_List_Table es adecuada para ser extendida por los desarrolladores, el código fuente actual marca esta clase como 'Privada'. Potencialmente, WordPress podría cambiar la clase, y si tales cambios ocurren, tendrás que comprobar que no rompen tu tabla.
jQuery Estilo de interfaz de usuario
Toda la interfaz de jQuery se proporciona en WordPress (y si tu plugin utiliza alguno, debes utilizar los scripts proporcionados por WordPress). Desafortunadamente, no hay necesariamente los correspondientes estilos CSS. Esto se deja actualmente para que lo proporcionen los plugins. Sin embargo, hay un potencial para que esto cambie con este billete de Trac. Helen Hou Sandi, desarrolladora principal de WordPress, ha trabajado en dos temas de la interfaz de usuario de jQuery que complementan a WordPress (uno para cada esquema de color del administrador). No hay garantía de que esto llegue a WordPress, pero en cualquier caso, debes descargar ambos temas y usarlos con tus plugins.
Un plugin de demostración puede ser descargado aquí. De eso también se pueden extraer los dos temas:
- jquery-ui-fresh.css (el esquema de color gris por defecto)
- jquery-ui-classic.css (el esquema de color azul)


Colócalos en tu carpeta de plugins. Cuando registres los scripts, utiliza el tema seleccionado por el usuario:
1 |
add_action( 'wp_enqueue_scripts', 'wptuts_register_scripts' ); |
2 |
function wptuts_register_scripts() { |
3 |
|
4 |
if ( 'classic' == get_user_option( 'admin_color' ) ) { |
5 |
wp_register_style ( 'wptuts-plugin-jquery-ui-css', plugin_dir_url( __FILE__ ) . 'jquery-ui-classic.css' ); |
6 |
} else { |
7 |
wp_register_style ( 'wptuts-plugin-jquery-ui-css', plugin_dir_url( __FILE__ ) . 'jquery-ui-fresh.css' ); |
8 |
}
|
9 |
|
10 |
}
|
Entonces puedes llamar a wp_enqueue_style( 'wptuts-plugin-jquery-ui-css' ) donde lo necesites (obviamente, debes darle a los estilos un mango diferente, único para tu plugin). Esto por sí solo puede ayudar mucho a dar a tu plugin una apariencia consistente con WordPress.
*Si llega a WordPress, entonces puedes quitar lo anterior de tu plugin y usar el estilo proporcionado por WordPress en su lugar.
Pensar fuera de la caja
No todo el contenido de WordPress es una publicación, un comentario o un archivo adjunto y, a veces, la interfaz de usuario existente no proporciona lo que necesitas. En estos casos no es apropiado imponerle las estructuras "post" que existen nativamente. Por ejemplo, Gravity Forms es un plugin que te permite añadir y administrar formularios en tu sitio. Si se restringieran a la interfaz de usuario nativa de WordPress, presentando los formularios casi como entradas, por ejemplo, el resultado sería una peor experiencia para el usuario y menos ventas para los formularios de gravedad.
Darle a tus usuarios el mejor UX no es simplemente poner todo dentro de listas y metaboxes. Si tu plugin necesita presentar la información de una manera que es ajena a la interfaz de usuario nativa de WordPress, siéntete libre de ser creativo y experimentar. Pero, ¿cómo se traza la línea entre ser creativo e integrarse con la interfaz de usuario de WordPress? Esto fue algo que salió a relucir en los comentarios del post de Tom mencionado anteriormente. La verdad es que se trata de un juicio personal y de experimentar para ver qué funciona. Las formas de gravedad, en general, hacen esto bien:


Es importante, aunque la interfaz de usuario de WordPress puede no proporcionar precisamente lo que necesitas, hay mucho en lo que inspirarse. Por ejemplo, si quieres que tus usuarios puedan arrastrar y soltar elementos, puedes consultar la página de menús para obtener orientación. No deberías descartar por completo la interfaz de usuario de la administración. Algunos "principios" de la interfaz de administración (algunos listados arriba) son traducibles independientemente de lo que se intente conseguir, como por ejemplo: el uso del color, los enlaces, los botones y los iconos. Y los detalles importan, conseguir los gradientes, el radio y el tipo de letra correctos son importantes para mantener la coherencia, sobre todo cuando se hace algo "diferente". Para el ejemplo de arrastrar y soltar, puede que quieras reutilizar el marcador de posición gris con un borde punteado.
Esta atención a los detalles puede parecer difícil, pero hacerlo bien es en realidad lo más perezoso (y en este caso, lo más apropiado) que se puede hacer. WordPress añade mucho estilo a la página de administración, y en su mayor parte esto será heredado automáticamente por tu plugin. En otros casos es solo cuestión de añadir las clases adecuadas a tus elementos.
Conclusión
Los siguientes artículos de esta serie serán mucho más "prácticos", pero esperamos que este artículo haya ilustrado algunos pasos inmediatos y fáciles para proporcionar a tus usuarios una administración más consistente. Las directrices enumeradas aquí no son de ninguna manera oficiales, y tampoco son exhaustivas, ¡y me gustaría que se discutieran y se hicieran sugerencias!



