Hola.
He leído varios temas aquí sobre la organización de categorías y etiquetas, pero no he logrado encontrar una estructura que se adapte a mis necesidades.
Básicamente, es un foro de soporte que cubre muchos productos. Hay quizás entre 50 y 100 productos diferentes, agrupados en unas 5 a 10 “departamentos”.
También me gustaría diferenciar los permisos para clientes y no clientes. Esto significa que los no clientes tendrán acceso de lectura y escritura solo al soporte “estándar”, y acceso de lectura al soporte “VIP”, mientras que los clientes tendrán acceso de lectura y escritura a ambos.
Además, me gustaría utilizar el sistema de votación para crear un mecanismo de “solicitud de funciones” que permita a los usuarios solicitar características y votar (para cada producto). Nuevamente, solo los clientes podrán solicitar funciones y votar; los usuarios solo podrán votar en las solicitudes de funciones, no en otros temas, y por supuesto, todos (personal y usuarios) deberán poder ver fácilmente las funciones más solicitadas.
¿Cuál es la mejor opción? Al principio pensé en usar una cantidad enorme de categorías:
DepartamentoA
Producto1
Solicitudes de funciones
VIP
Producto2
Solicitudes de funciones
VIP
DepartamentoB
Producto3
Solicitudes de funciones
VIP
Producto4
Solicitudes de funciones
VIP
Pero parece que son demasiadas categorías.
Las etiquetas parecen ayudar en este caso, pero ¿cómo podrían usarse, aplicarse, filtrarse y asignarse permisos?
Una desventaja importante que veo en las etiquetas (además de lo relacionado con los permisos) es que en cada foro de Discourse que visito y que sirve como “ejemplo” de uso de etiquetas (como el de Car Talking, pero hay otros), al final parece que las etiquetas simplemente no se utilizan. Muy pocos temas están etiquetados y todo termina en el mismo lugar.
No estoy seguro de si esto se ajustará a tus necesidades, pero lo compartiré con la esperanza de que algún fragmento pueda ayudarte.
Recientemente mudamos nuestra comunidad de 16 años de SMF a Discourse. Nuestra base de usuarios estaba muy contenta con capas de categorías, subcategorías y tableros hijos sin fin. Era realmente ridículo cuántos teníamos.
Los nuevos usuarios se perdían tanto en el laberinto.
Desde que nos mudamos a Discourse, ahora tenemos Categoría > Subcategoría > Etiquetas. Las etiquetas han reemplazado a los 9172816 tableros hijos que solíamos tener.
Hice obligatorio usar una etiqueta para publicar un tema, y solo pueden elegir entre las etiquetas que he creado para cada categoría.
Configura la opción de la categoría en “Número mínimo de etiquetas requeridas en un tema: 1”.
Crea grupos de etiquetas para cada categoría + desmarca “También permitir otras etiquetas” en la configuración de la categoría:
Abrimos las puertas en Año Nuevo, así que aún es un trabajo en progreso, pero aquí puedes ver mis agrupaciones de etiquetas. the Lettuce Craft Forums
En el flujo de creación de temas, se requiere que el usuario seleccione 1 etiqueta como mínimo/máximo. Personalicé el texto a “Ahora selecciona 1 etiqueta (subcategoría)”. Soy consciente de que una etiqueta no es realmente una subcategoría, pero este es el lenguaje que necesitamos usar por ahora para enseñar a nuestra comunidad de perros viejos/nuevos trucos.
Ustedes dos han convertido este tema en algo que parece el inicio de un tutorial gracias a sus publicaciones claras e informativas.
He redactado esta respuesta extensa porque he estado reflexionando sobre cómo abordar la configuración de nuevos foros. Así que pensé en experimentar con tu problema para ver si podía preparar algo y comprobar si te resulta útil.
Estoy de acuerdo en considerar el uso de etiquetas en lugar de agrupar todo en categorías, que es lo que hago yo mismo en algunos foros privados. Pero debes tener en cuenta que, actualmente, las categorías tienen dos ventajas claras:
Las categorías son esenciales para controlar el acceso
Los complementos (plugins) permiten una personalización mucho mayor de las categorías
El problema clave aquí es cuáles de tus requisitos deben gestionarse como categorías en lugar de etiquetas. Pero no tenemos que decidirlo de inmediato. Diseñamos las categorías, que son características pesadas, y luego vemos qué se puede convertir en etiquetas.
El proceso de toma de decisiones
Hay más de una forma de abordar el diseño de tus categorías. Cuando no se consideran las etiquetas como el mecanismo principal, yo seguiría este orden:
¿Qué categorías son necesarias?
¿Qué categorías requieren controles de acceso de usuario separados?
¿Necesito ahora las categorías predeterminadas?
Aquí se sigue una ruta diferente a la que normalmente se usaría porque puedes ver las categorías predeterminadas mínimas que podrían permitirte hacer todo lo demás con etiquetas.
¿Necesito las categorías predeterminadas?
¿Qué categorías requieren controles de acceso de usuario separados?
¿Qué otras categorías son necesarias que no requieran controles de acceso de usuario?
A. ¿Cuál es el requisito general?
Primero, ¿cuál es la justificación de la comunidad que se utilizará para desarrollar la estructura del foro? La comunidad y el foro son cosas diferentes.
Basándome en tu primera publicación, puedo decir que tienes los siguientes requisitos para tu comunidad:
El propósito principal es el soporte
El soporte está impulsado por el producto, es decir, sin productos no hay clientes ni soporte requerido.
El soporte se segmenta por estado del cliente, es decir, cliente frente a no cliente.
El producto tiene una solicitud de función adicional, tanto de clientes como de no clientes.
Los requisitos adicionales para el foro son que:
El departamento gestiona el producto, pero el cliente/usuario interactúa a través del producto.
Notas:
El soporte podría ser gestionado por el departamento, pero los clientes/usuarios probablemente se relacionan con los productos que utilizan. Por lo tanto, no complicaría el foro incluyendo la estructura de tu organización, a menos que tus departamentos sean marcas o empresas subsidiarias con las que los clientes y usuarios casi exclusivamente se identificarán en sus interacciones normales.
Uso Cliente aquí porque debería haber una advertencia sobre el uso de VIP. Esto elimina la opción de crear un subgrupo de VIP de clientes más adelante. He visto este problema antes en un foro para profesionales de la comunidad, por lo que reservaría VIP para una segmentación posterior.
B. ¿Cuáles son las categorías mínimas para lograr el requisito general?
1. ¿Necesito las categorías predeterminadas?
Considero que todas las categorías predeterminadas son esenciales, pero quizás tú no. Solo ten en cuenta que las predeterminadas se establecen con mucha consideración por los requisitos del propietario promedio de un foro y de los usuarios del foro:
#lounge
Por defecto, esto es para usuarios de Nivel de Confianza 3 (TL3). Sugiero que lo mantengas como una ventaja para tus no clientes más activos. Podrías sentirte tentado a usarlo para tu categoría VIP renombrándolo y reduciendo el TL mínimo para acceder a él. No lo hagas: mantén tu grupo VIP y su categoría separados de los grupos y categorías predeterminados.
#staff
Para administradores y moderadores, por lo que no es visible para la mayoría de los usuarios.
Uncategorized
La configuración predeterminada es allow uncategorized topics (permitir temas sin categoría).
Quizás quieras deshabilitar la configuración suppress uncategorized badge (suprimir insignia de sin categoría) para hacer que estos temas sean más visibles en las listas de temas, de modo que sea más probable que se asignen a una categoría más relevante.
Esto implica un poco más de trabajo para los moderadores y los usuarios con TL alto, pero facilita mucho a los nuevos usuarios que no pueden decidir en qué categoría publicar.
Esta categoría es la shared drafts category (categoría de borradores compartidos) predeterminada, que es otra razón para mantenerla.
Ejemplo
En este punto, tus categorías mínimas serían:
Lounge
Site Feedback
Staff
Uncategorized
2. ¿Qué categorías necesitan controles de acceso de usuario?
El único requisito definitivo es que:
El soporte se segmenta por estado del cliente, es decir, cliente frente a no cliente.
Quieres separar a los usuarios y a los clientes, por lo que las categorías deben usarse para esto. Cualquier otro método será muy doloroso.
Esto significa que necesitas que los clientes y los no clientes estén en un Grupo separado, con al menos una categoría donde:
Los clientes tengan acceso CRS (Crear, Leer, Ver)
Los no clientes tengan solo acceso S (Ver).
Ejemplo
En este punto, tus categorías mínimas serían:
Customer (Cliente)
Lounge
Site Feedback
Staff
Uncategorized
3. ¿Qué otras categorías son necesarias que no requieran controles de acceso de usuario?
Tus requisitos son:
El soporte está impulsado por el producto
El producto tiene una solicitud de función adicional
Incluso sin tus requisitos, la estructura hasta ahora parece decididamente inadecuada porque no está claro dónde poner las solicitudes de soporte de producto. Por lo tanto, necesitas al menos una categoría de soporte de producto, lo que luego requiere una subcategoría Customer (Cliente). Dejaría una categoría Customer de alto nivel como un lugar para abordar problemas que solo se comparten y probablemente solo son visibles para los clientes.
Puedes clasificar las solicitudes de funciones de producto utilizando el complemento Feature Ranking. Esto funciona clasificando los temas en una categoría, por lo que necesitas al menos una categoría. Luego, podrías tener dos opciones para mostrar las clasificaciones por producto:
Una categoría con vistas filtradas por una etiqueta de producto. Por lo que sé, esto podría ser un impedimento ahora, pero no lo he probado.
Una subcategoría Feature Request (Solicitud de función) por categoría Product (Producto)
Independientemente de la opción elegida, será más fácil colocar los temas Feature Request en una subcategoría.
Ejemplo sin categorías Product individuales
En este punto, tus categorías mínimas serían:
Customer
Lounge
Site Feedback
Staff
Support (Soporte)
Customer
Feature Request
Uncategorized
Ejemplo con categorías Product individuales
En este punto, tus categorías mínimas serían:
Customer
Lounge
Product 1
Customer
Feature Request
…
Product 100
Customer
Feature Request
Site Feedback
Staff
Uncategorized
Ahora surge la pregunta sobre la relación entre los productos y quienes los utilizan.
Issue
Una Categoría para Support
Una Categoría para cada Product
¿La mayoría/todos los clientes usan la mayoría/todos los productos?
Sí
No
¿La mayoría/todos los clientes se relacionan con productos individuales?
No
Sí
¿Cuál tiene mejor soporte en el núcleo de Discourse?
Las etiquetas son más limitadas
Las categorías tienen mejor soporte
¿Cuál tiene mejor soporte en los complementos?
Las etiquetas son más limitadas
Las categorías tienen mejor soporte
Gestión de categorías más fácil
Sí
No
Gestión de vistas e informes más fácil
No
Sí
Más fácil para un nuevo usuario de Discourse
No
Sí
En balance, creo que deberías optar por categorías individuales para cada producto, ya que funcionará y las principales desventajas son la vista larga de categorías y un período aburrido dedicado a configurar los detalles de las categorías y subcategorías, así como el acceso de los grupos.
Ejemplo con categorías Product individuales (como se muestra arriba)
En este punto, tus categorías mínimas serían:
Customer
Lounge
Product 1
Customer
Feature Request
…
Product 100
Customer
Feature Request
Site Feedback
Uncategorized
4. ¿Qué otras categorías podrían ser útiles?
Estoy seguro de que eres consciente de otras categorías que quizás quieras y que no has especificado aquí, por ejemplo:
Documentos de la empresa, por ejemplo, términos y condiciones genéricos para todos los clientes y productos
Documentos del producto, por ejemplo, documentos relacionados con el producto
Descargas, por ejemplo, software relacionado con el producto, como versiones antiguas del propio producto de software
Tutoriales de Cómo hacerlo
Preguntas frecuentes (FAQs)
C. ¿Qué características deberían ser etiquetas?
En cuanto a qué etiquetas deberías usar, necesitaría más información, por ejemplo, sobre cómo los departamentos gestionan el soporte.
Al principio, dejaría fuera el Departamento de tu foro porque puedes desarrollar informes basados en Product con resúmenes por Departamento que no necesitarían ninguna etiqueta visible.
Te remito a temas existentes aquí para darte una idea de lo que se puede hacer con las etiquetas en un foro de soporte. Estos temas son de los más recientes a los más antiguos:
Gracias a ambos, @soraiden y @Remah, por las respuestas tan detalladas. Realmente lo aprecio.
Aún no he decidido, sin embargo. Es realmente difícil.
Las sugerencias de @Remah parecen más adecuadas para mi situación, pero cuando dices: «entonces tendrás Documentación, HowTo, FAQs, etc.», ¿no estarán también relacionadas con los productos?
Esto aumenta la sensación de que los productos deberían ser etiquetas; de lo contrario, tendré que seguir duplicando subcategorías en todas partes (como las sugeridas «Clientes» y «Solicitudes de características»).
Por otro lado, es deseable que cada cliente tenga un acceso diferente según el producto, ya que, de hecho, Cliente1 podría haber registrado ProductoA, mientras que Cliente1 podría haber registrado ProductoB, y son diferentes. Aunque podría vivir sin esto, si realmente es necesario.
También tengo miedo de configurar las cosas basadas en etiquetas solo para descubrir más tarde que alguna característica clave solo está disponible para categorías y no para etiquetas…
Una cosa que no entendí de la sugerencia de @Remah: ¿por qué necesitaría una categoría de nivel superior «Cliente» y luego una subcategoría «Cliente» dentro de cada producto?
Pero, de nuevo, muchas gracias por la respuesta tan detallada y organizada.
¿Cuál es su plazo para poner en marcha este foro? Si es corto y limitado en el tiempo, es posible que no haya oportunidad de experimentar con las etiquetas.
Por cierto, mientras prueban cosas, pueden configurar tanto etiquetas como categorías simultáneamente. No importa si la estructura de etiquetas duplica la de categorías. Si utilizan categorías, las etiquetas no serán necesarias, por lo que simplemente no se verán, ya que nadie tendrá que usarlas.
Ese es el problema que también me preocupa. Mi corazón dice que prueben con etiquetas, pero mi cabeza dice que aún no están del todo listas. Ya identifiqué un posible obstáculo con las etiquetas: la en mi publicación anterior sobre el filtrado por etiquetas que no funciona con el complemento Feature Ranking. Sin embargo, el equipo de Discourse está motivado para habilitar un uso intensivo de etiquetas, por lo que podrían ver oportunidades para desarrollar nuevas funciones que ayuden.
Pueden comenzar a desarrollar la estructura del foro usando etiquetas en lugar de categorías. Si no pueden lograr lo que desean en este momento, su alternativa sería crear todas las categorías y subcategorías de productos.
Asegúrense de registrar todo lo que no puedan hacer o no entiendan. Luego, regresen a este foro con esos problemas y soliciten soluciones.
Las categorías son muy visibles y existen independientemente de los temas, mientras que la estructura de etiquetas no es tan visible y las etiquetas solo existen cuando hay temas que las utilizan. Por lo tanto, para llenar el foro con las etiquetas que desean usar, necesitarán tener temas de “ejemplo” que las utilicen, por ejemplo, un tema de lista de productos.
Una ventaja adicional de las etiquetas es que pueden crear grupos de etiquetas, de modo que sus productos puedan agruparse bajo grupos de etiquetas para sus departamentos. Los grupos de etiquetas departamentales no tendrán que agregarse a los temas, ya que agregar la etiqueta de producto a un tema asociará indirectamente el grupo de etiquetas con ese tema. Por lo tanto, las etiquetas ofrecerán algunas opciones únicas que no implementarían con categorías.
Sí, diría que es muy probable. Pero deben trabajar en el proceso de decidir los pros y contras de cada opción.
Si tienen una subcategoría Cliente para cada producto, ¿dónde colocarán los temas que se relacionan con todos los clientes pero no con todos los usuarios? No necesita ser una categoría separada, pero vale la pena pensar en lo que podrían necesitar o aprovechar para hacer cosas nuevas.
Un nuevo foro es una oportunidad para adoptar nuevas formas de hacer las cosas.
Por lo que sé, esto