Поиск и связывание тем в тексте, например, ссылки в скобках как в Roam

Внести вклад Функция
1

Я считаю, что пришло время для Discourse, чтобы появился более быстрый способ создания ссылок на другие темы на данном форуме. Очевидно, что в редакторе уже есть кнопка ссылки и горячая клавиша, и если вы действительно гениальны и знаете точный URL темы, то можете сделать это даже без использования диалога вставки ссылки. Но другие приложения показывают, что может быть лучший, более быстрый и простой способ: вызов диалога поиска и вставки ссылки прямо в тексте.

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

Один из недавно популярных синтаксисов для этого — «ссылки в квадратных скобках», то есть [[ссылка-на-тему]]. Вы вводите [[, и сразу запускается поиск по заголовкам тем, как в поиске пользователей или хештегов. Другой распространённый подход — меню со слэшем (/), хотя оно обычно используется для множества функций. Как бы это ни было реализовано, это сделает создание ссылок между темами супербыстрым и простым, что лично я считаю хорошим шагом, поскольку это поощряет людей ссылаться на другой существующий и связанный контент.

Основная проблема, которую я вижу в этом конкретном синтаксисе, заключается в том, что он отличается от текущего синтаксиса вики, но при этом похож на него. Однако синтаксис вики-ссылок фактически используется в системах, которые также поддерживают синтаксис с двойными квадратными скобками [], но именно для ссылок с пользовательским текстом. Таким образом, один из вариантов — использовать то же различие: двойные скобки для ссылки на тему, где в качестве текста ссылки используется заголовок темы, а традиционная вики-ссылка — для пользовательского заголовка. Другой вариант — изменить общий синтаксис ссылок, что, думаю, мало кому понравится. Третий вариант — выбрать другой синтаксис для вставки ссылок прямо в тексте, то есть другой набор символов, вызывающих поиск ссылок.

Мне не так важно, как именно это будет реализовано, я просто хочу иметь возможность искать и вставлять ссылки прямо в тексте! Я считаю, что это станет отличным дополнением к уже отличному редактору Discourse и другим функциям удобства. :slight_smile:

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

6 лайков
Discourse Wikilinks Plugin
2

Что-то подобное существует при выделении и перемещении сообщений в новую/существующую тему. Честно говоря, в текущем виде это боль:

  • поиск занимает много времени
  • даже если вы знаете название темы и вводите его в точности так, как написано (с правильным регистром и т.д.), поиск не находит нужную тему
  • поиск находит тему, вы её выбираете, но поиск продолжается, не давая вам даже шанса подтвердить выбор. Ваш выбор исчезает, и поиск больше не показывает выбранную вами тему

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

1 лайк
3

Привет, Oshyan, :slightly_smiling_face:

Мне очень нравится идея, но…

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

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

Screenshot_20210815_093116_com.android.chrome
Screenshot_20210815_093116_com.android.chrome1080×2240 168 KB

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

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

1 лайк
4

Всё это звучит как результат неудач в области UI/UX или функций поиска, а не как проблема самой идеи встроенной в текст ссылки. Если вы ещё этого не сделали, я бы предложил вам открыть тему для обсуждения улучшений/исправлений текущего поведения «перемещения постов/объединения», учитывая описанный вами опыт. Но предположим, что в контексте предлагаемого мной подхода к ссылкам таких проблем не возникло: тогда бы вы нашли его полезным?

Почему вы предполагаете, что встроенный поиск будет работать иначе, чем поиск в панели инструментов? Что касается поведения поиска и отображения, он должен работать точно так же и, следовательно, обеспечивать тот же уровень удобства и полезности при поиске и выборе правильной темы. Я бы предпочёл, чтобы он отличался от существующего диалога создания ссылок и был сосредоточен на скорости и простоте использования, работая очень похоже на существующий поиск по @, который показывает небольшой контекстный список результатов. Список результатов мог бы выглядеть точно так же, как в диалоге ссылок, но я не хочу поля для заголовка темы, кнопок «ОК/Отмена» и т. д. Уже существует ярлык, который открывает этот диалог.

Я действительно не понимаю, почему должно быть больше битых ссылок. Вам всё равно нужно нажать Enter, чтобы подтвердить выбранную из поиска тему.

Что ж, оно определённо не «быстрее». Оно может быть более удобным для пользователя, конечно, но мое предложение не заменить существующее создание ссылок через панель инструментов, а добавить более быстрый способ создания ссылок для более опытных пользователей.

Конечно, Ctrl+K (ярлык) — это отличная альтернатива, которая уже существует. Мне просто нравится возможность использовать встроенный синтаксис для вызова полезных функций, и это уже принято в Discourse с @ и #. И то, и другое также можно было бы сделать доступным через сочетания клавиш или ручной ввод без поиска, но, конечно, есть дополнительная ценность в том, как они работают сейчас. Я предлагаю, чтобы создание ссылок получило аналогичную ценность при таком подходе.

2 лайка
5

Ага, понял, спасибо за разъяснение!
Это была бы продвинутая функция, сохраняющая оригинальную панель поиска.
Мне кажется, это хорошая идея. :slightly_smiling_face:

1 лайк
8

Для ясности контекста, то, что у нас есть сегодня, это:

CTRLALTf
поиск по теме
ВНИЗ
a

Например: In-line topic search-and-linking, e.g. Roam-like bracket links

Проблема в том, что это крайне сложно объяснить, но (возможно) предлагает более широкий набор функций, чем предложение с [[.

5 лайков
9

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

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

Мне даже интересно, что у вас возникло достаточно сильное желание быстрого создания ссылок, чтобы создать эту несколько необычную последовательность клавиш (без сомнения, потому что многие другие уже использовались). Это говорит мне о том, что вы, возможно, видите определённую ценность в идее встраивания ссылок в целом… Но у меня сложилось впечатление, что на данный момент моей идее не хватает поддержки. Тем не менее, мне любопытно узнать, есть ли какие-либо явные препятствия для её реализации, например: «Мы используем скобки для чего-то другого», «мы не можем добавить ещё один обработчик в строку, иначе это замедлит все запросы к базе данных на 30%» или что-то в этом роде. :grinning_face_with_smiling_eyes:

В любом случае, надеюсь, это хотя бы пробудило чьё-то внимание. Мне всё ещё хотелось бы иметь такую возможность, и я представляю, что, когда другие пользователи смогут её попробовать, им тоже она понравится (есть ли здесь пользователи Roam? Obsidian? Logseq?). Но хотя бы надеюсь, что я пробудил интерес к идее поиска и создания ссылок в строке, и, возможно, в будущем вокруг этого что-то сформируется. :folded_hands:

1 лайк
10

Я вижу, что [[ магический поиск можно реализовать в компоненте темы уже сегодня.

Единственное ограничение: при завершении [[ будет удаляться и заменяться ссылкой. Не уверен, как ещё это можно реализовать. Из-за этого ]] становится практически бесполезным.

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

2 лайка
11

Это хорошая новость! Как непрограммист, я не до конца понимаю, насколько широкими возможностями обладают компоненты тем (кажется, что очень широкими, и это одна из многих вещей, которые мне нравятся в Discourse). Так что это действительно круто.

Действительно, в другом программном обеспечении синтаксис [[ сохраняется и сохраняет свою ценность даже после добавления ссылки. Или, точнее говоря, поиск по [[ не подставляет обычную ссылку, а создаёт специализированную внутреннюю ссылку. Поскольку несколько приложений поддерживают этот формат ссылок, он переносим в варианте Markdown, что очень удобно.

Но в любом случае, в случае с Discourse [[ — это просто знакомый внутристрочный ярлык, который, к счастью, редко срабатывает случайно. Я был бы рад любому другому текстовому способу вызова внутристрочного поиска, который соответствовал бы аналогичным критериям, но, несмотря на различия в том, как это будет работать в Discourse по сравнению, например, с Roam, я вижу ценность в том, чтобы синтаксис оставался одинаковым. Как я уже сказал, это становится своего рода фактическим стандартом. :thinking:

Другая мысль, которая приходит в голову, заключается в том, что в Discourse уже есть свой аналог внутренних ссылок, которые отображаются особым образом: это то, как работает цитирование! Так что “post:10, topic:200454” по умолчанию создаст ссылку на ваш ответ мне здесь. Поскольку эта функция предназначена специально для внутренних тем, она могла бы просто использовать это и автоматически отображать ссылку на тему во время рендеринга. Я не могу решить, больше ли это соответствует тому, как работает Discourse, или меньше… :grinning_face_with_smiling_eyes:

С одной стороны, уже есть такой способ создания ссылок; это был бы просто другой способ вызова поиска и выбора ссылки, и он очень похож на существующие поиски по @ и #, о которых я упоминал. С другой стороны, это отклоняется от существующего поведения создания ссылок, вызываемого сочетанием клавиш Ctrl+K, панелью инструментов и другими ярлыками. Однако я думаю, что ссылки типа “post:10” больше похожи на концепцию ссылок [[, используемую в других приложениях, поэтому я склоняюсь немного в эту сторону… если бы у меня было какое-то влияние на это. :wink: Конечно, я знаю, что это всё равно больше относится к области компонентов тем, так что, возможно, у меня оно и есть! Может быть, вы сможете высказаться, можно ли реализовать ссылки в стиле “post:10” через всплывающий поиск в компоненте темы?

12

Я только что попробовал Roam в контексте.

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

В прошлом у нас уже были обсуждения о внедрении синтаксиса типа #784, который очень напоминает эту дискуссию.

Как работает Roam:

  1. Вы вводите [[.
  2. Система автоматически добавляет ]] и помещает курсор внутрь.
  3. При вводе текста внутри [[ ]] выполняется автодополняющий поиск. Например:

image
image783×281 14.2 KB

  1. Когда вы окончательно выбираете ссылку, используется полное заглавие, например: [[August 13th, 2021]].

  2. Система автоматически обрабатывает переименования исходного документа, обновляя разметку в документах, где есть ссылки на него.

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

В настоящее время у нас есть:

  • CTRL+SHIFT+F + A … что, хотя и неудобно, работает.

  • Также у нас есть автоматическое раскрытие ссылок и отслеживание обратных ссылок, например: https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454/11 отображается как: In-line topic search-and-linking, e.g. Roam-like bracket links - #11 by oshyan

4 лайка
13

В качестве интересного примера реализации рекомендую посмотреть на https://obsidian.md. Они используют этот синтаксис в Markdown-файлах, и, похоже, он похож на спецификацию, которую описал @sam.

1 лайк
14

Хорошо, вот где мой пример с Roam начинает разваливаться, если воспринимать его слишком буквально. :grinning_face_with_smiling_eyes: На самом деле я перестал пользоваться Roam довольно давно, отчасти потому, что его встроенный поиск ужасен. Obsidian — более подходящий пример, и я сейчас использую его постоянно, но для его проверки требуется загрузка, тогда как Roam (или Logseq) этого не требуют.

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

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

  • Не нужно автоматически дополнять скобку, так как она не будет сохранена в итоговом markdown (в Roam она сохраняется, то же самое в Obsidian).
  • Поиск в Discourse, как, например, поиск ссылок через Ctrl-K или Ctrl-Alt-F, лучше, чем в Roam, и, если он будет реализован внутри строки, вероятно, позволит мне найти интересующую тему за разумное время (то есть, если вы считаете, что поиск полезен хотя бы немного, то он уже удовлетворит описанную здесь потребность).
  • Ссылка будет использовать полное заглавие, точно так же, как если бы вы скопировали/вставили ссылку на тему Discourse в том же форуме в сообщение.
  • Переименование будет обрабатываться так же, как Discourse уже обрабатывает это для внутренних ссылок.

Итак, подводя итог: Roam — это просто пример, демонстрирующий концепцию и часть пользовательского опыта. Что я на самом деле предлагаю:

  • Набор редко используемых, но быстро набираемых символов, которые могут запускать встроенный поиск по темам.
  • Встроенный поиск по темам с автоматическим выбором первого результата при нажатии Enter.
  • Стандартная обработка ссылок в Discourse во всех остальных аспектах.
  • Реализация любым способом, который наиболее соответствует подходу Discourse к подобным вещам.

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

Так что, учитывая всё вышесказанное, изменится ли оценка необходимого объема работы? Если нет, то что именно в этом запросе на функцию делает его настолько более сложным, чем, например, Ctrl-Alt-F + A? Я спрашиваю, потому что это может помочь мне понять, могу ли я сузить область запроса, чтобы сделать затраты разумными, или же это просто не стоит затраченного времени.

Спасибо еще раз!

4 лайка
15

Для меня, чем меньше Discourse совместим с обычным Markdown, тем сложнее становится выполнение некоторых других задач, например, перемещение контента между Discourse и другими системами, использующими Markdown. (Мои сайты и документация обычно используют Markdown или MDX.)

Если такая функция будет добавлена, альтернативной идеей для реализации могло бы стать использование системы, аналогичной Confluence или Notion, где символ / (слэш) открывает меню.

Вот пример из Confluence:

Confluence slash commands
Confluence slash commands641×705 37.2 KB

А вот Notion:

Notion slash commands
Notion slash commands480×436 28.1 KB

Если бы подобная функция была реализована в Discourse, нажатие слэша могло бы открывать меню, включающее опцию «Ссылка». При выборе «Ссылка» пользователь мог бы выполнить поиск по другим сообщениям, и в редакторе была бы вставлена обычная Markdown-ссылка.

Я не прошу внедрить эту функцию, а лишь предлагаю альтернативный вариант реализации, который не привел бы к ещё большему расхождению содержимого raw с обычным Markdown. :slight_smile:

3 лайка
16

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

Вот пример полного рабочего процесса:

  1. Пользователь вводит: [[
  2. Редактор автоматически добавляет ]], а курсор оказывается между скобками.
  3. Пользователь вводит поисковый запрос, например: [[in-line topic]]
  4. По мере ввода выполняется поиск, и результаты отображаются в выпадающем списке, аналогичном @упоминаниям.
  5. Выберите нужный вариант с помощью клавиш вверх/вниз/Enter.
  6. После выбора [[in-line topic]] заменяется на https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454.
  7. Если пользователь просто переместит курсор за пределы ]], автозаполнение закроется, и [[in-line topic]] останется в разметке Markdown.

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

5 лайков
17

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

Отлично, спасибо, что продумали это и дали мне представление о сложности и времени разработки! Это чрезвычайно полезно. Мне нужно будет подумать, смогу ли я выделить часть собственных средств на это, так как у меня есть другие, возможно, более важные запросы, которые, вероятно, нужно финансировать для разработки. И теперь, когда я больше знаю о сочетаниях клавиш, эта функция является скорее удобством, чем необходимостью.

2 лайка
18

Это было бы ещё интереснее, если бы поддерживалась функция «создать именованную ссылку» при добавлении ссылки через a к выделенному тексту. Очень хотелось бы, чтобы в результате получалось [выделенный текст](ссылка).

К сожалению, похоже, это действие не добавляется в буфер отмены.

2 лайка
19

Другие хорошие примеры рабочих процессов ввода с использованием / и [[ ]], на которые можно ориентироваться, представлены на сайтах

и

3 лайка
20

Концепция системы управления личными знаниями (PKM) в сочетании с форумом действительно опережает время и обладает огромным потенциалом. Она не является «новой» (например, см. «Bliki» от 2003 года), но это и не обязательно. Контекст изменился, и поэтому сама идея обретает новую актуальность. Рынок PKM стремительно растет, потому что каждый ищет нечто похожее на то, что вы описываете, но такого решения пока не существует. При этом я не считаю, что вики-ссылки были бы правильным решением; гораздо лучше подошла бы функция «ссылка на выделение», встроенная в Discourse (как улучшение или вариация текущей функции цитирования). Кнопка «Поделиться», появляющаяся при выделении текста в посте, должна предоставлять URL, а также возможность создать новую тему на форуме, используя цитату (последняя функция сейчас скрыта за тремя кликами и работает не совсем корректно). Однако я понимаю, что создание вики-ссылок на темы, которых еще не существует, может быть полезным: такие ссылки становятся вики-постами, когда кто-то переходит по ним и создает соответствующую тему.

Я считаю, что ваш Garden — это превосходный proof of concept, который во многом ограничен тем, что он собран на скорую руку на базе Discourse (как вы думаете, он бы лучше работал как вики, как зеттелькастен или как экземпляр Circle/Notion?). Общий PKM легко может развалиться, если качество постов не будет строго контролироваться: глубокий, но бесполезный контент может закрепиться, если нет возможности оценить его качество до перехода по ссылке. Форумы справляются с открытой совместной генерацией знаний гораздо лучше, чем традиционные PKM-системы. Вот интересный промежуточный пример: на LessWrong есть система «сообщественного блога», которая на самом деле является форком Reddit, и она блестяще работает для их целей. Это позволяет им избежать проблемы, когда все участники должны сразу быть экспертами в своем деле; пользовательские материалы (посты и коллекции постов, похожие на плейлисты) не являются каноническими (в отличие от вики, где обычно есть только одна статья на тему).

3 лайка
21

Некоторые аспекты были бы лучше, но другие заметно хуже. Для моих целей я определённо ограничен Discourse в некоторых важных отношениях, но, на мой взгляд, одна из главных проблем — это просто навигация, которую, кажется, можно относительно легко решить, если есть желание и, соответственно, ресурсы разработчиков. У меня есть идея, которую я скоро предложу (с некоторым финансированием), и надеюсь, что она поможет.

Также считаю ценным задуматься о расширении концепции «Модератора» в контекстах, связанных с генерацией знаний, превратив её в нечто большее, похожее на «Куратора». Индивидуальная генерация знаний объединяет роли и деятельность генератора и куратора. Однако коллективная генерация знаний, вероятно, требует — или, по крайней мере, значительно выиграла бы от — наличия доверенных людей, чья роль или часть их фокуса заключается в цитировании, продвижении, организации, полировке и ином выделении контента, идей и т.д., созданных другими, делая их более доступными для тех, кто может извлечь из этого пользу. Теоретически функциональность вики в Discourse могла бы стать частью решения этой задачи, но её потребовалась бы доработка.

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

В конечном счёте проблема заключается в том, что CDCK, вероятно, не особенно заинтересована в таком использовании Discourse (что я понимаю: их полезность и, следовательно, потенциал для получения дохода на данном этапе гораздо более незрелые и неясные). Тем временем немногие — если вообще есть какие-либо — другие платформы, которые фокусируются на генерации знаний, например, Wikipedia/MediaWiki, действительно хорошо справляются с аспектами беседы и обсуждения, особенно с взаимодействием между ними. В идеальном мире качественное обсуждение на протяжении длительного времени могло бы постепенно дополнять дистиллированный вывод знаний, идей, перспектив легко и плавно, сохраняя атрибуцию и одновременно позволяя создавать хорошо оформленные, согласованные «документы»/артефакты, которые было бы приятно читать. Wikipedia снова является хорошим примером текущей рабочей модели, но она крайне несовершенна, и необходимы новые инструменты и методы, чтобы выйти за рамки простого документирования знаний к реальному генерированию инсайтов, исследованию новых идей и т.д.

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

4 лайка