Блочные интерфейсы — путь к структурированным данным

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

Речь идет о том, что мечта о возможности просто и быстро создавать структурированные данные в Интернете, чтобы показывать их потом в разных контекстах без дополнительной трудоемкости, становится реальностью. Сейчас мы наблюдаем рост популярности платформ с блочными интерфейсами, но пока есть сложность в интеграции между ними. Расскажем об истории структурированных данных, о проблемах и ​​преимуществах блочных интерфейсов, и представим новый стандарт для работы с блочной информацией (не имеет ничего общего с Web3, блокчейн или NFT), который может решить ряд проблем как со структурированными данными, так и с интеграцией блочных редакторов различных разработчиков.

Блочные интерфейсы могут помочь вам создавать более структурированные данные в сети.

Почему мы вообще должны заботиться о структурированных данных?

Действительно, почему стоит мечтать о мире, в котором у нас будет больше структурированных данных, чем сейчас?

Сеть наполнена контентом — статьи, комментарии, описания, изображения, заголовки, видео и все остальное. Но наши компьютеры понятия не имеют, о чем этот контент, они не понимают смысла. И это потому, что его никто не структурировал. Т.е. при создании автор не дополнил содержание метаданными (не пометил содержимое так, чтобы оно было понятно не только читателям, но и алгоритмам).

Представьте, что вы хотите найти книгу, например «Выдох» Теда Чанга. При вводе стандартного поискового запроса по слову «выдох» вы получите результаты выдачи как о книге, так и о методах дыхания или медицинских проблемах. Алгоритм поисковика не знает разницы между выдохом в виде книги и выдохом в биологической концепции. Но это можно исправить.

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

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

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

Чтобы дать вам практический пример того, как это выглядит, посмотрите как выглядят неструктурированные данные для веб-сайта об этой конференции. У нас есть заголовок в теге <h1>, и описание, время и местоположение в тегах <p>.

Если взять и ту же информацию о событии, структурировать и записать в формате JSON-LD (связанные данные JSON), который в настоящее время является самым популярным и широко используемым форматом.

Мы увидим, что событие имеет тип «Event», а так же такие свойства, как «дата начала» и «дата окончания». У события есть местоположение типа «Place» , которое, в свою очередь, имеет «Address»

Звучит очень знакомо, верно? Это же и есть семантическая паутина или Semantic Web. Это мечта, которая началась более 20 лет назад, когда Тим Бернерс-Ли (MIT) написал статью «Семантическая сеть: новая форма веб-контента, значимая для компьютеров, откроет революцию новых возможностей» о грандиозных возможностях сети, которые откроются, если и когда смысл человеческой информации станет доступен алгоритмам.

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

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

Проблемы Semantic Web

Культура описаний одинаковых объектов разная

Онтологии — то есть модели, в которых мы определяем и связываем такие понятия, как «Человек» или «Книга», — всегда культурно относительны, субъективны и зависят от контекста. Не существует универсального единого набора свойств, с которым мы все могли бы согласиться. Это связано с тем, что человеческая культура многообразна, у всего есть много точек зрения и версий правды, что и составляет весь смысл человеческой культуры. Это механизм создания совершенно разных способов видения и существования в мире. Настолько разнообразное, что невозможно договориться об основных категориях и свойствах того, что существует вокруг нас.

Возьмем, к примеру, тип «Человек». В самом большом и широко используемом репозитории схем schema.org (поддерживаемый Google), у «Person» есть свойства «имя» и «фамилия». Но во многих культурах у людей нет имен и фамилий. Так людей не называют. У людей может быть несколько личных имен, фамилий и названий кланов, которые меняются в зависимости от того, кто к ним обращается и в каком контексте. Ни один из них не помещается аккуратно в две окна на форме ввода данных.

Точно так же тип «Postal Address» может показаться чем-то с жесткой структурой. В таких странах, как Великобритания, есть строгие форматы для номеров домов, названий улиц и почтовых индексов. Но в некоторых местах уличные адреса не были стандартизированы и формализованы их правительствами. Чей-то адрес может быть таким: «пройдите 200 метров мимо храма, это четвертый дом слева». Попробуйте поместить это в свою схему.

