Как показывать древовидные обсуждения в вебе

Я работал над древовидными обсуждениями и комментариями в своём приложении для веба и мобильных. Пытался понять, что делать с бесконечным ветвлением, пример которого можно встретить на Hacker News и Reddit. И решил, что рассказ о моих изысканиях будет полезен.

Начал с исследования, как древовидные обсуждения отображаются сейчас. Если отмести некоторые странные способы, останется 5 основных вариантов:

У каждого есть преимущества и недостатки.

Полностью плоские

Встречаются на многих новостных сайтах. Пример: New York Times.

Преимущества:

• Простота навигации. Просто прокручивайте страницу вниз.
• Содержимое не выдавливается с экрана.

Недостатки:

• Недоступность контекста.
• Тяжело проследить за ходом обсуждения или понять, к чему относится конкретный ответ.

Бесконечно ветвящиеся

Пример: Reddit, Disqus, Пикабу. С определённого момента Reddit скрывает ответы в ветках, но всё равно это отличный пример с дискуссиями, которые могут идти бесконечно.

Преимущества:

• Контекст всегда понятен.
• Можно вести продолжительные обсуждения.

Недостатки:

• Сложность навигации.
• Тяжело искать новые ответы в ветке обсуждения.
• Содержимое занимает на экране всё меньше места. Ширина каждого нового ответа в ветке становится всё меньше и меньше.
• Не позволяет выбрать какую-то конкретную ветку для ознакомления. Джефф Этвуд написал об этом в статье Web Discussions: Flat by Design.

Ограниченно ветвящиеся

Пример: Stack Exchange.

Преимущества:

• Намекает пользователям, что дискуссии не могут идти бесконечно.
• Контекст понятен (до определённого момента).
• Содержимое не выдавливается с экрана.

Недостатки:

• Недоступны более глубокие уровни ответов.

Скрываемые бесконечно ветвящиеся

Пример: Quora, Живой журнал.

Преимущества:

• Контекст доступен по запросу.
• Легко прокрутить страницу и выбрать ветку для углубления.
• Меньше когнитивная нагрузка при просмотре комментариев.

Недостатки:

• Требуются дополнительные действия для просмотра контента.

Ограниченно ветвящиеся с тизерами

Пример: Фейсбук.

Преимущества:

• Контекст доступен по запросу.
• Легко прокрутить страницу и выбрать ветку для углубления.
• Меньше когнитивная нагрузка при просмотре комментариев.
• Обращает внимание пользователя на подходящее содержимое.

Недостатки:

• Новые комментарии в ветке могут сбить с толку, если вы не знаете контекст.

Мой вариант

В бизнесе любой дизайн — это компромисс. В моём случае нужно было понять, какого эффекта я хочу добиться и чем готов ради него пожертвовать. В существующем продукте работают бесконечно ветвящиеся комментарии. Переход на любой другой вариант отображения будет сложным. Мне нужен единый подход для веба и мобильного приложения, поэтому мне ближе всего вариант ограниченного ветвления с тизерами.

Это лучшее сочетание простоты сканирования комментариев и возможности углубиться в отдельное обсуждение. Особо интересны тизеры ответов — хитрый способ предложить пользователю релевантное содержимое. Можно показать первый непрочитанный ответ, последний ответ кого-нибудь из друзей или самый популярный. Ещё не решил, какой вариант будет полезнее.

Важный вопрос, надо ли показывать обсуждения на мобильном как-то иначе? Если надо, то как? Некоторые приложения (например, Quora и Фейсбук) на одной странице показывают пост и первый уровень комментариев, а на другой — ответы в выбранной ветке. Скорее всего, это необходимо для повышения производительности приложения.

С другой стороны, YouTube показывает всё на одной странице:

Пока что я склоняюсь к варианту с одной страницей и скрытыми по умолчанию ответами на комментарии, как в YouTube. Надо узнать больше о производительности этого варианта.

Предполагаю, хорошим решением будет:

• Показывать комментарии и ветки ответов на одной странице, чтобы упростить их просмотр и углубление в конкретное обсуждение.
• В мобильной версии показывать первые 5 строк комментария. С возможностью прочитать полностью.
• Отображать первый ответ на комментарий. С возможностью загрузить ещё 5. («Загрузить ещё» на мобильных.)
• Показывать первые 10 комментариев к статье. С возможностью загрузить ещё 10. («Загрузить ещё» на мобильных.)

