Допустим, что мы с помощью скрипта и стилей получили решение сборника юзерскриптов для сайта, идея которого давно витала в воздухе и высказывалась в виде пожеланий многими, в комментариях к почти каждой статье о юзерстилях. В начале года даже наблюдалась реализация подобного решения — github.com/silentroach/habrafix, которая с 3.10.2011, очевидно, тоже не работает. В простом исходном виде решение было бы трудно поддерживать — сборкой скриптов должен бы заниматься один человек, поддерживать все браузеры, добавлять новые возможности по желанию других пользователей или, в лучшем случае, рассматривать форки и объединять их функциональность.
Большая проблема будет в «сизифовом труде» над скриптами. Представление сайта и скриптов на них регулярно меняется силами официальных разработчиков, реализация каждой новой мелкой функциональности требует продумывания, решения, отладки. При смене представления сайта нужно всем, кто делал юзерскрипты, внезапно спохватиться, побежать восстанавливать и перетестировать все функции. Хорошо, если функция одна и тестирование в браузерах занимает день, вечер, 2 часа. Меньше — не всегда возможно, потому что есть 5 браузеров, версии браузеров, несколько типов страниц сайта, на которых решение (скрипт или часть его) работает. Тестовые случаи умножаются и сократиться комбинаторное число может только эвристиками находящихся в теме разработчиков. Если это сборник скриптов, автор сборника должен на каждое движение разработчиков перетестировать каждую функцию (или интуитивно догадаться, что сломалось, зная все зависимости на сайте и в скриптах).
Посмотрим, сколько скриптов восстановилось после 3.10.2011. Просто сделаем поиск: userscripts.org/scripts/search?q=habrahabr&submit=Search, другие слова для поиска — «хабр», «habr». Всё, что выше указанной даты (6 штук), то авторы скриптов сумели сделать после разрушений. Остальные скрипты, вероятнее всего, не работают (12 штук только за 2011 год, 16 за 2010-й, ещё 20 за более ранние), хотя каждый, конечно, можно восстановить указанными манипуляциями и тестированием. Но большая часть авторов, очевидно, что уже не хотят заниматься решением или его публикацией. Что легко понять — скрипт был, чаще всего, результатом вдохновления идеей, а возврат к пройденным решениям — это не всегда интересно и нужно.
Если посмотреть на сборники браузерозависимых скриптов, мы увидим похожий и немного другой набор реализованных идей, часть которых тоже не смогла или не успела восстановиться после 3.10.2011.
Чтобы обойти системные проблемы, нужно сделать системные решения. Какие? Перечислим в порядке «мозгового штурма».
, собирающий не только статьи авторов, но и ссылки с других ресурсов на статьи, интересные решения, со своей организацией, со своей командой разработки. Так проблемы, не решаемые Хабром, перейдут под ведение других людей, которые, может быть, будут более отзывчивы к нововведениям, слушать пожелания, обеспечат краудсорсинговое развитие автоматики сайта.
Что будем иметь? Допустим, команда собралась и какое-то время может кое-что сделать на энтузиазме или с помощью венчурного финансирования. За время выхода на самоокупаемость или самоподдержку она должна успеть:
* Привлечь большое количество людей, достаточных для самоподдержания общественности (комьюнити) и интереса к посещениям и высказываниям — сделать среду, приносящую пользу для посетителей. Как видно по опыту подобных ресурсов, это возможно при выполнении ряда требований: актуальность информации, приход авторитетных в некоторых темах людей и выполнение достаточно известных принципов сетевого этикета пользователями и администраторами.
* Чтобы улучшить интерфейсы — быть реагирующими на пожелания и тенденции.
* Чтобы совместить достоинства различных ресурсов — обеспечить удобное чтение статей других ресурсов с обсуждением у себя.
Многие узнаЮт в описанной схеме Reddit.com, с примесью digg.com, с примесью RSS-лент сторонних сайтов (например, как Google Reader) и ещё одного ресурса, старательно выпиленного из. Что ж, схема жизнеспособна, требуется группа энтузиастов (объявляется запись, и, кроме того, уже на Хабре есть люди, которые ко мне обращались с похожей группой идей с тем, чтобы я стал участником. Возможно, стоит объединить идеи и ресурсы и выступить некоторой группой).
Но этим группа предложений не ограничивается, статья не об этом, а о более глубокой сути. Как ещё мы можем реализовать более жизнеспособную поддержку юзерскриптов от различных авторов?
Отдавая себе отчёт в неудобствах и «сизифовости» работ над юзерскриптами, попробуем, всё же построить мало-мальски жизнеспособную схему проектирования. Трудность поддержки жизнеспособности — в сильной зависимости от родительского сайта и отсутствие какой-либо поддержки от него. В таких условиях можно побороться и поддерживать жизнь проекта распределением работ по плагинам, например.
Пишется базовая функциональность, которая будет нужна во всех скриптах сайта и которая довольно легко осваивается, с минимумом хитростей, с простотой документации. Это — способ подключения плагина, единые настройки плагинов, соглашение о контроле версий, соглашение о точках подключения скриптов и стилей. Далее, в основном скрипте (точнее, в утилитах к нему) независимо от плагинов может писаться сборщик проектов под конкретные браузеры. Он поможет на основе разделённых заранее блоков строить расширения браузеров автоматически, а в базовой функциональности будет работать универсальный скрипт *.user.js, поддерживающий с деградацией максимум функциональности.
Кратко суть для тех, кто в курсе. Функциональность расширений увеличивается по сравнению с базовым скриптом за счёт более глубокого внедрения участков кода в другие места подключения. Например, свои изображения в базовом скрипте можем задать через base64-стиль, а в расширении можем использовать изображения. Стили можем подключить только в одной точке — в конце страницы, как и выполнить скриты. В расширениях можем запускать некоторые скрипты раньше и в другом окружении. Этим воспользуемся для повышения качества загрузки страницы. Следовательно, исходный код как основного скрипта, так и плагинов будет иметь 4 секции как минимум. В зависимости от особенностей сайта число секций может увеличиться, зависеть от групп HTML-страниц. Тем не менее, писателю плагина будет понятна схема, в которой он может быстро написать расширение для сайта и включить разными способами, вплоть до сборки единого скрипта под некоторый браузер (в перспективе).
Попытка прохождения такого пути будет сделана, потому что наработки на нём уже есть и они помогают моделировать интерфейсы работы с текстами. Отдавая отчёт в том, что она может никого не заинтересовать, потому что писателей — единицы и всегда проще написать независимый скрипт, чем плагин.
Наконец, видится ещё один путь ослабления «сизифовости» работ — препарируемый родительский сайт должен быть использован по минимуму и по сути. То есть, брать из него не контент + вёрстку, как делают все скрипты, а только контент. Тогда избавляемся от ряда минусов:
*) не зависим от вёрстки — огромное облегчение. От вёрстки будет зависеть только парсер, тут никуда не деться, но он обычно достаточно прост. Тогда, если вёрстка меняется, сначала рушится всё (или то, что поменялось), но после починки парсера продолжат работать все скрипты и плагины, строящие представление, потому что они будут на своей стабильной вёрстке.
*) наработки используются для другого контента — достаточно написать парсер другого сайта — и имеем работу всех ранее сделанных наработок под полученную структуру данных.
*) это более сложно, чем RSS, но RSS может быть альтернативой, официальным поставщиком контента на случай ломки основного поставщика — сайта.
*) не зависим от ошибок скриптов на родительских страницах. Сейчас при ошибке JS на странице рушится и юзерскрипт — очень неинтересная зависимость от проблем с разработчиками на сервере. Какие-то скрипты придётся дублировать и запускать из-за ajax-подгрузки данных на родительском сайте, но тут есть баланс интересов — или мы получаем свою систему получения чужого контента, или полностью доверяем скриптам поставки, но они имеют риск разрушить и наши скрипты (в общем, есть техники обхода таких проблем, главное, что о них не надо забывать, даже если месяцами всё работало стабильно).
Каковы минусы?
*) все ajax-запросы должны повторить в своих скриптах или использовать запуск сайтовых скриптов для обмена данными.
*) разработчику плагина надо работать не со страницей (что просто — посмотрел Ctrl-U, и всё видно), а с категориями данных: сообщение, автор, дата, ответы, автор, дата, оценка, сайтовые функции голосования, отправки сообщений и т.д.. Это сложнее (для автора парсера тоже), но перекрывается огромным плюсом независимости от вёрстки, при условии, что есть парсер. Значит, и плагин, написанный 2-3 года назад, будет работать, если касается представления, а 80-90% плагинов — такие. Но и часть функций работы с данными тоже можно отслоить от сайтов, чтобы операции «отправить ответ» или отправка оценки не зависели от реализации.
*) разработчику парсера надо хорошо продумать систему, чтобы она оставалась простой для разработчиков плагинов. Перекрывается плюсами расширения базы разработчиков.
Эта, третья идея видится более перспективной, поэтому по ней тоже объявляется набор исполнителей и спонсоров.
Есть другие соображения, как надо развивать полученную систему для устранения очередных отрицательных факторов — удаленные сообщения и статьи, падение серверов, но они выходят за рамки обсуждаемого вопроса о скриптах.
Есть 3 различных пути привлечения разработчиков для улучшения качества представления данных на сайте. Они различны по трудозатратам и схеме монетизации — от нулевой до весьма полноценной. Простые скрипты имеет смысл собрать в один плагин для того, чтобы иметь не только полезный инструмент для гиков, но и модель для гибкого тестированя юзабилити на реальных данных и собственном опыте. Для наработок некоторых идей, которые можно применить в других местах. Этот путь — наименее затратный и приносящий косвенные выгоды разработчикам в виде накопления их опыта.
Но на такую систему разрушающе действует произвол разработчиков сайта, поэтому в архитектуру скриптовой прослойки неплохо было бы включить отделение структуры данных от вёрстки. Такого рода проект можно тоже начать как общественный, с выходом на охват не только одного сайта, с лучшей защитой информации от потери, с более глубокой прокачкой скиллов разработчиками. Вполне возможно, что после проекта такого уровня команда разработчиков приобретёт опыт, полезный для других подобных по уровню коммерческих проектов, это будет хорошей саморекламой и опытом.
Наконец, возможно и привлечение венчурных коммерческих структур, как на начальном этапе, так и позже, для создания амбициозного и необычного проекта, сочетающего в себе решение подмеченных и перечисленных в данном тексте системных проблем. По первым двум уровням есть проработанная стратегия развития, правда, с неясной шириной охвата аудитории. Возможно, некоторые из читателей смогут продумать маркетинговую сторону вопроса в необычной плоскости — не в среде гиков, а в несколько другой, и это будет перспективнее. Третий уровень требует проработки распределённой системы серверов, что далеко выходит за пределы вопросов о скриптах и о представлении данных в браузерах. Следовательно, лучше, чтобы к этой части подключились люди (одного достаточно) — архитекторы серверной части.
Итого, все 3 направления актуальны и выражают подход, более ориентированный на качество представления данных в социальных сетях.
Большая проблема будет в «сизифовом труде» над скриптами. Представление сайта и скриптов на них регулярно меняется силами официальных разработчиков, реализация каждой новой мелкой функциональности требует продумывания, решения, отладки. При смене представления сайта нужно всем, кто делал юзерскрипты, внезапно спохватиться, побежать восстанавливать и перетестировать все функции. Хорошо, если функция одна и тестирование в браузерах занимает день, вечер, 2 часа. Меньше — не всегда возможно, потому что есть 5 браузеров, версии браузеров, несколько типов страниц сайта, на которых решение (скрипт или часть его) работает. Тестовые случаи умножаются и сократиться комбинаторное число может только эвристиками находящихся в теме разработчиков. Если это сборник скриптов, автор сборника должен на каждое движение разработчиков перетестировать каждую функцию (или интуитивно догадаться, что сломалось, зная все зависимости на сайте и в скриптах).
Посмотрим, сколько скриптов восстановилось после 3.10.2011. Просто сделаем поиск: userscripts.org/scripts/search?q=habrahabr&submit=Search, другие слова для поиска — «хабр», «habr». Всё, что выше указанной даты (6 штук), то авторы скриптов сумели сделать после разрушений. Остальные скрипты, вероятнее всего, не работают (12 штук только за 2011 год, 16 за 2010-й, ещё 20 за более ранние), хотя каждый, конечно, можно восстановить указанными манипуляциями и тестированием. Но большая часть авторов, очевидно, что уже не хотят заниматься решением или его публикацией. Что легко понять — скрипт был, чаще всего, результатом вдохновления идеей, а возврат к пройденным решениям — это не всегда интересно и нужно.
Если посмотреть на сборники браузерозависимых скриптов, мы увидим похожий и немного другой набор реализованных идей, часть которых тоже не смогла или не успела восстановиться после 3.10.2011.
Чтобы обойти системные проблемы, нужно сделать системные решения. Какие? Перечислим в порядке «мозгового штурма».
* ещё один «хабр»
, собирающий не только статьи авторов, но и ссылки с других ресурсов на статьи, интересные решения, со своей организацией, со своей командой разработки. Так проблемы, не решаемые Хабром, перейдут под ведение других людей, которые, может быть, будут более отзывчивы к нововведениям, слушать пожелания, обеспечат краудсорсинговое развитие автоматики сайта.
Что будем иметь? Допустим, команда собралась и какое-то время может кое-что сделать на энтузиазме или с помощью венчурного финансирования. За время выхода на самоокупаемость или самоподдержку она должна успеть:
* Привлечь большое количество людей, достаточных для самоподдержания общественности (комьюнити) и интереса к посещениям и высказываниям — сделать среду, приносящую пользу для посетителей. Как видно по опыту подобных ресурсов, это возможно при выполнении ряда требований: актуальность информации, приход авторитетных в некоторых темах людей и выполнение достаточно известных принципов сетевого этикета пользователями и администраторами.
* Чтобы улучшить интерфейсы — быть реагирующими на пожелания и тенденции.
* Чтобы совместить достоинства различных ресурсов — обеспечить удобное чтение статей других ресурсов с обсуждением у себя.
Многие узнаЮт в описанной схеме Reddit.com, с примесью digg.com, с примесью RSS-лент сторонних сайтов (например, как Google Reader) и ещё одного ресурса, старательно выпиленного из. Что ж, схема жизнеспособна, требуется группа энтузиастов (объявляется запись, и, кроме того, уже на Хабре есть люди, которые ко мне обращались с похожей группой идей с тем, чтобы я стал участником. Возможно, стоит объединить идеи и ресурсы и выступить некоторой группой).
Но этим группа предложений не ограничивается, статья не об этом, а о более глубокой сути. Как ещё мы можем реализовать более жизнеспособную поддержку юзерскриптов от различных авторов?
* юзерскрипт с поддержкой плагинов и базовых функций
Отдавая себе отчёт в неудобствах и «сизифовости» работ над юзерскриптами, попробуем, всё же построить мало-мальски жизнеспособную схему проектирования. Трудность поддержки жизнеспособности — в сильной зависимости от родительского сайта и отсутствие какой-либо поддержки от него. В таких условиях можно побороться и поддерживать жизнь проекта распределением работ по плагинам, например.
Пишется базовая функциональность, которая будет нужна во всех скриптах сайта и которая довольно легко осваивается, с минимумом хитростей, с простотой документации. Это — способ подключения плагина, единые настройки плагинов, соглашение о контроле версий, соглашение о точках подключения скриптов и стилей. Далее, в основном скрипте (точнее, в утилитах к нему) независимо от плагинов может писаться сборщик проектов под конкретные браузеры. Он поможет на основе разделённых заранее блоков строить расширения браузеров автоматически, а в базовой функциональности будет работать универсальный скрипт *.user.js, поддерживающий с деградацией максимум функциональности.
Кратко суть для тех, кто в курсе. Функциональность расширений увеличивается по сравнению с базовым скриптом за счёт более глубокого внедрения участков кода в другие места подключения. Например, свои изображения в базовом скрипте можем задать через base64-стиль, а в расширении можем использовать изображения. Стили можем подключить только в одной точке — в конце страницы, как и выполнить скриты. В расширениях можем запускать некоторые скрипты раньше и в другом окружении. Этим воспользуемся для повышения качества загрузки страницы. Следовательно, исходный код как основного скрипта, так и плагинов будет иметь 4 секции как минимум. В зависимости от особенностей сайта число секций может увеличиться, зависеть от групп HTML-страниц. Тем не менее, писателю плагина будет понятна схема, в которой он может быстро написать расширение для сайта и включить разными способами, вплоть до сборки единого скрипта под некоторый браузер (в перспективе).
Попытка прохождения такого пути будет сделана, потому что наработки на нём уже есть и они помогают моделировать интерфейсы работы с текстами. Отдавая отчёт в том, что она может никого не заинтересовать, потому что писателей — единицы и всегда проще написать независимый скрипт, чем плагин.
* ещё один путь — семантические скрипты
Наконец, видится ещё один путь ослабления «сизифовости» работ — препарируемый родительский сайт должен быть использован по минимуму и по сути. То есть, брать из него не контент + вёрстку, как делают все скрипты, а только контент. Тогда избавляемся от ряда минусов:
*) не зависим от вёрстки — огромное облегчение. От вёрстки будет зависеть только парсер, тут никуда не деться, но он обычно достаточно прост. Тогда, если вёрстка меняется, сначала рушится всё (или то, что поменялось), но после починки парсера продолжат работать все скрипты и плагины, строящие представление, потому что они будут на своей стабильной вёрстке.
*) наработки используются для другого контента — достаточно написать парсер другого сайта — и имеем работу всех ранее сделанных наработок под полученную структуру данных.
*) это более сложно, чем RSS, но RSS может быть альтернативой, официальным поставщиком контента на случай ломки основного поставщика — сайта.
*) не зависим от ошибок скриптов на родительских страницах. Сейчас при ошибке JS на странице рушится и юзерскрипт — очень неинтересная зависимость от проблем с разработчиками на сервере. Какие-то скрипты придётся дублировать и запускать из-за ajax-подгрузки данных на родительском сайте, но тут есть баланс интересов — или мы получаем свою систему получения чужого контента, или полностью доверяем скриптам поставки, но они имеют риск разрушить и наши скрипты (в общем, есть техники обхода таких проблем, главное, что о них не надо забывать, даже если месяцами всё работало стабильно).
Каковы минусы?
*) все ajax-запросы должны повторить в своих скриптах или использовать запуск сайтовых скриптов для обмена данными.
*) разработчику плагина надо работать не со страницей (что просто — посмотрел Ctrl-U, и всё видно), а с категориями данных: сообщение, автор, дата, ответы, автор, дата, оценка, сайтовые функции голосования, отправки сообщений и т.д.. Это сложнее (для автора парсера тоже), но перекрывается огромным плюсом независимости от вёрстки, при условии, что есть парсер. Значит, и плагин, написанный 2-3 года назад, будет работать, если касается представления, а 80-90% плагинов — такие. Но и часть функций работы с данными тоже можно отслоить от сайтов, чтобы операции «отправить ответ» или отправка оценки не зависели от реализации.
*) разработчику парсера надо хорошо продумать систему, чтобы она оставалась простой для разработчиков плагинов. Перекрывается плюсами расширения базы разработчиков.
Эта, третья идея видится более перспективной, поэтому по ней тоже объявляется набор исполнителей и спонсоров.
Есть другие соображения, как надо развивать полученную систему для устранения очередных отрицательных факторов — удаленные сообщения и статьи, падение серверов, но они выходят за рамки обсуждаемого вопроса о скриптах.
Подводим итоги
Есть 3 различных пути привлечения разработчиков для улучшения качества представления данных на сайте. Они различны по трудозатратам и схеме монетизации — от нулевой до весьма полноценной. Простые скрипты имеет смысл собрать в один плагин для того, чтобы иметь не только полезный инструмент для гиков, но и модель для гибкого тестированя юзабилити на реальных данных и собственном опыте. Для наработок некоторых идей, которые можно применить в других местах. Этот путь — наименее затратный и приносящий косвенные выгоды разработчикам в виде накопления их опыта.
Но на такую систему разрушающе действует произвол разработчиков сайта, поэтому в архитектуру скриптовой прослойки неплохо было бы включить отделение структуры данных от вёрстки. Такого рода проект можно тоже начать как общественный, с выходом на охват не только одного сайта, с лучшей защитой информации от потери, с более глубокой прокачкой скиллов разработчиками. Вполне возможно, что после проекта такого уровня команда разработчиков приобретёт опыт, полезный для других подобных по уровню коммерческих проектов, это будет хорошей саморекламой и опытом.
Наконец, возможно и привлечение венчурных коммерческих структур, как на начальном этапе, так и позже, для создания амбициозного и необычного проекта, сочетающего в себе решение подмеченных и перечисленных в данном тексте системных проблем. По первым двум уровням есть проработанная стратегия развития, правда, с неясной шириной охвата аудитории. Возможно, некоторые из читателей смогут продумать маркетинговую сторону вопроса в необычной плоскости — не в среде гиков, а в несколько другой, и это будет перспективнее. Третий уровень требует проработки распределённой системы серверов, что далеко выходит за пределы вопросов о скриптах и о представлении данных в браузерах. Следовательно, лучше, чтобы к этой части подключились люди (одного достаточно) — архитекторы серверной части.
Итого, все 3 направления актуальны и выражают подход, более ориентированный на качество представления данных в социальных сетях.
