Я помню, как выглядело программирование в эпоху «до Windows». Даже после революции языков программирования (которая шла в несколько этапов, из них я видел только последний – переход к ООП) оно было крайне низкопродуктивным. В первую очередь, из-за необходимости в каждом проекте тратить значительное время на разработку велосипедов пользовательского интерфейса – графического ли, текстового ли – не столь важно в данном контексте.

А потом появился Windows API, и стало возможно тратить время не на отладку поведения курсора, нажатия кнопки и прочих деталей синтаксического, а то и лексического уровня, а на осмысление и проектирование User Experience. Уровень пользовательских интерфейсов революционно вырос, порог вхождения наивного пользователя в возможность сделать что-то для себя полезное с помощью наших программных продуктов – упал.

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

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

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

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

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

Средством продвижения революционного API в прошлый раз стала специально под него созданная операционная система. Из того, что в предлагаемой системе через API должны происходить взаимодействия пользователей, «носителем» нового API должна являться социальная сеть. В 2011-2012 году можно было предположить, что по данному пути будет развиваться Facebook, но они полностью дискредитировали свой API в качестве универсальной платформы приложений ещё до того, как получили массовую поддержку независимых разработчиков, и упустили свой шанс.

Вместе с тем, в последующие годы новых попыток не делалось, и, более того, представляется весьма ограниченным набор акторов, ментально способных выдержать подобную концепцию – очевидно, что в силу существования у них собственных операционных систем, на неё не способны Apple и Google. Microsoft уже являлся автором революции подобного масштаба в прошлом и, потому, вряд ли сможет что-то подобное делать ещё раз, Facebook истратил свою попытку.

В связи с тем, что в настоящее время Facebook ощутимо теряет популярность и в качестве традиционной социальной сети, и единой альтернативы ему нет, как представляется сейчас крайне удачное время попытаться развернуть альтернативную социальную сеть, используя в качестве «разгонного модуля», например, один из популярных мессенджеров, либо одну из глобальных торговых систем.
Как представляется, пользовательский интерфейс собственно приложения социальной сети должен строиться по модульному принципу с возможность замены большинства пользовательских функций сторонними приложениями по желанию пользователя. То есть, если пользователю не нравится, например, «штатная» лента – он может найти ленту от альтернативных разработчиков (например, с более гибким дизайном, дополнительными возможностями фильтрации, управляемым набором «лайков», и тому подобным), использующую тот же набор данных и, скорее всего, реализованную на тех же технических принципах.

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

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

Предполагаемая технологическая платформа структурно должна иметь три уровня программных средств и два слоя протоколов, представленных на прилагаемой схеме:
1. Базовый уровень: ядро и сервисные функции (содержащий ключевые и общеупотребительные сервисные функции платформы)
2. Уровень приложений (содержащий «штатные» и альтернативные приложения)
3. Прикладной уровень (уровень, с которым взаимодействуют пользователи).

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

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

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

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

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

30 марта 2020 года

Примечания и приложения

Упоминание в схемах именно телеграма объясняется тем, что, по некоторым соображениям, концепция писалась под углублённое взаимодействие именно с Телеграмом. По факту следует читать "мессенджер". Схемы можно посмотреть подробнее.

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

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