Я хотел бы запустить один экземпляр Discourse для университетской программы, где категории верхнего уровня соответствуют разным курсам, а доступ управляется через группы. Чтобы преподаватели и студенты каждого курса имели целостное представление о своём курсе, я хотел бы обеспечить ощущение изоляции между разными курсами. Поэтому мне нужно, чтобы мой экземпляр предлагал опыт навигации, похожий на Teams, Slack или Mattermost, где существуют относительно изолированные команды, и пользователям необходимо переключаться между ними. В моём случае это означало бы, что интерфейс делает акцент на данных, относящихся к выбранному курсу. Например, пользователи проводят большую часть времени в одной из категорий верхнего уровня, и выбор такой категории фильтрует подкатегории и каналы чата, которые они могут легко видеть.
Аналогичная потребность возникает в экземпляре, где категории соответствуют разным исследовательским группам (я также хотел бы запустить такой).
Какие существующие инструменты могут помочь достичь этого?
На самом деле я не хочу их отключать: студент, скорее всего, будет одновременно посещать несколько курсов, и уведомления от всех них вполне приемлемы. Дело скорее в том, что я хочу создать более чёткое впечатление «сейчас я работаю с курсом X».
Похоже, что цель плагина заключается в том, чтобы основная группа соответствовала выбранной домашней странице, верно? Вам нужно включить user_selected_primary_groups, чтобы пользователи могли менять свою основную группу на странице настроек аккаунта.
В идеале я бы хотел что-то более временное и менее заметное для публики. Однако, полагаю, что если не использовать заголовок и флёр, то UI-компонент для переключения основной группы мог бы работать как селектор команды.
Что-то вроде дополнительного селектора в боковой панели, который несколько дней назад работал здесь в качестве эксперимента, было бы отличным решением для этого.
Вы могли бы это сделать. Также можно менять логотип сайта в зависимости от основной группы пользователя; я реализовывал это для сайта, где несколько университетов используют один и тот же экземпляр. Возможно, вам подойдёт компонент темы с выпадающим списком в верхней панели, который позволит выбрать основную группу (и, возможно, вместо слова «группа» использовать слово «курс»).
@Anton_Akhmerov, вы планируете сделать это самостоятельно или готовы заплатить кому-то, чтобы он сделал это за вас? Дайте знать!
Если вы хотите сделать это сами, я бы хотел перенести обсуждение в Development, чтобы вы могли работать над этим там, отчитываться перед сообществом и получать обратную связь от других участников. Давайте перенесём это в Development.
Если вы хотите заплатить кому-то, я перенесу обсуждение в Marketplace.
Думаю, лучше перенести это обсуждение в канал #community, чтобы подробнее обсудить ваш сценарий использования, как наилучшим образом удовлетворить ваши потребности сегодня, и освободить место для других, кто мог столкнуться с похожими задачами и уже нашел их решения.
Затем, если будут выявлены конкретные пробелы в продукте, которые вы считаете достаточно важными для самостоятельной реализации или продвижения, мы можем создать отдельные темы в каналах #feature и/или Development для этих идей.
Звучит ли это согласованно с вашими мыслями? Или вы уже на этапе «Я готов создать недостающие компоненты»?
#community тоже имеет смысл . Функция выглядит сложной, и, судя по популярности подобных запросов, она в какой-то мере отвечает потребностям сообщества
Я планирую заняться этим, но пока мои планы довольно размыты.
В качестве продолжения, вот как я представляю наилучшее удовлетворение ваших потребностей с помощью стандартных функций Discourse. Это может быть не в точности то, что вы имеете в виду, но я считаю, что это стоит рассмотреть как отправную точку для обсуждения.
Сначала я делаю некоторые предположения, которые могут быть верными, а могут и нет. Пожалуйста, дайте знать, если я ошибаюсь:
Будет много курсов (десятки, возможно, сотни)
Настройка курсов будет происходить периодически, крупными партиями, в начале каждого семестра (2–4 раза в год)
У курсов будет срок окончания
Люди, управляющие курсами, должны иметь возможность настраивать их самостоятельно
Люди, управляющие курсами, будут иметь ограниченный или нулевой опыт управления сайтом Discourse.
Люди, управляющие курсами, действительно нуждаются только в просмотре своих собственных. Они могут иногда просматривать другие в качестве примеров, но не нуждаются в постоянном участии в них.
^ То же самое для студентов курсов
Существует очень небольшая команда, управляющая системой в целом
Курсам на самом деле не нужны подкатегории; использования тегов для организации контента внутри курсов будет достаточно
Если эти предположения близки к истине, вот что я предлагаю, сначала на высоком уровне:
Создать небольшое количество категорий верхнего уровня: одну для «Текущих курсов», одну для «Прошедших курсов», одну для «Предстоящих курсов» и одну или несколько для общих вопросов, касающихся всей системы (например, как пользоваться сайтом)
Установить стиль главной страницы как «блоки с категориями», чтобы они были хорошо заметны
Использовать подкатегории для каждого курса
Создавать их в «Предстоящих курсах»
Перемещать их в «Текущие курсы» в начале семестра
Когда курс завершается, перемещать его из «Текущих курсов» в «Прошедшие курсы»
Контролировать доступ к курсам с помощью групп (более подробно ниже)
Контроль доступа:
Для каждого курса создать набор следующих групп, например: foo_interested, foo_enrolled, foo_admin
Создать две дополнительные группы: «browse_courses» и «browse_past_courses»
Настроить категории в «Предстоящих курсах» и «Текущих курсах» так, чтобы они были доступны только людям из групп для конкретного курса и людям из группы «browse_courses».
Настроить категории в «Прошедших курсах» так, чтобы они были доступны только людям из групп для конкретного курса и людям из группы «browse_past_courses».
Пользовательский опыт для групп и курсов
Закрепить тему в категории верхнего уровня для «Предстоящих курсов», объясняющую, как просматривать курсы, с простым способом присоединения к группе «browse_courses».
^ То же самое для «Текущих курсов»
^ То же самое для «Прошедших курсов»
Для отдельных курсов закрепить тему в категории, объясняющую, как присоединиться к курсу:
Присоединиться к группе «foo_interested» и/или «foo_enrolled»
Добавить курс в боковую панель
Администрирование будет немного трудоемким вначале, так как для каждого нового курса кому-то с соответствующими привилегиями потребуется:
Создать категорию
Создать группы
Создать закрепленную тему
Добавить людей в группу _admins
Предоставить им документацию, необходимую для управления своим курсом
Часть этого можно автоматизировать с помощью легковесных инструментов. В зависимости от того, кто входит в основную административную команду, может иметь смысл начать с внешнего решения, которое просто обращается к API. Или, возможно, вам понадобится что-то более ориентированное на интерфейс, встроенное в Discourse как компонент темы или плагин. Но я предлагаю начать с малого здесь, сосредоточившись сначала на определении рабочего процесса, а затем проектировать инструменты вокруг него.
Масштабирование категорий может стать проблемой. У Discourse есть некоторые проблемы с производительностью и пользовательским опытом, когда количество категорий становится слишком большим (сотни или тысячи). Пользователи с доступом к большему количеству категорий почувствуют это влияние, тогда как те, у кого доступ ограничен, — нет. Это одна из причин ограничения доступа к категориям, как я описал выше.
Очень интересно услышать любые и все отзывы или вопросы, которые у вас есть по вышеизложенному.
Привет @mcwumbly, спасибо за подробное и вдумчивое описание.
То, что вы описываете, действительно близко к тому, что я имею в виду, с некоторыми отличиями.
Запуская один экземпляр курса в течение примерно 5 лет, я понял, что гораздо меньше усилий требуется скрыть или переместить устаревшие обсуждения, чем воссоздавать экземпляр курса с нуля. Поэтому на практике пространство Discourse для курса фиксировано, но у большинства тем есть срок окончания поддержки.
Я в основном представляю, что командам курса потребуется управлять курсом, а не настраивать его с нуля.
На наших курсах обучается около 200 студентов, а команда курса состоит примерно из 10 человек, включая ассистентов. Это оправдывает наличие как минимум нескольких категорий:
Вопросы по содержанию (студенты задают вопросы, команда курса отвечает)
Организационные вопросы курса (то же самое, но исключительно организационные вопросы)
Объявления (команда курса публикует, студенты могут отвечать)
Обсуждения внутри команды курса (видны только членам команды курса)
Я считаю, что использование подкатегорий покроет эту потребность.
Я понимаю, что можно создать группировку вышеперечисленного в масштабах всего экземпляра, аналогичную тому, что вы описываете, но кажется более разумным поместить всё это в одну категорию.
В целом, я думаю, что текущие возможности Discourse хорошо подходят для этого варианта использования, за исключением чисто фронтенд-функции, которая должна создавать у члена команды курса или у студента ощущение, что они просматривают один конкретный курс, а не все курсы одновременно.
Компонент темы документации немного похож в этом плане, так как он позволяет пользователю «войти» в категорию, но не позволяет легко «остаться» внутри категории.
Да, массовое перемещение тем — это немного неудобно, но перенос всей категории из «текущих курсов» в «прошедшие курсы» был бы, я думаю, довольно простым.
Преимущество этого подхода в том, что каждый семестр мог бы начинаться с чистого листа.
Однако это может стать и недостатком, в зависимости от того, считаете ли вы, что контент предыдущих семестров полезен или вреден, а также от того, сколько усилий требует от вашей команды создание новых категорий для каждого семестра.
Бессрочное сохранение категорий, безусловно, снижает эти затраты. Если это реализуемо, звучит отлично.
А если со временем наличие старого контента станет проблемой, возможно, это «хорошая проблема», и не составит особого труда позже перейти к модели, которую я предложил.
Я думаю, ваша теория здесь верна.
Использование подкатегорий для каждого из этих видов деятельности внутри категории каждого курса выглядит разумным.
Снова всё зависит от того, насколько вы уверены, что дополнительная сложность оправдана, и если да, то является ли это правильной структурой.
Для объявлений можно использовать ограниченные теги, что имеет свои преимущества.
Последние два пункта можно решить через личные сообщения групп вместо создания отдельной категории.
Я считаю, что стоит рассмотреть оба варианта. Между ними есть компромиссы.
По мере того как вы углубляетесь в настройку, не стесняйтесь задавать вопросы по мере их возникновения.
И независимо от того, с какого направления вы начнёте, я буду рад периодически получать новости о том, как всё идёт!
Компонент темы может, например, изменить иконку и перенаправить на главную страницу курса вместо глобальной.
Я начал использовать Discourse для преподавания курсов по педагогическим технологиям, когда работал профессором образования.
Я выделил отдельную категорию для учебных материалов и просил студентов отвечать в виде связанных тем для сдачи работ (в публичных категориях). В теме, посвящённой семестру, в syllabus указывались канонические материалы курса с описанием того, что и когда нужно делать. Затем я использовал набор тегов, чтобы отмечать, какие темы подлежат оценке, и написал скрипт, который проверял, поставил ли я лайк теме, чтобы определить, одобрил ли я работу.
Я также написал скрипт, который обновлял CSV-файл из университетской LMS, чтобы упростить загрузку оценок туда.
То, что мне понравилось больше всего, и о чём я, возможно, написал бы, будь я более академичным (и не уволился с той работы), — это возможность обновлять задания в ходе курса, исправляя неясные моменты, вместо того чтобы ждать следующего года для внесения улучшений. И поскольку все правки были доступны в истории, студенты могли работать с любой версией задания (или той, что существовала до моего редактирования). Я до сих пор считаю, что улучшение курса «на лету», а не ожидание года и надежда на то, что вспомнишь, какие именно проблемы были, — отличная идея.
. Функция выглядит сложной, и, судя по популярности подобных запросов, она в какой-то мере отвечает потребностям сообщества