Приветствую.
Я прочитал несколько тем здесь об организации категорий и тегов, но не смог придумать структуру, которая подошла бы моим потребностям.
По сути, это форум поддержки, охватывающий множество продуктов. Их может быть от 50 до 100 разных продуктов, и они сгруппированы примерно в 5–10 «отделов».
Но я также хотел бы разграничить права доступа для клиентов и неклиентов. Это означает, что неклиенты будут иметь права на чтение и запись только в разделе «стандартной» поддержки, а на чтение — в разделе «VIP-поддержки», тогда как клиенты будут иметь права на чтение и запись в обоих разделах.
Также я хотел бы использовать систему голосований для создания механизма «запроса функций», чтобы пользователи могли предлагать функции и голосовать за них (для каждого продукта). Опять же, только клиенты смогут запрашивать функции и голосовать; обычные пользователи смогут голосовать только за запросы функций, но не за другие темы, и, конечно же, каждый (сотрудники и пользователи) сможет легко видеть наиболее запрашиваемые функции.
Какой вариант лучше всего подходит? Сначала я думал использовать огромное количество категорий:
ОтделA
Продукт1
Запросы функций
VIP
Продукт2
Запросы функций
VIP
ОтделB
Продукт3
Запросы функций
VIP
Продукт4
Запросы функций
VIP
Но это кажется слишком большим количеством категорий.
Кажется, теги могут помочь в этом случае, но как их можно использовать, принудительно применять, фильтровать и как применять к ним права доступа?
Один из основных недостатков, который я вижу в тегах (помимо вопросов с правами доступа), заключается в том, что каждый форум Discourse, который я посещаю и который является «примером» использования тегов (например, форум «Разговоры о машинах», но есть и другие), в итоге выглядит так, будто теги просто не используются. Очень мало тем помечено тегами, и всё оказывается в одном месте.
Не уверен, что это подойдёт именно вам, но делюсь в надежде, что какая-то часть может оказаться полезной.
Недавно мы перенесли наше 16-летнее сообщество с SMF на Discourse. Наша аудитория была довольна многослойной структурой: категории, подкатегории и множество дочерних форумов. Честно говоря, их было настолько много, что это выглядело абсурдно. Новым пользователям было очень легко потеряться в этом лабиринте.
После перехода на Discourse у нас теперь структура: Категория > Подкатегория > Теги. Теги заменили те 9 172 816 дочерних форумов, которые у нас были раньше.
Я сделал обязательным использование тега при создании темы, причём пользователи могут выбирать только из тех тегов, которые я создал для каждой категории.
В настройках категории установите «Минимальное количество обязательных тегов в теме: 1».
Создайте группы тегов для каждой категории и снимите галочку «Разрешить также другие теги» в настройках категории:
Мы открыли двери в Новый год, поэтому всё ещё в процессе доработки, но вот как выглядят мои группировки тегов: the Lettuce Craft Forums
В процессе создания темы пользователю требуется выбрать минимум и максимум один тег. Я изменил текст на «Теперь выберите один тег (подкатегорию)». Я понимаю, что тег — это не совсем подкатегория, но пока что это та формулировка, которая нужна, чтобы научить наше старое сообщество новым трюкам.
Ваши четкие и информативные сообщения превратили эту тему в начало руководства.
Я написал этот длинный ответ, потому что размышлял о том, как лучше организовать новые форумы. Поэтому я решил протестировать ваш случай, чтобы подготовить что-то конкретное и узнать, будет ли это полезно для вас.
Я согласен с тем, что стоит использовать теги вместо того, чтобы помещать все в категории, как это делаю я сам в некоторых закрытых форумах. Однако вам нужно знать, что на данный момент у категорий есть два явных преимущества:
Категории необходимы для контроля доступа
Плагины позволяют значительно больше настраивать категории
Ключевой вопрос здесь в том, какие из ваших требований должны обрабатываться как категории, а не как теги. Но нам не обязательно решать это сразу. Мы проектируем категории (которые являются «тяжелыми» функциями), а затем смотрим, что можно преобразовать в теги.
Процесс принятия решений
Существует более одного подхода к проектированию ваших категорий. Если не рассматривать теги как основной механизм, я бы действовал так:
Какие категории нужны?
Какие категории требуют отдельных контролей доступа для пользователей?
Нужны ли мне категории по умолчанию?
Здесь используется иной маршрут, чем обычно, потому что можно увидеть минимальный набор категорий по умолчанию, который позволит делать все остальное с помощью тегов.
Нужны ли мне категории по умолчанию?
Какие категории требуют отдельных контролей доступа для пользователей?
Какие другие категории нужны, которые не требуют контроля доступа пользователей?
А. Какова общая задача?
Во-первых, какова логика сообщества, на основе которой будет разрабатываться структура форума — сообщество и форум это разные вещи.
Из вашего первого поста я могу сказать, что у вашего сообщества есть следующие требования:
Основная цель — поддержка
Поддержка обусловлена продуктом, то есть нет продуктов — нет клиентов и нет необходимости в поддержке.
Поддержка сегментируется по статусу клиента, то есть клиент против неклиента
У Продукта есть дополнительная функция запроса функций — как от клиентов, так и от неклиентов
Дополнительные требования к форуму заключаются в том, что:
Отдел управляет продуктом, но клиент/пользователь взаимодействует через продукт.
Примечания:
Поддержка может управляться отделом, но клиенты/пользователи, вероятно, связаны с продуктами, которые они используют. Поэтому я не усложнял бы форум, включая организационную структуру, если только ваши отделы не являются брендами или дочерними компаниями, с которыми клиенты и пользователи почти исключительно ассоциируют себя в своей повседневной деятельности.
Я использую термин «Клиент», потому что следует сделать оговорку относительно использования термина «VIP». Он исключает возможность создания подгруппы VIP-клиентов позже. Я сталкивался с этой проблемой ранее на форуме для специалистов по работе с сообществами, поэтому я бы зарезервировал VIP для дальнейшей сегментации.
Б. Каков минимальный набор категорий для достижения общей задачи?
1. Нужны ли мне категории по умолчанию?
Я считаю все категории по умолчанию необходимыми, но вы можете с этим не согласиться. Просто имейте в виду, что настройки по умолчанию продуманы с учетом требований владельцев средних форумов и пользователей форумов:
#lounge
По умолчанию это для пользователей Trust Level 3 (TL3). Я предлагаю сохранить его как привилегию для ваших самых активных неклиентов. Вас может соблазнить использовать его для вашей категории VIP, переименовав ее и снизив минимальный уровень TL для доступа. Не делайте этого: оставьте вашу группу VIP и категорию отдельно от групп и категорий по умолчанию.
Contribute > Site feedback
Для всех пользователей, чтобы предлагать улучшения или указывать на проблемы в вашем форуме.
#staff
Для администраторов и модераторов, поэтому невидимо для большинства пользователей.
Uncategorized
По умолчанию включена настройка allow uncategorized topics (разрешить темы без категорий).
Возможно, вам стоит отключить настройку suppress uncategorized badge (скрывать значок без категории), чтобы такие темы были более заметны в списках тем, чтобы их было легче назначить в более релевантную категорию.
Это немного увеличивает работу модераторов и пользователей с высоким TL, но значительно упрощает задачу для новых пользователей, которые не могут определиться с категорией.
Эта категория является категорией по умолчанию для shared drafts category (общих черновиков), что является еще одной причиной для ее сохранения.
Пример
На этом этапе ваш минимальный набор категорий будет следующим:
Lounge
Site Feedback
Staff
Uncategorized
2. Какие категории требуют контроля доступа пользователей?
Единственное определенное требование заключается в том, что:
Поддержка сегментируется по статусу клиента, то есть клиент против неклиента
Вы хотите разделить пользователей и клиентов, поэтому для этого необходимо использовать категории. Любой другой метод будет крайне болезненным.
Это означает, что вам нужны клиенты и неклиенты, каждый в отдельной Группе, с как минимум одной категорией, где:
У клиентов есть доступ CRS (Create, Read, See — создание, чтение, просмотр)
У неклиентов есть только доступ S (See — просмотр).
Пример
На этом этапе ваш минимальный набор категорий будет следующим:
Customer
Lounge
Site Feedback
Staff
Uncategorized
3. Какие другие категории нужны, которые не требуют контроля доступа пользователей?
Ваши требования:
Поддержка обусловлена продуктом
У Продукта есть дополнительная функция запроса функций
Даже без ваших требований текущая структура выглядит определенно недостаточной, так как неясно, куда помещать запросы поддержки по продуктам. Поэтому вам нужна как минимум категория поддержки продукта, которая затем требует подкатегории Customer. Я бы оставил категорию верхнего уровня Customer как место для решения вопросов, которые разделяются только с клиентами и, вероятно, видны только им.
Вы можете ранжировать запросы функций продукта, используя плагин Feature Ranking. Он работает путем ранжирования тем в категории, поэтому вам нужна как минимум одна категория. Затем у вас может быть два варианта отображения рейтингов по продукту:
Одна категория с представлениями, отфильтрованными по тегу продукта. Насколько я знаю, это может стать препятствием сейчас, но я не пробовал.
Одна подкатегория Feature Request для каждой категории Product
Какой бы вариант ни был выбран, будет легче размещать темы Feature Request в подкатегории.
Пример без отдельных категорий Product
На этом этапе ваш минимальный набор категорий будет следующим:
Customer
Lounge
Site Feedback
Staff
Support
Customer
Feature Request
Uncategorized
Пример с отдельными категориями Product
На этом этапе ваш минимальный набор категорий будет следующим:
Customer
Lounge
Product 1
Customer
Feature Request
…
Product 100
Customer
Feature Request
Site Feedback
Staff
Uncategorized
Теперь возникает вопрос о взаимосвязи между продуктами и теми, кто ими пользуется.
Вопрос
Одна категория для Support
Одна категория для каждого Product
Используют ли большинство/все клиенты большинство/все продукты?
Да
Нет
Ассоциируют ли большинство/все клиентов с отдельными продуктами?
Нет
Да
Какая поддержка лучше в ядре Discourse?
Теги более ограничены
Категории имеют лучшую поддержку
Какая поддержка лучше в плагинах?
Теги более ограничены
Категории имеют лучшую поддержку
Проще управлять категориями
Да
Нет
Проще управлять представлениями и отчетами
Нет
Да
Проще для нового пользователя Discourse
Нет
Да
В целом, я думаю, что вам следует выбрать отдельные категории для каждого продукта, так как это будет работать, а основные недостатки — это длинный список категорий и скучный период, потраченный на настройку деталей категорий и подкатегорий, а также доступа групп.
Пример с отдельными категориями Product (как показано выше)
На этом этапе ваш минимальный набор категорий будет следующим:
Customer
Lounge
Product 1
Customer
Feature Request
…
Product 100
Customer
Feature Request
Site Feedback
Uncategorized
4. Какие другие категории могут быть полезны
Я уверен, что вы знаете о других категориях, которые могут вам понадобиться и которые вы не указали здесь, например:
Документы компании, например, общие условия и положения для всех клиентов и продуктов
Документы продуктов, например, документы, связанные с продуктами
Загрузки, например, программное обеспечение, связанное с продуктами, такое как старые версии самого программного продукта
Учебные руководства
Часто задаваемые вопросы (FAQ)
В. Какие функции должны быть тегами?
Что касается того, какие теги вам следует использовать, мне нужна дополнительная информация, например, о том, как отделы управляют поддержкой.
В начале я бы исключил Отдел из вашего форума, потому что вы можете разработать отчетность на основе Продукта с сводками по Отделу, которые не потребуют видимого тегирования.
Я отсылаю вас к существующим темам, чтобы вы могли оценить, что можно сделать с тегами в форуме поддержки. Эти темы от новых к старым:
Спасибо вам обоим, @soraiden и @Remah, за очень подробные ответы. Это очень ценно.
Я всё ещё не принял решение. Очень сложно.
Предложения от @Remah кажутся более подходящими для моей ситуации, но когда вы говорите: «тогда у вас будут Документация, HowTo, FAQ и т. д.» — разве они не будут также связаны с продуктами?
Это усиливает ощущение, что продукты должны быть тегами, иначе мне придётся дублировать подкатегории повсюду (как предложенные «Клиенты» и «Предложения по функциям»).
С другой стороны, желательно, чтобы у каждого клиента был разный доступ к разным продуктам, ведь Клиент1 мог зарегистрировать ПродуктА, а Клиент1 мог зарегистрировать ПродуктБ, и это разные вещи. Хотя я мог бы обойтись и без этого, если это действительно необходимо.
Также я боюсь настроить всё на основе тегов, только чтобы позже обнаружить, что какая-то ключевая функция доступна только для категорий, но не для тегов…
Один момент, который я не понял в предложении @Remah: зачем мне нужна категория верхнего уровня «Клиент», а затем подкатегория «Клиент» внутри каждого продукта?
Но ещё раз большое спасибо за очень подробный и структурированный ответ.
Каков ваш срок запуска этого форума? Если он короткий и ограничен по времени, то возможности для экспериментов с тегами может не быть.
Кстати, в процессе тестирования вы можете настроить одновременно и теги, и категории. Не имеет значения, если структура тегов дублирует структуру категорий. Если вы используете категории, то теги не понадобятся, поэтому их просто не будут видеть, так как никому не нужно их использовать.
Это именно та проблема, которая меня тоже беспокоит. Сердце говорит попробовать теги, а разум — что они ещё не совсем готовы. Я уже выявил одну потенциальную проблему с тегами: в моём предыдущем сообщении о том, что фильтрация по тегам не работает с плагином Feature Ranking. Однако команда Discourse мотивирована на активное использование тегов, поэтому они могут увидеть возможности для разработки новых функций, чтобы помочь в этом.
Вы можете начать разработку структуры форума, используя теги вместо категорий. Если в данный момент вы не сможете добиться желаемого, то вашим запасным вариантом будет создание всех категорий продуктов и подкатегорий.
Обязательно записывайте всё, что вы не можете сделать или не понимаете. Затем вернитесь на этот форум с этими вопросами и попросите решения.
Категории очень заметны и существуют независимо от тем, тогда как структура тегов не так заметна, и теги существуют только тогда, когда есть темы, которые их используют. Поэтому, чтобы наполнить форум нужными вам тегами, вам понадобятся «примерные» темы, которые их используют, например, тема со списком продуктов.
Одним из дополнительных преимуществ тегов является возможность создания групп тегов, чтобы ваши продукты можно было сгруппировать по группам тегов для ваших отделов. Групповые теги отделов не нужно добавлять в темы, так как добавление тега продукта к теме косвенно ассоциирует группу тегов с этой темой. Таким образом, теги предлагают уникальные возможности, которые нельзя реализовать с помощью категорий.
Да, я бы сказал, что это весьма вероятно. Но вам стоит пройти процесс оценки плюсов и минусов каждого варианта.
Если у вас есть подкатегория Клиент для каждого продукта, то куда вы поместите темы, которые относятся ко всем клиентам, но не ко всем пользователям? Это не обязательно должна быть отдельная категория, но стоит подумать, что вам может понадобиться или что можно использовать для новых возможностей.
Новый форум — это возможность освоить новые подходы к работе.
Насколько я знаю, это