Семантика сайта elisdn.ru

Формируем план работы на ближайшие полгода. Среди старых задач болтается переделка личного блога ElisDN.

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

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

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

Выбор инструментов

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

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

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

Первый этап — снятие параметров статей

При первом заходе в таблице появились только названия записей и их адреса. Адреса всегда заношу в таблицу — так быстрее обращаться к статьям. Всем подписывала комментарии это: пост, статья, видео, вебинар, приглашение.

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

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

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

Кстати меток я посчитала, было всего 29. Но главное, что к каждой записи их было проставлено не более 6. А это уже облегчало работу по занесению меток в таблицу.

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

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

Второй этап — создание гипотез

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

Сначала очевидными было дублирование рубрики “События и акции” и метки “События”. Почему появилась такая метка? Потому что есть события, такие как анонс проведения мастер-класса или вебинара, которое сразу относится к разделу событий и акций. С другой стороны событие — выступление на митапе — находилось в разделе программирования. По этой причине пришлось все события объединить единой меткой.

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

Дальше стало сложнее.

Я не в теме, но поправьте меня в комментариях. Правильной архитектуре разве можно научиться? Создание архитектуры является творческим процессом. Есть методики, которыми оперируешь, перегоняешь в голове объекты. Это как, у всех есть цемент и песок, но не все построят Лахта-центр.

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

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

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

Затем решила уменьшить количество меток.

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

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

Также продукты можно дополнить циклами статей или видео. Например, о программирования сервиса SeoKeys. Это полноценный, пусть и бесплатный, но продукт. С другой стороны в общих метках с технологиями по программированию метки “SeoKeys” быть не должно.

Также долго думала над объединением меток “Yii” и “Yii2”. Выйдет третий, поставим метку “Yii3”? Зачем? Да, это разные фреймворки с разными подходами. Но тем не менее в названиях статей фигурирует, на каком из фреймворков программировался код к статье.

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

Третий этап — создание структуры

Лист таблицы с исходными данными я оставила нетронутым. Для новых разделов создала новые листы, в которые скопировала строки с параметрами.

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

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

И создаём новые правила распределения будущих статей. Ведь у Димы как минимум 7 ближайших определено.

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

То, что было “до” вы можете увидеть в таблице. То что получим — это увидите в будущем. Часть меток на сайте уже удалила.

Если вы дочитали эту статью до конца, то молодцы. Сможете ответить на вопрос: стоит ли нам с Димой рассказать наши планы и объём работы на ближайшее время? Есть возможность провести такой вебинар на Deworker и там пообщаться. Интересно ваше мнение.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *