Aislamiento por categoría

Comunidad
,
1

Me gustaría ejecutar una única instancia de Discourse para un programa universitario, donde las diferentes categorías de nivel superior corresponden a diferentes cursos y donde el acceso se gestiona mediante grupos. Para que los instructores y alumnos del curso puedan tener una impresión coherente de un curso, me gustaría proporcionar una sensación de aislamiento de los diferentes cursos. Por lo tanto, me gustaría que mi instancia ofreciera una experiencia de navegación similar a Teams/Slack/Mattermost, donde hay equipos relativamente aislados y los usuarios necesitan cambiar de uno a otro. Para mi instancia, esto significaría que la interfaz de usuario enfatiza los datos relacionados con el curso seleccionado actualmente. Por ejemplo, los usuarios pasan la mayor parte del tiempo en una de las categorías de nivel superior, y la selección de una de ellas filtra las subcategorías y los canales de chat que pueden ver fácilmente.

Una necesidad similar surge en una instancia donde las diferentes categorías corresponden a diferentes grupos de investigación (también me gustaría ejecutar una de ese tipo).

¿Qué herramientas existentes pueden ayudar a lograr esto?

4 Me gusta
2

¡Caso de uso interesante! Una solución posible es simplemente silenciar las categorías que no están relacionadas, para que no aparezcan en las listas de temas.

3

En realidad no quiero que se silencien: es probable que un estudiante siga varios cursos a la vez y las notificaciones de todos están bien. Más bien, quiero dar una impresión más clara de “ahora estoy mirando el curso X”.

1 me gusta
4

En realidad, parece que necesitaría algo como esto

Pero con una “página de inicio” seleccionable.

5

Parece que grupo principal = inicio seleccionado, ¿no? Necesitas habilitar user_selected_primary_groups para que los usuarios puedan cambiar su grupo principal en la página de preferencias de su cuenta.

2 Me gusta
6

En el mejor de los casos, querría algo más efímero y menos visible públicamente. Sin embargo, me imagino que si no uso el título y el flair, entonces un componente de interfaz de usuario que cambie el grupo principal funcionaría como un selector de equipo.

Algo como el selector lateral adicional que se ejecutó aquí como experimento hace unos días sería genial para eso.

7

Podrías hacer eso. También podrías cambiar el logo del sitio dependiendo de su grupo principal; lo he hecho para un sitio que tiene varias universidades compartiendo una instancia. Quizás tendrías un componente temático con un menú desplegable en la barra superior que les permitiría seleccionar su grupo principal (y tal vez decir “clase” en lugar de “grupo”).

8

@Anton_Akhmerov ¿esperas hacerlo tú mismo o estarías dispuesto a pagarle a alguien para que lo haga por ti? ¡Avísame!

Si quieres hacerlo tú mismo, me gustaría mover esto a Dev para que puedas trabajar en ello allí e informar a la comunidad y recibir aportes de otros miembros. Moveré esto a Dev.

Si quieres pagarle a alguien, lo moveré a Marketplace.

9

Dev por favor :folded_hands: :smiling_face_with_sunglasses:

Además, si alguien en Dev tiene alguna indicación, sería absolutamente maravilloso :heart_eyes:

13

Creo que sería mejor mover esto a Community y discutir más sobre tu caso de uso, cómo satisfacer mejor tus necesidades hoy y dejar espacio para que otros que hayan tenido necesidades similares las hayan resuelto.

Luego, si se identifican brechas de producto específicas que consideras lo suficientemente importantes como para crearlas tú mismo o abogar por ellas, podemos crear temas separados en Feature y/o Dev para estas ideas.

¿Suena alineado con tu pensamiento aquí? ¿O ya estás en la fase de “Estoy listo para construir las piezas que faltan”?

1 me gusta
14

#comunidad también tiene sentido :grin:. La función parece complicada y parece estar algo alineada con las necesidades de la comunidad, considerando la popularidad de solicitudes como esta

Tengo la intención de trabajar en esto, pero hasta ahora mi plan es bastante vago.

2 Me gusta
15

Como seguimiento, aquí explico cómo imagino que se satisfacen mejor sus necesidades con las funciones listas para usar de Discourse. Puede que no sea exactamente lo que tiene en mente, pero creo que vale la pena considerarlo como punto de partida para la discusión.