Мне нравится, что для веба и мобильного приложения работает единый подход и при этом учтены различия платформ. Мы с командой ещё обсуждаем это решение, поэтому предлагайте свои варианты и пишите комментарии.

Мнения экспертов

Автор перевода попросил экспертов в проектировании интерфейсов поделиться мнением, а также нашёл опубликованный ранее совет Ильи Бирмана.

Егор Камелев

основатель «Проектората»

Моё мнение простое. Сначала смотрим, какая система комментов уже есть в цмске (примечание: системе управления сайтом). Для большинства простых проектов она подойдёт. А если нам надо кастомное проектирование, то делаем тот вид комментов, который лучше всего подойдёт под наши пользовательские сценарии.

Вкратце, при кастомном проектировании нужно учесть три составляющих: бизнесовая, пользовательская, технологическая. В данном случае бизнесовой можем пренебречь, потому что она нам нужна в большинстве случаев тогда, когда сайт зарабатывает на продаже рекламы, и нам нужно больше показов страниц. Для этого вводим постраничку в комментариях.

Технологическая — учитываем адаптивку и нагрузку. То есть отображение для разных видов устройств и защита от перегрузки контентом.

Пользовательская:

• Нам важно, чтобы люди общались друг с другом или просто оставляли свои мнения к материалу?
• Нам важно, чтобы они рейтинговали друг друга?
• Нам важно придумывать систему, которая не позволит искусственно манипулировать положением комментария в треде?
• Нам важно сделать такую систему оценок комментов, которая не будет провоцировать стадный эффект? (Это когда мы на некоторое время прячем рейтинг комментов.)
• Нам важно ограничить сообщество от негативных комментов?

И ещё 100 500 вопросов в зависимости от проекта.

Ярослав Табаков

директор по развитию Astra Media Group

Как человеку, который смотрит на все аспекты взаимодействия со стороны опыта пользователя, мне нравится проектировать так, словно технических ограничений нет. С оговоркой, что это в большинстве случаев не так, и часто лучшее решение — наиболее простое и доступное, порассуждаю об «идеальной системе комментариев».

В любой ситуации, когда этого достаточно для задач обсуждения, стоит использовать линейную систему. Например, если речь идёт об обсуждении деталей задач в системе командной работы. В таких системах если обсуждение затягивается и распадается на ветки, значит что-то пошло не так. Если система будет этому препятствовать — тем лучше.

Предположим, речь о широком публичном обсуждении, где плюрализм мнений важен, а дискуссия естественным порядком должна распадаться на обсуждение частных вопросов, нюансов и аспектов. В такой ситуации удобно иметь сначала список обсуждаемых тем, а затем углубиться в одну из них. При такой задаче идеально подходит двухуровневая структура комментариев вроде той, что использует Фейсбук. Верхний уровень выполняет, по сути, функцию списка поднятых тем. При этом разумно полностью или частично скрывать второй уровень комментариев, так как далеко не все они релевантны интересам читающего.

Наконец, есть такой распространённый тип площадок, как флудильня, предназначенная для таймкиллинга в бесконечном чтении и генерации бесконечных же, часто мало осмысленных комментариев. Ситуация наиболее сложная для проектирования. Но парадокс в том, что в ней удобство чтения комментариев сугубо вторично для пользователя. Здесь процесс самоценен, а его эффективность практически не имеет значения.

В любом случае, при выборе того или иного подхода ключевой вопрос: «Зачем это пользователям?» Выяснив их задачи, можно совершить осмысленный выбор. Не ответив — невозможно.

Илья Бирман

арт-директор «Дизайн-бюро Артёма Горбунова»

Идеальной системы комментариев нет.

Линейная система:

• помогает комментаторам держаться темы,
• мешает вести одновременно несколько бесед,
• помогает читателям следить за беседой,
• хорошо воспринимается зрительно,
• проста в технической реализации.

Древовидная система:

