No puedo resolver dos cosas:
¿Alguien más ha experimentado este problema?
Es posible, pero tenemos un caso especial que lo hace más complicado que una simple integración. El selector de categorías solo permite agregar categorías existentes… pero actualmente permitimos una entrada personalizada @ para aplicar el componente a la vista de nivel superior “todas las categorías”.
Tendremos que dividir eso en una configuración separada y migrar las configuraciones existentes para poder usar el menú desplegable de categorías.
¿Esta pestaña?
No puedo reproducir el problema, es posible que ya se haya solucionado; si todavía lo encuentras, háznoslo saber.
Lo siento, desde entonces dejé Discourse y volví a llevar mi comunidad a Discord.
[cita=“awesomerobot, publicación:3, tema:366791”]
El selector de categorías solo permite agregar categorías existentes… pero actualmente permitimos agregar una entrada personalizada @ para aplicar el componente a la vista general de “todas las categorías”.
[/cita]
Esto es increíblemente confuso. ¿Podrías explicar qué significa el “@” y cómo usarlo? Lo he visto en la interfaz de configuración de Kanban y no conseguí entender qué hace.
Además, ¿por qué tener un “@” personalizado hace que sea imposible usar el menú desplegable? Solo agrega la entrada “@” al desplegable, ¿no funcionaría eso? Y aún mejor, ¿por qué llamarlo “@”? Pon “Todas las categorías” en ese desplegable, y haz que use el “@” en segundo plano. Resultó ser demasiado críptico incluso para mí, un desarrollador de software, que también ha usado Discourse desde sus inicios.
Esto está obviamente fuera de tema, pero me gustaría añadir mi opinión y decir que las frustraciones duraderas con la interfaz de usuario de Discourse hacen que no tenga éxito en reclutar a mis socios y partes interesadas del proyecto para que usen Discourse. Todos odian la interfaz de usuario, simplemente no pueden usarla porque es confusa por todos los medios, y esta incapacidad para configurar Kanban como una herramienta útil solo aumenta la frustración de esos socios a quienes estoy tratando de convencer para que se unan al uso de Discourse para la gestión de proyectos. Para volver al problema real discutido en este tema, ¿cómo demonios debería explicar el “@” a un gerente que solo quiere abrir el panel de configuración y configurar las listas de kanban a su gusto? Son todas estas pequeñas cosas las que se suman y hacen que las personas se desorienten por completo al ingresar al espacio de Discourse, y tratan de irse de inmediato y me piden que no interactúe con ellos en esta plataforma porque les hace perder el tiempo. Estoy indefenso para entusiasmar a la gente con Discourse. Y para empeorar las cosas, por alguna razón, el equipo de Discourse empeora algunos aspectos de la interfaz de usuario en lugar de mejorarlos, vea una actualización reciente aquí y mi crítica de ella: Now that the topic title is editable by click, I can't simply copy it without entering the edit mode
Por cierto, si ingreso allí @MiCategoría (lo cual hice intuitivamente mientras intentaba entender qué hace el “@”), no me dice ningún error de validación. ¿Cómo se considera aceptable no decirme que estoy haciendo algo incorrectamente cuando es obvio desde la perspectiva del programador, y se puede detectar fácilmente al “Guardar…” el valor de configuración actualizado?
Lamento tener que decirlo todo, especialmente después de ver que alguien dejó Discourse y regresó a Discord, lo que solo confirmó mis preocupaciones y frustraciones con la interfaz de usuario.
Realmente me esforcé, pero hay demasiada complejidad. Es como en los viejos tiempos: las guerras de Android contra iPhone.
Android te permitía personalizar lo que quisieras.
iPhone era súper limitado, pero… simplemente funcionaba.
Este es el mismo caso con Discourse en este momento. Creo que debemos tomar más el camino de Antoine de Saint-Exupéry: “La perfección se logra, no cuando no queda nada más que añadir, sino cuando no queda nada que quitar”.
Hay tanta confusión (como DMs frente a chats privados, por nombrar el primero que se me ocurre) que es realmente difícil convencer a la gente de que lo use libremente. En Discord, hay menos fricción. Lo mismo ocurre con Skool. Creo que esto es lo que deberíamos intentar lograr, no añadir más funciones.
Recientemente, un cliente dejó Discourse exactamente por la razón que mencionas: demasiada complejidad.
Pero, para ser honesto, mirando algunos servidores de Discord, no diría que sean en absoluto simples. Hay mucho que puedes añadir ahora a un servidor de Discord (incluyendo bots).
Una gran desventaja de cambiar a Discord o a cualquier aplicación personalizada cerrada es que pierdes SEO, ¿no? Quizás eso no te afecte.
Quien lo implementó eligió “@” como un símbolo único para representar las listas de temas de nivel superior cuando no se filtran por categoría o etiqueta. Esto es como forum.example.com/latest o forum.example.com/top. Por lo tanto, ingresas “@” por separado como su propia entrada para aplicarlo allí.
Estoy de acuerdo en que esto es confuso, pero es algo que se puede ignorar a menos que quieras tableros kanban globales.
No lo hace, simplemente complica la transición al menú desplegable de categorías porque también tenemos que crear una migración para no revertir la configuración en los sitios que ya la están utilizando de esta manera.
La configuración del tema está dictada por las API principales, por lo que cuando usamos el tipo de lista de categorías, no podemos extenderlo con opciones adicionales del tema en sí.
Discourse no es una empresa masiva, tenemos limitaciones de tiempo para centrarnos en las funciones más utilizadas y la refactorización de componentes (que se ofrecen sin costo alguno, por cierto) puede ser difícil de priorizar. Si alguien quiere patrocinar mejoras en la configuración de kanban, ciertamente podemos darle una mayor prioridad.
¿Discord tiene una función de tablero kanban disponible? Busqué pero no pude encontrar mucho aparte de un bot que se integra con un servicio kanban externo.
También pierdes algo de control, tus usuarios son usuarios de Discord, el contenido que publican también es contenido de Discord. Cuando alguien paga por Discord, el beneficio es de Discord. Hay compensaciones y costos para cada plataforma.
Sí, no está claro cuándo estaremos en posición de prestar atención a la función de Kanban en este momento.
Es algo que me gustaría revisar en algún momento. Creo que la adopción del componente de tema ha proporcionado cierta evidencia de que hay un deseo de más de este tipo de cosas ahí fuera.
Implementarlo como un componente de tema ha tenido ventajas: es relativamente fácil para cualquier administrador encontrarlo e instalarlo, pero también viene con algunas limitaciones significativas que dificultan su diseño de la manera que uno podría esperar.
Si y cuando lo revisemos, creo que hay dos caminos posibles que tomaremos: podríamos usar el conjunto de funciones deseado para un tablero Kanban como una razón para mejorar las API disponibles para los componentes de tema, o podríamos convertirlo en una función principal o un plugin y tener más acceso para agregar las API de servidor adecuadas para el propósito que necesitamos.
Hasta entonces, creo que es probable que solo reciba ajustes para problemas específicos.
[cita=“merefield, post:10, tema:366791”]
tbh, al mirar algunos servidores de Discord, no diría que sean nada simples. Hay muchas cosas que se pueden agregar a un servidor de Discord ahora (incluidos los bots).
[/cita]
Eso es cierto, pero esa carga recae en nosotros, los dueños, no en los usuarios. Los usuarios lo ven de la manera más simple:
elegir canal → enviar el mensaje ¡y eso es todo!
No hay Kanban. No es necesario comprender la diferencia entre Watching y Tracking. No hay un montón de funciones como hey-how-cool-it-would-be-if-discourse-pudiera-LOSTEDO-xyz.
Todas estas funciones son muy buenas, para nosotros, los técnicos/propietarios/admins.
Pero para la gente común, quieren sentir que forman parte de una comunidad. Quieren sentir que son libres de expresarse y no tener que entender todas esas cientos (creo que hay tantas) diferentes opciones, términos y otras cosas.
Este es exactamente el comentario que tengo de los interesados. Se pierden entre chats y temas privados.
En mi proyecto actual, el propietario del proyecto está explorando Basecamp porque dice que no puede simplemente usar Discourse después de probarlo. Estoy abogando por Discourse porque conozco sus características y capacidades sobresalientes, pero no puedo hacer mucho porque la usabilidad deficiente y un desorden tanto en la interfaz de usuario como en la terminología siempre superan la funcionalidad. Sin mencionar el Markdown que todas las personas normales y no técnicas odian, y no puedo explicarles por qué no es wysiwyg en primer lugar. Gracias a Dios, el equipo de Discourse finalmente está trabajando en el editor adecuado. La mayoría de la gente quiere un editor de texto simple similar a Word con solo unas pocas capacidades: formato, tablas, colores, imágenes, fragmentos de código. No hay razón para que algo de esto se obtenga en forma de markdown de un usuario normal. Las características más sofisticadas como la IA parecen inútiles cuando el usuario final no puede entender por qué su editor de texto de publicaciones está dividido verticalmente en dos columnas, eso es lo que piensan, no en la IA.
Tienen todos los datos. Ese es el trato, y entiendo la frustración inicial, pero veo muchas mejoras en los últimos meses en Discourse.
Los administradores pueden optar por dejar de usar chats y/o mensajes privados y simplificar. Lleva tiempo, y hay una curva de aprendizaje que todos seguramente entienden. Pros y contras como en todo.
Le deseo lo mejor al equipo, y creo que realmente necesitamos contribuir y dar tiempo al proceso de evolución natural.
Este es un comportamiento aceptable a corto plazo, pero ¿no es una dinámica muy buena para organizar la información?
Usuarios que disparan sin pensar < > un sitio web bien organizado.
¿Por eso Discourse se centra en la moderación y en herramientas para organizar las cosas?
Este es el caso exacto en el que no nos mantenemos al día con el panorama cambiante de cómo los miembros de nuestras comunidades consumen contenido.
Me enfrenté a la misma decisión. Tener algo robusto, bien organizado, con excelente SEO, algo que nos permita crear un legado dada la naturaleza del contenido que estamos creando.
Pero la gente hoy en día (y esto es obviamente una generalización) no siente que, por ejemplo, Slack esté quitando algo al limitar el historial a los últimos 90 días.
Uno de mis miembros me dijo (y es una emprendedora extremadamente exitosa que acaba de cumplir 30 años) que hoy en día, si la información tiene más de 3 meses, no la lee, ya que todo cambia tan rápido que desenterrar cosas viejas es una pérdida de tiempo. Independientemente de si se trata de negocios, ciencia o… bueno, de la vida.
Y, por supuesto, tener hilos como los que tenemos aquí sobre plugins que pueden actualizarse dentro de muchos meses, es un caso válido. pero aparte de eso, en el sentido de “construir la comunidad”, se trata más del “sentimiento de pertenencia” y de poder interactuar con esta comunidad con poca o ninguna fricción, en lugar de descifrar todas las opciones que nos abruman.
Hablé de ello en hilos anteriores, donde preguntaba sobre el éxito de Skool, en comparación con Discourse.
Entiendo esto completamente, gracias por tu perspectiva.
Para ser perfectamente claro, veo un potencial increíble en Discourse, y si alguna vez puedo servir para ayudar al equipo con mi experiencia en la construcción de comunidades, estaré feliz de ayudar.