Primero, hago algunas suposiciones, que pueden ser válidas o no. Por favor, hágame saber dónde me equivoco:

  1. Habrá muchos cursos (decenas, posiblemente cientos).
  2. La configuración de los cursos ocurrirá periódicamente, en lotes considerables, al comienzo de cada trimestre (2-4 veces al año).
  3. Los cursos tendrán una fecha de finalización.
  4. Las personas que administran los cursos necesitan tener cierta capacidad para configurarlos por sí mismas.
  5. Las personas que administran los cursos tendrán poca o ninguna experiencia en la gestión de un sitio de Discourse.
  6. Las personas que administran los cursos solo necesitan ver los suyos. Es posible que deseen ver otros ocasionalmente como ejemplos, pero no necesitan participar continuamente en ellos.
  7. ^ lo mismo para las personas que toman cursos.
  8. Hay un equipo muy pequeño que administra el sistema en su conjunto.
  9. Los cursos no necesitan realmente subcategorías; usar etiquetas para organizar el contenido dentro de los cursos sería suficiente.

Dado que estas suposiciones son cercanas, aquí está lo que sugeriría, primero a un alto nivel:

  1. Cree un pequeño número de categorías de nivel superior: una para “Cursos Actuales”, una para “Cursos Pasados”, una para “Próximos Cursos” y una o más para cosas más generales sobre el sistema en sí (por ejemplo, cómo usar el sitio).
  2. Configure el estilo de la página de inicio como “cuadros con categorías” para que se muestren de forma destacada.
  3. Utilice subcategorías para cada curso.
  4. Créelos en “Próximos Cursos”.
  5. Muévalos a “Cursos Actuales” cuando comience el trimestre.
  6. Cuando un curso concluya, muévalo de “Cursos Actuales” a “Cursos Pasados”.
  7. Controle el acceso a los Cursos utilizando Grupos (más detalles a continuación).

Control de acceso:

  1. Para cada curso, cree un conjunto de los siguientes grupos, por ejemplo: foo_interesado, foo_inscrito, foo_admin.
  2. Cree dos grupos adicionales: “explorar_cursos” y “explorar_cursos_pasados”.
  3. Configure las categorías en “Próximos Cursos” y “Cursos Actuales” para que solo sean accesibles para las personas en los grupos del curso específico y las personas en el grupo “explorar_cursos”.
  4. Configure las categorías en “Cursos Pasados” para que solo sean accesibles para las personas en los grupos del curso específico y las personas en el grupo “explorar_cursos_pasados”.

Experiencia de usuario para grupos y cursos:

  1. Tenga un tema fijado en la categoría superior de “Próximos Cursos” que explique cómo explorar cursos, con una forma sencilla para que las personas se unan al grupo “explorar_cursos”.
  2. ^ lo mismo para “Cursos Actuales”.
  3. ^ lo mismo para “Cursos Pasados”.

Para cursos individuales, tenga un tema fijado en la categoría que explique cómo unirse al curso:

  1. Únase al grupo foo_interesado y/o foo_inscrito.
  2. Agregue el curso a su barra lateral.

La administración será un poco laboriosa al principio, ya que para cada curso nuevo alguien con los privilegios apropiados deberá:

  1. Crear la categoría.
  2. Crear los grupos.
  3. Crear el tema fijado.
  4. Agregar a las personas al grupo _admins.
  5. Proporcionarles la documentación que necesitan para administrar su propio curso.

Parte de eso podría automatizarse con algunas herramientas ligeras. Dependiendo de quién sea el equipo de administración principal, puede tener sentido comenzar con algo fuera de banda que simplemente acceda a la API. O tal vez necesite algo más basado en UI que esté integrado en Discourse como un componente de tema o un plugin. Pero sugeriría comenzar de forma sencilla aquí, y centrarse primero en definir un proceso que funcione, y luego diseñar las herramientas en torno a él.

La escalabilidad de las categorías es una posible preocupación aquí. Discourse tiene algunos problemas de rendimiento y usabilidad cuando el número de categorías es demasiado grande (cientos o miles). Los usuarios con acceso a más categorías sentirán el impacto de esto, mientras que aquellos con acceso limitado no lo harán. Esa es parte de la motivación para limitar el acceso a las categorías como he descrito.

Estoy muy interesado en escuchar cualquier comentario o pregunta que tenga sobre lo anterior.

1 me gusta
16

Hola @mcwumbly, gracias por una descripción detallada y reflexiva.

Lo que describes está, de hecho, cerca de lo que tengo en mente, con algunas diferencias.

Al ejecutar una instancia única para un curso durante unos 5 años, me di cuenta de que es mucho menos esfuerzo ocultar o mover discusiones obsoletas que recrear una instancia de curso desde cero. Así que, en la práctica, el espacio de discurso para un curso es fijo, pero la mayoría de los temas tienen un fin de vida.

