Об сайт!

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

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

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

Что же пошло не так? Некоторые ответы на этот вопрос теперь ясны; ими и делюсь.

О несуществовании сайта

Сделанный сайт — вот он, он дан нам в ощущениях; если смотреть его на смартфоне или планшете, его даже можно пощупать. Однако когда сайт ещё не сделан, его совсем нету, вместо него — набор отдельных ингредиентов в виде работ и активностей.

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

• Текстовый контент
• Нетекстовый контент
• Подача этого контента
• Оформление и вёрстка контента
• Техническая реализация контента
• Устройство “сайтового аппарата” (по аналогии с книжным аппаратом, т.е. как устроено меню, где именно оно находится, что написано в подвале и т.п.; всё, что не контент, зато сайт в целом)
• Дизайн сайта в целом (здесь и далее — не отдельных страниц, потому что они проходят по ведомству контента)
• Техническая реализация сайта в целом.

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

А другие пункты просто завязаны между собой клубком. Например, как придумать сайтовый аппарат, пока не выработано, какие именно страницы на сайте будут? И одновременно многие страницы, вроде главной или результатов поиска, есть прямое следствие решений про сайтовый аппарат. И так оно всюду!

Басня. Некогда я был книжным верстальщиком/дизайнером. И каждый раз, получив новый манускрипт, я злыми словами ругал авторов, которые в некоторых местах делали двойные заголовки (это когда сразу за названием главы идёт название параграфа). Можно хорошо сверстать, когда все заголовки глав или разделов двойные, равно как когда двойных заголовков нет вовсе. А когда они где-то есть, а где-то нет — хорошо сверстать нельзя. Прошли годы, заполненные руганью. Когда я писал свою первую книгу я потратил некоторые усилия, чтобы сделать хороший и удобный для вёрстки манускрипт. Но когда я сам сел его верстать… Мама дорогая, я сам допустил в двух местах двойной заголовок. С тех пор я стараюсь не ругаться; теперь я хорошо понимаю разницу в модальности сознания автора и верстальщика.

В результате проблемы.

А) Делая сайт для других, мы можем игнорировать эти взаимозависимости, принимая простое решение — “ну, тут мы сделаем как обычно”. Делая же сайт для себя, на такое мы пойти не готовы.

Б) Делая сайт для других мы легко принимаем решения за других. Например, дизайнер, рисуя страницу, когда контента ещё нет, ловко принимает решение о том, что “ну, здесь будет три абзаца текста и не больше, а вот тут будет картинка!”, оставляя другим муки растягивать/ужимать текст именно до трёх абзацев и искать картинку, которая сама из воздуха не появляется. Делая же сайт для себя, этих других нету, поэтому, принимая решения такого типа, мы впадаем в дихотомию “хвост вытащил — клюв увяз”.

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

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

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

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

Что делать?

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

Ничего не делать, буквально

Можно отказаться от принятия проектных решений вовсе и сайт не делать, настроив вместо него редирект на соцсеть. Например, в Иннове так и сделали и никто не умер. Я легко понимаю их логику. Только некоторые пути ведут на вершину, но все пути ведут с вершины вниз — а Иннова как раз находится на вершине творческих и технических потенций сделать себе сайт. Крупный минус — человек без аккаунта в Facebook ничего не сможет сделать на “сайте в Facebook”.

Тупой движок

Можно отказаться от части проектных решений и собрать сайт на готовом движке, отдав на откуп разработчикам движка большую часть проектных решений. Негибкость движка в этом случае является бонусом. Мы так и сделали и собрали сайт на Тильде — которая ограничила нас в качестве кода (он ужасен), и в оформлении/формате подачи (нудные лонгриды в жанре корпоративного модернизма, но хоть от hero shot мы избавились).

Готовые ригидные движки в последнее время стали не так уж плохи, при этом позволяют одновременно работать и с контентом и с его оформлением (чего, несмотря на все обещания, так и не позволили традиционные СУКи). При этом они продолжают эволюционировать; убогие сейчас, они станут лучше в самое ближайшее время. К сожалению, они преимущественно эволюционируют в сторону мощности, а не повышения качества; например, в Тильде появляются и появляются новые блоки, но интерфейс редактора как был шизофреническим, так и остаётся. Creeping featurism никуда не девается, несмотря на всю эволюцию.

На сторону!

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

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

Полное прототипирование

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

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

Золотой век интернета.

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

Как бы я поступил сейчас?

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

1. Видение проекта

Сначала надо было составить простенькую таблицу, в которой в строках были бы:

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

…и для каждой строки перечислены:

• факты, которые поддерживают мессидж
• ответы на вопросы
• приемлемые решения для сервисов.

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

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

2. Контент-прототип

На основе таблички из первого этапа надо было сделать контент-прототип: т.е. все тексты и все эскизы всей графики, которая была бы на сайте. Чисто организационно я сделал бы это в OneNote — там прекрасная групповое редактирование, ключевые слова для отметки степени готовности материалов, а встроенная навигация внутри блокнота прекрасно эмулирует будущую навигацию сайта; кроме того, там легко хранить не единственное решение, а облако возможных решений по контенту (“вот тут будет такая картинка, но если она не получится, как планируем, будет вот такая”).

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

Когда контент-прототип полон, т.е. в нем есть все, что требует видение проекта, можно обновить видение (к этому моменту уже будут видны многие его недостатки) и соответственно обновить контент-прототип.

3. Дизайн-прототип

После этого уже можно превратить контент-прототип в дизайн-макет (но все равно ещё прототип), сверстав тело всех страниц прототипа и подготовив всю графику в нем. Технически тут много свободы; я бы для экономии времени и сил большинство бы сравнительно простых контентных блоков заверстал бы в Bootstrap, а акцидентные блоки нарисовал бы в Sketch и вставил бы как графику в HTML-вёрстку (исходя из того, что финальную вёрстку все равно будет делать профессионал). Организационно простая альтернатива — если вас устраивает корпоративный модернизм и вы готовы терпеть убогие редакторы внутри браузера, просто собрать сайт в той же Тильде, Readymag, Webflow или в другом подобном редакторе.

4. Прототип сайта

И вот на этом этапе можно превратить дизайн-прототип собственно в сайт:

• приделав к телам всех страниц навигацию, шапку и подвал,
• хорошо сверстав акциденцию
• синхронизировав стили между разными страницами
• насадив сайт на тот или иной СУК
• отрегулировав мета-данные.

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

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

Мы, Usethics, проектируем интерфейсы, проводим юзабилити-тестирование, исследуем пользовательский опыт и поставляем качественные UI и UX с 2001 года.