• помогает комментаторам развивать в ветках разные темы,
• провоцирует комментаторов на ведение споров,
• крайне затрудняет последовательное чтение комментариев,
• вследствие всего этого повышает количество комментариев и время на сайте,
• плохо выглядит,
• сложна в технической реализации.

Линейную систему комментариев используют чаще, потому что она имеет больше плюсов. По моему личному мнению, древовидная система предпочтительна лишь тогда, когда качество комментариев не имеет значения, и они используются лишь как инструмент улучшения статистики.

Саша Куценко

креативный директор UX-студии Aidem

Смотря с какой стороны смотреть.

Если со стороны читателя статьи, то модель комментариев как на «Роем» оптимальна — показаны лучшие комментарии, и по ним многое ясно. При желании можно прочитать остальные, но предположу, что это нужно 10–20% пользователей.

Если со стороны участников дискуссии, чья цель — само обсуждение, то им нужна функциональность беседы: кому обращен ответ, какие участники беседы или их высказывания упоминаются в сообщении и т.д. Им нужна среда одновременного нахождения круга лиц (условно, в одном месте и в одно время), чтобы слышать друг друга и вовремя реагировать на позицию одного или нескольких. Причем, стоит отметить, что такого рода дискуссии характерны обращениями собеседников друг к другу, а значит требуют идентификаторов (имена, ники). Поэтому, наиболее естественная среда для таких дискуссий — социальные сети, где упоминания и уведомления — базовый функционал среды, и вложенность комментариев не так востребована.

Адаптация среде и задаче

Понятно, что каждому бизнесу и его пользователям нужна своя система. Но что если порассуждать о системе, которая адаптивна среде и задаче.

Мне кажется, дело не в выборе между линейной и древовидной системой, а в отсутствии системы, управляющей рангами внимания пользователя к разным веткам дискуссии. Например, если 2 собеседника «зацепились языками» в самом начале обсуждения материала, то их диалог не достоин огромной части страницы и должен быть как-то сокращен с возможностью прочтений при желании.

Отведем этих спорящих парней в сторону, пусть не мешают остальным.

Тогда как если в том же начале обсуждения материала началась ветка с участием большого числа участников, это заслуживает большого внимания, и принцип сокращения отображения такой ветки должен быть другой.

Я также выскажу гипотезу, что решение о том, «насколько далеко отводить спорящих парней от общей группы собеседников», может меняться в зависимости от количества высказанных комментариев о материале в целом, а также от количества самих участников и их репутационных характеристик. Другими словами:

Если спор двух парней начался в начале, и ничего другого нет, то им и место в центре толпы.

Тогда как, если рядом появились другие группы обсуждающих с интересными участниками, внимание к первой паре должно быть сокращено. Я говорю об алгоритме отображения комментариев, который учитывает ход беседы и модифицируется в зависимости от того, как проходит дискуссия.

Это легко представить на примере толпы, услышавшей резонирующее заявление со сцены. Появятся и многочисленные, и маленькие группы обсуждающих. В них будут как авторитетные личности, так и нет. От этого будет зависеть рост или сокращение численности группы в ходе её цикла жизни. Будут мнения, оставшиеся без комментариев со стороны, а кто-то будет долго спорить вдвоем, далеко уйдя от изначальной темы.

Словом, это должно происходить в режиме реального времени и на основании ситуации в дискуссии.

Алгоритм управления отображением этого информационного потока не может быть линейным из-за слишком большой вариативности сценариев, которые влияют на природу дискуссии и её характеристики в каждый момент времени.

Это большая и интересная тема. Думаю, нас ждут новые модели отображения комментариев.

Кстати, «Медуза» обещала сделать какие-то новые (умные) комментарии на своем сайте. Учитывая все сложности вопроса комментариев под статьями СМИ, очень интересно посмотреть, что они придумали.

Понравилось — подписывайтесь

• Заметки UX-проектировщика ВКонтакте или в Фейсбуке;
• Рассылка UX-проектировщика.

«How to display threaded discussions on the web» написал 21 сентября 2015 года Rian van der Merwe, директор по дизайну продукта Jive Software и автор книги Making It Right: Product Management For A Startup World.

Перевёл статью, добавил несколько примеров из рунета и собрал мнения экспертов Антон Григорьев. Статья также опубликована в VC.