Imagino principalmente que los equipos del curso necesitarán gestionar un curso en lugar de configurarlo.

Nuestros cursos tienen alrededor de 200 estudiantes y un equipo de curso de alrededor de 10 personas, incluidos los ayudantes de cátedra. Esto justifica al menos varias categorías:

  • Preguntas y respuestas sobre el contenido (los estudiantes publican, el equipo del curso responde)
  • Organización del curso (igual que lo anterior, pero solo asuntos organizativos)
  • Anuncios (el equipo del curso publica, los estudiantes pueden responder)
  • Preguntas sobre calificaciones (los estudiantes publican, solo el equipo del curso puede ver y responder).
    Planeo abordar este último utilizando Private Topics Plugin y Assigning based on post content.
  • Discusión del equipo del curso (solo visible por el equipo del curso)

Creo que el uso de subcategorías cubrirá esta necesidad.

Me doy cuenta de que se puede crear una agrupación a nivel de instancia de lo anterior, similar a lo que describes, pero parece más razonable poner todo eso en una sola categoría.

En general, creo que las capacidades actuales de Discourse se adaptan bien a este caso de uso, excepto por la característica puramente de frontend de necesitar proporcionar una sensación a un miembro del equipo del curso o a un estudiante de que están viendo un solo curso, en lugar de todos los cursos a la vez.

El componente temático de documentación es un poco similar en que permite al usuario “entrar” en una categoría, pero no permite “permanecer” fácilmente dentro de una categoría.

1 me gusta
17

Sí, mover temas en masa es un poco complicado, pero reasignar una categoría completa de “cursos actuales” a “cursos pasados” sería bastante fácil, creo.

Los beneficios de hacer esto son que cada trimestre podría comenzar de nuevo.

Sin embargo, eso podría ser una desventaja, dependiendo de si crees que tener contenido de trimestres anteriores es valioso o perjudicial, y cuánto esfuerzo le toma a tu equipo crear nuevas categorías para cada trimestre.

Tener categorías que duren indefinidamente ciertamente reduce ese esfuerzo. Si es factible, suena genial.

Y si se convierte en un problema tener contenido antiguo para siempre, tal vez ese sea “un buen problema para tener”, no debería ser demasiado difícil cambiar al modelo que sugerí más tarde.

Creo que tu teoría aquí es sólida.

Tener subcategorías para cada una de esas actividades dentro de cada categoría de curso parece razonable.

Creo que nuevamente depende un poco de cuán seguro estés de que la complejidad adicional está justificada y, si es así, si esa es la forma correcta.

Podrías usar una etiqueta restringida para los anuncios en su lugar, lo que tiene algunos beneficios.

Los dos últimos podrían manejarse a través de mensajes privados de grupo en lugar de una categoría.

Creo que ambas opciones valen la pena considerarlas. Hay algunas compensaciones entre ellas.

A medida que profundices en la configuración, sigue haciendo preguntas cuando te encuentres con ellas.

Y, independientemente de la dirección que elijas para empezar, ¡me encantaría escuchar actualizaciones ocasionales sobre cómo van las cosas!

2 Me gusta
18

Un componente temático podría, por ejemplo, cambiar el icono y hacer que vaya a la página de inicio del curso en lugar de a la global.

Empecé a usar Discourse para enseñar cursos de tecnología instruccional cuando era profesor de educación.

Utilicé una categoría para los materiales del curso y pedí a los estudiantes que respondieran como tema enlazado para entregar su trabajo (en categorías públicas). En un tema de nivel de semestre, un programa de estudios haría referencia a los materiales canónicos del curso indicando cuándo hacer cada cosa. Luego utilicé un conjunto de etiquetas para que indicaran qué temas debían ser calificados y escribí un script que veía si me gustaba un tema para indicar si había aprobado el trabajo.

Escribí un script que actualizaba un csv del sistema de gestión de aprendizaje (LMS) de la universidad para facilitar la carga de las calificaciones allí.

Lo que creo que más me gustó, y que podría haber escrito si hubiera sido un mejor académico (y no hubiera dejado ese trabajo), fue que actualizaba las tareas durante el curso para corregir cosas que no estaban claras, en lugar de esperar al año siguiente para hacer mejoras. Y como todas las ediciones estaban disponibles en el historial, los estudiantes eran libres de hacer la versión de la tarea que quisieran (o que hubieran hecho antes de que yo hiciera la edición). Todavía creo que mejorar el curso sobre la marcha en lugar de esperar un año y esperar recordar cuáles eran los problemas fue una gran idea.

4 Me gusta