Я не могу понять две вещи:
Сталкивался ли кто-то ещё с этой проблемой?
Это возможно, но у нас есть особый случай, который делает задачу сложнее, чем простое добавление выпадающего списка. Выборщик категорий позволяет добавлять только существующие категории… однако мы сейчас разрешаем добавлять пользовательскую запись @, чтобы применить компонент к представлению верхнего уровня «все категории».
Нам придется разделить это на отдельную настройку и перенести существующие настройки, чтобы можно было использовать выпадающий список категорий.
Эта вкладка?
Мне не удалось воспроизвести эту проблему, возможно, она уже исправлена. Если вы всё ещё сталкиваетесь с этим, дайте нам знать.
Извините, я уже покинул Discourse и вернул своё сообщество обратно в Discord.
Это невероятно запутанно. Не могли бы вы объяснить, что означает «@» и как его использовать? Я видел это в интерфейсе настроек Kanban, но не мог понять, что он делает.
Кроме того, почему наличие пользовательской записи «@» делает невозможным использование выпадающего списка? Просто добавьте запись «@» в выпадающий список — разве это не сработает? И ещё лучше: почему её назвали «@»? Напишите в выпадающем списке «Все категории», а «@» используйте за кулисами. Оказалось, что это слишком зашифровано даже для меня, разработчика программного обеспечения, который использует Discourse с самого начала.
Очевидно, это не по теме, но я хочу высказать своё мнение: постоянные проблемы с интерфейсом Discourse делают меня полностью неспособным убедить моих партнёров и заинтересованных лиц использовать Discourse. Все они ненавидят этот интерфейс, им просто невозможно в нём ориентироваться — он запутан во всех смыслах. А невозможность сделать Канбан полезным инструментом лишь усиливает разочарование тех партнёров, которых я пытаюсь убедить использовать Discourse для управления проектами. Возвращаясь к основной теме обсуждения: как, чёрт возьми, объяснить менеджеру, который просто хочет открыть панель настроек и настроить списки Канбан по своему вкусу, что означает символ «@»? Именно такие мелочи в совокупности полностью дезориентируют людей, когда они впервые попадают в пространство Discourse, и они сразу же пытаются уйти, прося меня больше не вовлекать их в эту платформу, так как это лишь тратит их время. Я бессилен вызвать у людей энтузиазм по поводу Discourse. Более того, по какой-то причине команда Discourse ухудшает некоторые аспекты интерфейса вместо их улучшения. См. недавнее обновление здесь и мою критику: Now that the topic title is editable by click, I can't simply copy it without entering the edit mode
Кстати, если я ввожу там @MyCategory (что я интуитивно сделал, пытаясь понять, что делает символ @), система не выдаёт никаких ошибок валидации. Как можно считать нормальным не сообщать мне о том, что я делаю что-то неправильно, когда это очевидно с точки зрения программиста и легко обнаруживается при «Сохранении…» обновлённого значения настройки?
Извините, что пришлось всё это сказать, особенно после того, как я увидел, что кто-то покинул Discourse и вернулся в Discord, что лишь подтвердило мои опасения и разочарование в интерфейсе.
Я очень старался, но сложности слишком велики. Это как в старые времена — война между Android и iPhone.
Android позволял настраивать всё, что угодно.
iPhone был крайне ограничен, но… просто работал.
Сейчас ситуация с Discourse такая же. Я считаю, что нам нужно идти по пути Антуана де Сент-Экзюпери: «Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать».
Существует столько путаницы (например, личные сообщения против приватных чатов — первое, что приходит на ум), что людям действительно трудно убедить пользоваться этим свободно. В Discord меньше трения. То же самое с Skool. Я думаю, именно к этому нам стоит стремиться, а не добавлять новые функции.
Недавно один из моих клиентов ушёл с Discourse именно по той причине, о которой вы говорите, — из-за сложности.
Но если честно, глядя на некоторые серверы Discord, я бы не сказал, что они хоть сколько-нибудь просты? Сейчас в сервер Discord можно добавить очень много всего (включая ботов).
Один огромный минус перехода на Discord или любое другое закрытое приложение — потеря SEO, верно? Возможно, это вас не затрагивает.
Тот, кто реализовал эту функцию, выбрал символ @ как уникальный маркер для списков тем верхнего уровня, когда фильтрация по категории или тегу не применяется. Это аналогично ссылкам forum.example.com/latest или forum.example.com/top. Таким образом, вы вводите @ отдельно как самостоятельную запись, чтобы применить доску на этом уровне.
Я согласен, что это может сбивать с толку, но это можно игнорировать, если вам не нужны глобальные доски Kanban.
Нет, это не делает невозможным, но усложняет переход к выпадающему списку категорий, поскольку нам также нужно создать миграцию, чтобы не сбрасывать настройки на сайтах, которые уже используют его таким образом.
Настройки темы определяются основными API, поэтому при использовании типа списка категорий мы не можем расширять его дополнительными опциями из самой темы.
Discourse — не огромная компания, мы ограничены во времени и вынуждены сосредотачиваться на наиболее востребованных функциях. Рефакторинг компонентов (кстати, предоставляемых бесплатно) может быть сложно поставить в приоритет. Если кто-то захочет спонсировать улучшения настроек Kanban, мы, безусловно, сможем поднять это в приоритете.
Есть ли в Discord функция доски Kanban? Я искал, но кроме бота, интегрирующегося с внешним сервисом Kanban, ничего не нашёл.
Вы также теряете часть контроля: ваши пользователи становятся пользователями Discord, а контент, который они публикуют, становится собственностью Discord. Когда кто-то платит за Discord, прибыль получает Discord. У каждой платформы есть свои компромиссы и издержки.
Да, пока неясно, когда мы сможем уделить внимание функции Канбан.
Это то, что я хотел бы пересмотреть в будущем. Я считаю, что популярность компонента темы свидетельствует о том, что есть спрос на подобные решения.
Реализация в виде компонента темы имеет свои плюсы — любому администратору относительно легко найти и установить его — но при этом накладываются существенные ограничения, которые затрудняют проектирование в соответствии с ожиданиями.
Если мы всё же вернёмся к этой теме, то, на мой взгляд, возможны два пути: либо использовать желаемый набор функций для доски Канбан как повод для улучшения API, доступных для компонентов темы, либо превратить это в основную функцию или плагин, получив больше возможностей для создания серверных API, необходимых для решения конкретных задач.
До тех пор, скорее всего, будут вноситься лишь точечные исправления по конкретным проблемам.
Это правда, но эта ответственность лежит на нас — владельцах, а не на пользователях. Пользователи видят всё максимально просто:
выбрать канал → отправить сообщение, и всё!
Здесь нет Канбан-досок. Не нужно разбираться в разнице между Наблюдением и Отслеживанием. Нет кучи функций вроде «как было бы круто, если бы Discourse тоже мог делать xyz».
Все эти функции очень круты для нас — технических специалистов, владельцев и администраторов.
Но для обычных людей важно чувство общности. Они хотят чувствовать себя свободными в самовыражении и не обязаны разбираться во всех этих сотнях (я думаю, их действительно так много) различных опций, терминов и прочего.
Это именно та обратная связь, которую я получаю от заинтересованных сторон. Они путаются в чатах и приватных темах.
В моём текущем проекте владелец проекта рассматривает Basecamp, потому что говорит, что не может просто использовать Discourse после его пробного использования. Я выступаю за Discourse, так как знаю его выдающиеся функции и возможности, но мало что могу сделать, поскольку плохая юзабилити и хаос как в интерфейсе, так и в терминологии всегда перевешивают функциональность. Не говоря уже о том, что Markdown ненавистен каждому обычному нетехническому пользователю, и я не могу объяснить им, почему это не WYSIWYG в первую очередь. Слава богу, что команда Discourse наконец-то работает над правильным редактором. Большинство людей хотят простой текстовый редактор, похожий на Word, с несколькими возможностями: форматирование, таблицы, цвета, изображения, фрагменты кода. Нет никаких причин, по которым всё это должно быть доступно обычному пользователю в виде Markdown. Более сложные функции, такие как ИИ, кажутся бесполезными, когда конечный пользователь не может понять, почему его текстовый редактор поста разделён на две вертикальные колонки — именно об этом они думают, а не об ИИ.
У них есть все данные. Такова сделка, и я понимаю первоначальное разочарование, но я вижу множество улучшений за последние месяцы в Discourse.
Администраторы могут отказаться от использования чатов и/или личных сообщений и упростить систему. Это требует времени, и у всех, безусловно, есть кривая обучения. Как и в любом деле, есть плюсы и минусы.
Я желаю команде всего наилучшего и считаю, что нам действительно нужно внести свой вклад и дать время естественному процессу эволюции.
В краткосрочной перспективе это приемлемое поведение, но для организации информации это не очень эффективная динамика?
Пользователи, действующие импульсивно <> хорошо организованная веб-страница.
Отсюда и акцент Discourse на модерации и инструментах для организации контента?
Это именно тот случай, когда мы не успеваем за меняющимся ландшафтом того, как участники наших сообществ потребляют контент.
Я столкнулся с точно таким же выбором. Создать что-то надежное, хорошо организованное, с отличным SEO, что позволит нам создать наследие благодаря характеру создаваемого нами контента.
Но сегодня люди (и это, очевидно, обобщение) не чувствуют, что, например, Slack отнимает что-то у них, ограничивая историю последними 90 днями.
Один из моих участников сказал мне (а она — крайне успешный предприниматель, которой недавно исполнилось 30 лет), что сегодня, если информация старше 3 месяцев, она её не читает, так как всё меняется слишком быстро: копать старые материалы — просто пустая трата времени. Неважно, речь о бизнесе, науке или… ну, о жизни в целом.
И, конечно же, наличие таких веток, как у нас здесь, касающихся плагинов, которые могут обновляться через много месяцев, — это обоснованный случай. Но если говорить о «построении сообщества», то важнее «чувство принадлежности» и возможность взаимодействовать с этим сообществом с минимальным или нулевым трением, вместо того чтобы разбираться со всеми опциями, которые нас перегружают.
Я уже говорил об этом в предыдущих ветках, где спрашивал об успехе Skool по сравнению с Discourse.
Я полностью это понимаю, спасибо за ваш вклад.
Чтобы быть предельно ясным: я вижу огромный потенциал в Discourse, и если я смогу когда-нибудь помочь команде своим опытом в построении сообществ — я с радостью помогу.