Много конкурирующих форматов

На протяжении многих лет люди предлагали множество различных способов реализации структурированных данных в Интернете. Есть RDF и RDFs, JSON-LD и Microformats.

Кроме того, есть все платформы аннотаций, языки запросов и словари, которые взаимодействуют с этими форматами, например OWL, FOAF, SPARQL, Turtle и другие.

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

Большая трудоемкость и проблемы мотивации

Чтобы добавить семантическую разметку на веб-сайт, разработчику требуется много труда, а взамен это не приносит немедленной выгоды. Структурированные данные, безусловно, могут улучшить поисковую оптимизацию (SEO) и обнаружение контента вашей целевой аудиторией, но кроме этого мы не нашли для веб-мастеров достаточных убедительных аргументов для разметки контента.

Амбициозный масштаб Semantic Web ошеломляет

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

Дебаты о семантической паутине привели к появлению двух противоборствующих лагерей.

Кажется, что такие полярные утверждения не оставляют места для компромисса.

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

Не сама идея была проблемой, проблемой стал масштаб. Мечта имеет шанс воплотиться.

В чем польза от структурированных данных?

Поисковая оптимизация сайтов (SEO) и «расширенные результаты» в поисковых системах

Структурирование контента на сайтах уже давно и активно используется веб-мастерами и разработчиками.

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

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

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

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

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

Обеспечение адаптивного и более сложного UX

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

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

Структурированные данные облегчают работу специалистам по данным и ученым.

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

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

Сдвиг к структурированным данным

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

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

Практический вопрос, который мы все должны задать: как нам сдвинуть стрелку вправо?

Цель — более структурированные данные, а не все структурированные данные.

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

Большая часть внимания семантического веб-движения была направлена ​​на создание синтаксических форматов, таких как RDF, OWL и JSON-LD. Также было приложено много усилий, чтобы убедить разработчиков присоединиться к делу. Но разработчики не создают контент, они делают веб-ресурсы. А профессиональные создатели контента, таких как дизайнеры, специалисты по продуктам и специалисты по контент-стратегии, имеют серьезный порог входа для понимания и работы с текущими инструментами разметки и структурирования данных. Пока это больше похоже на код с грубым пользовательским интерфейсом для работы. И он определенно недоступен для большинства людей.

Как упростить создание структурированных данных для всех людей, не программистов?

Появление блоков на платформ пользовательского контента

За последние 5 лет все мы наблюдали огромный всплеск блоков и составных интерфейсов. И вы почти наверняка видели или использовали блоки в каком-то из приложений.

Но сначала, что именно подразумевается под «блоком»?

Большинство из вас сталкивались с блоками в таких приложениях, как Notion, что, возможно, является причиной огромного бума популярности блоков.

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

По сути, вы можете создавать очень мощные макеты и форматы с очень простым набором шаблонов интерфейса.

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

Можно легко встраивать мультимедийные материалы, такие как твиты, или запрашивать внешний API, например библиотеку изображений Unsplash. Все из удобного набора компонентов пользовательского интерфейса и без написания кода.

Это может показаться вам не таким впечатляющим. Мы немного устали от интерфейсов такого типа. Интерфейсы прямого управления WYSIWYG считаются само собой разумеющимся. Но создать что-то подобное было бы запредельно сложно еще 5 лет назад.

Все это очень сложно сделать, если вы работаете с родными веб-языками, такими как HTML, CSS и JS. Для людей, которые не умеют программировать, блочные интерфейсы позволяют создавать мультимедийные документы и публиковать их в Интернете за пару кликов. Это огромный шаг вперед в демократизации веб-публикаций.

Шаблоны интерфейса в блочных редакторах уже стали достаточно последовательными и стандартизированными. В большинстве из них вы можете ввести /и получить раскрывающийся список параметров блокировки.

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

Итак, теперь, когда мы увидели пару примеров блочных интерфейсов, можно дать определение понятию «блок».

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

Блок «таблица» размещает данные в строках и столбца, в то время как блок «канбан» размещает данные в наборе карточек.

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

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

