Подкатегории должны быть вложены в боковую панель.
Такие примеры, как этот, не будут работать, если подкатегории не вложены:
Ford
–Вождение
–Покупка
GM
–Вождение
–Покупка
Результат отображения будет следующим:
Вождение
Вождение
Ford
GM
Покупка
Покупка
На скриншоте ниже документация является родительской категорией, а admins, faq, moderators, sso, sysadmin — подкатегориями.
Один момент, который нам нужно прояснить: что делать, если пользователь добавляет подкатегорию, но не родительскую категорию… всегда ли нужно включать родительскую категорию для контекста?
Это более или менее обязательно, если подкатегории могут иметь дублирующиеся названия.
Я не разработчик, но я выполняю много задач, связанных с UX/UI, поэтому считаю, что использование одинаковых названий — в любом случае плохая политика. Одно из решений — требовать уникальности даже реальных названий (но после этого окажется множество сломанных форумов…)
Но могли бы вы предоставить администраторам свободу в именовании категорий способом, не зависящим от технической части форума? Это просто ещё одно видимое для пользователей название — тогда можно использовать что-то вроде категория:подкатегория.
Принудительное включение названия родительской категории в название подкатегории приведет к большому количеству избыточных элементов, например:
Ford
– Ford Driving
– Ford Purchasing
GM
– GM Driving
– GM Purchasing
Я только что переименовал все наши подкатегории, добавив префикс категории, но я также согласен, что вложенность была бы хорошим вариантом. Поскольку у каждой главной категории свой уровень безопасности, мы использовали одинаковые названия, но я также вижу преимущества наличия префиксов.
Также было бы удобно, если бы категории можно было открывать и закрывать — при более чем 200 категориях список получается очень длинным.
Наше первоначальное предположение заключается в том, что мы можем начать с некоторых простых улучшений здесь:
Это не решает всю проблему целиком, но доступны обходные пути: 1) заставить пользователей добавлять родительскую категорию самостоятельно или 2) обновлять названия категорий для их различения.
Тем не менее, мы будем следить за этим и рассмотрим, какие ещё изменения могут быть оправданы.
Сколько из этих категорий, по вашему мнению, пользователь добавит в свою боковую панель?
Я воспринимаю это как общий вопрос 
Ни одной. Они уже подписаны только на те категории, которые их интересуют, и хотят получать уведомления одинаково от всех них.
3 сообщения были перенесены в новую тему: Вариант отображения только непрочитанных категорий и тегов в боковой панели
Переключение подкатегорий в боковой панели имеет решающее значение. У нас уже есть девять категорий и 19 подкатегорий, и я ещё не закончил сортировку. Я ожидаю добавить ещё 25 подкатегорий. Я хочу, чтобы все они были доступны в боковой панели. Наш корпус создавался с 1969 года, поэтому наш форум служит не только симпозиумом, но и справочной библиотекой. Для нас категории являются и инструментами поиска, и фильтрами для обсуждений.
По той же причине теги должны быть расположены в алфавитном порядке и иметь прокрутку в боковой панели. У нас сейчас 1400 тегов, и к моменту завершения сортировки их количество удвоится. Без окна прокрутки невозможно будет представить теги в удобном виде. На самом деле, идеальным вариантом было бы окно прокрутки с полем поиска сверху.
Это, вероятно, отдельная тема для обсуждения, но размещение тегов в переключаемых выпадающих окнах под заголовками тем в списке также было бы очень полезно. В наших темах в среднем по 18 тегов. Самая длинная тема содержит 98 тегов. Когда я отображаю их все, они затмевают заголовки тем. Я упоминаю об этом здесь, потому что реализация универсального класса для переключаемого прокручиваемого блока могла бы решить несколько полезных задач.
Также было бы неплохо, если бы категории можно было раскрывать и сворачивать
Зачем? Это было бы ужасно неудобно в использовании, потому что этот список будет бесконечно длинным. Ну, если большинство ваших пользователей имеют экраны 24 дюйма и больше, вас не беспокоят маленькие экраны и мобильные устройства, и ваши пользователи не знают, как использовать страницу категорий, то возможно.
И мы вернулись к основной проблеме: пользователь должен иметь выбор, что показывать, а что нет. Это не задача администратора решать это.
Потому что это упростит навигацию. Это будет намного чище, чем представление категорий/списков в двойную ширину, которое является единственным текущим вариантом и занимает гораздо больше места на экране, чем один список с боковой панелью, если проблема в экономии пространства.
Почему
Если вы имеете в виду теги, то очень длинный алфавитно-цифровой список, прокручиваемый в окне, управляемом полем поиска над ним и колесиком мыши, был бы очень удобным и намного лучше любого другого представления тегов. Это касается и огромного списка на странице тегов, который абсолютно не удобен для навигации, так как требует постоянного переключения между страницей тегов и темой, а единственным инструментом для этого является кнопка «Назад» в браузере.
этот список будет бесконечно длинным.
Итак, здесь два момента.
Во-первых, Discourse разработан снизу вверх с прицелом на будущее, что означает, что он предназначен для всех, у кого есть большие экраны с высоким разрешением. В любом случае это почти не имеет значения: на прошлой неделе я покупал новый монитор для своей дочери и не нашел ни одного размером меньше 24 дюймов.
Что касается мобильных устройств, то могу лишь сказать, что навигация, спроектированная для таких интерфейсов, во всех отношениях отличается от навигации для настольных или портативных компьютеров. Боковые панели не являются подходящим инструментом.
если большинство ваших пользователей имеют экраны 24 дюйма или больше, и вас не беспокоят экраны меньшего размера и мобильные устройства
Будущее, которое уже является обычным понедельником, совершенно противоположно. Оно построено для мобильных устройств. Извините, но большие экраны — это вчерашний день.
Знаете ли вы, что в Европе мобильных телефонов больше, чем ноутбуков? Но у нас больше нет стационарных телефонов или чеков (за исключением Великобритании и Ирландии, но они отстают примерно на 50 лет )
Похоже, что ваш сценарий использования больше подходит для discourse-docs, чем для боковой панели.
Вы можете посмотреть пример представления и фильтрации, которые оно предоставляет, здесь Documentation - Discourse Meta
Да, я этого совсем не ожидал. Мне кажется, что версия боковой панели в виде слайдера отлично подходит для этих назойливых мобильных устройств.
Так что, возможно, это мобильное приложение, которое идет в комплекте с Lucky Forums на Digital Ocean?
Стивен, спасибо за это предложение. Я установил его и сейчас пробую. Оно может подойти для большого набора статей, которые мы еще не добавили. Мне нужно для них возможность комментирования, чтобы вовлекать читателей в обсуждения. Я думал об интеграции Ghost с Discourse для этой цели.
Я всё ещё считаю, что боковая панель будет идеальна для навигации на настольных компьютерах и ноутбуках, если в ней будет переключаемый прокручиваемый блок для тегов и переключаемые категории.
Эта часть была реализована в PR
Значок цвета очень полезен для различения связей между родительской категорией и подкатегорией. Сортировка и, возможно, отступ должны укрепить визуальное определение подкатегорий. Вот что я имею в виду:
documentation является родительской категорией для admins и sysadmin. В текущей настройке они отсортированы по алфавиту, и единственным указанием на связь является цвет половины значка. Очевидно, это не идеально.
При сортировке мы получаем ощущение порядка и взаимосвязи, но всё же различие остаётся только в цвете значка.
Более подходящий подход — добавить подкатегории небольшой отступ, который повсеместно понимается как указание на связь между категорией и подкатегорией. Приведённый выше макет показывает, как это может выглядеть, если подкатегория будет сдвинута на половину или полную ширину значка.
Спасибо, что нашли время создать макеты этих идей!
Есть ещё один сценарий, который стоит рассмотреть: когда у пользователей в боковой панели есть все перечисленные выше категории, которые вы показали, но нет родительской категории Documentation. Как бы вы предложили обрабатывать такой сценарий?
Думаю, это зависит от структуры сайта. В моем исходном посте, где я привел Ford и GM в пример структурированного сообщества, отсутствие родительской категории могло бы затруднить чтение боковой панели — что есть что?
В таком случае родительскую категорию следует отображать:
В случаях, когда каждая подкатегория может существовать самостоятельно, родительская категория может быть не обязательной.
Для категорий с подкатегориями мое сообщество рассматривает родительскую категорию как заполнитель, не содержащий тем. Вместо этого все темы находятся в подкатегориях. У нас также есть другие самостоятельные категории.
Таким образом, в идеале администратор должен иметь возможность выбирать, отображать ли родительскую категорию в боковой панели.
Отображать иерархию в боковой панели
Порядок подкатегорий в боковой панели теперь сначала сортируется по их родительской категории согласно этому PR от @tgxworld:
Кто-нибудь нашел решение для вложенных подкатегорий? Я всё ещё ищу, но не могу найти компоненты темы, которые работают.