Эти типы интерфейсов и платформ, очевидно, стали очень мощными и популярными. Как сказал основатель компании HASH Джоэл Спольски: «Великие горизонтальные приложения-убийцы на самом деле просто причудливые структуры данных».

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

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

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

Неудивительно, что блочные приложения начали появляться повсюду. Они делятся на три основные категории.

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

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

Третью категорию, которая только начинает формироваться, можно называть «SaaS-конструктор для моделирования данных и автоматизации». Эти приложения дают пользователям возможность создавать свои собственные интерфейсы с гораздо большим количеством встроенных программных функций. Обычно вы можете запрашивать отдельный источник данных, добавлять логику «если это / то это» к элементам и определять более продвинутые функциональные возможности блоков, такие как фильтруемые списки и раскрывающиеся списки-селекторы. Вместо подписки на 10 различных сервисов SaaS эти приложения позволяют создавать собственные решения.

Границы между этими 3 категориями довольно размыты. Это целый спектр блочных парадигм. Каждое приложение работает немного по-разному. Кто-то представляет его как документ, кто-то — как веб-сайт, а кто-то — как полноценное приложение.

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

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

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

Блочные приложения передают пользователю власть над данными

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

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

Если бы 5 лет назад вы хотели бы разместить таблицу данных на веб-сайте, пришлось бы нанимать разработчика либо самому писать для этого HTML, CSS и JS. И это определенно не было бы так хорошо, как таблица Coda или Notion. А теперь вы сможете сделать это в два клика.

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

В чем проблема и как это относится к структурированным данным?

Во-первых, блоки принадлежат отдельным приложениям и не могут перемещаться между приложениями. Если у вас есть любимый блок в одном из приложений, вы не можете использовать его в другом приложении.

Вторая причина тесно связана с первой: огромное количество часов разработчиков тратится на повторное изобретение одних и тех же блоков снова и снова.

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

Если мы посмотрим на блок канбан в Notion, Coda и ClickUp, мы заметим, что все они работают одинаково. Они предлагают одинаковую базовую функциональность, формат и взаимодействие. Но разработчикам пришлось создавать каждый из них отдельно.

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

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

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

Сравните это с тем, к чему имеет доступ ваш повседневный разработчик React. Если перейти на npm и набрать «компоненты React», то выдача составит более 64 000 результатов на выбор. Очевидно, что не все эти компоненты будут блочными. Многие будут утилитами или помощниками. Но это по-прежнему показывает, что существует огромное несоответствие между возможностями и выбором, которые есть у разработчиков при создании интерфейса по сравнению с обычными пользователями.

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

Таблица в WordPress Gutenberg и таблица в Notion на первый взгляд имеют одинаковую структуру данных. У них обоих есть значения, хранящиеся в строках, которые являются столбцами. Но они построены по-разному на задней части. Они не предназначены для совместного использования. Это означает, что мы не можем легко передавать данные из таблицы Gutenberg в таблицу Notion.

Открытый стандарт для построения блочных интерфейсов

Встраивание блоков

Обмен данными

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

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

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

Преимущества для пользователей

Почему нас волнует, что все это встраивание, обмен данными и интерактивность возможны?

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

Преимущество для разработчиков приложений

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

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

И наконец, стандартный протокол упрощает создание структурированных данных и обеспечивает их большую совместимость.

Упрощение структурирования данных

Дизайн — это поиск формы, соответствующей контексту

Кристофер Александер

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

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

Все это выглядит как прекрасная идея, но многие могут подумать о том, что легко сказать, но трудно реализовать.

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

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

Разработчики декларируют масштабную цель всего этого проекта — создать благотворный цикл положительной обратной связи между действиями обычного пользователя и улучшением связности всей Semantic Web.

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

Положительная обратная связь частного и общего циклов использования стандарта

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

Автор: Мэгги Эплтон

Курирование и адаптация: Онтограф

Ссылки:

• Видео выступления Мэгги Эплтон на конференции по структурированным данным летом 2022 г:

• Текст презентации о блочных интерфейсах и новом стандарте (англ.)
• Сайт конференции по структурированному контенту в Сан-Франциско, май 2022 г.
• Открытый стандарт для построения блочных интерфейсрв