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

1. Инструмент с циничным названием «С этой девушкой выбирают также:» «Не сложилось? Посмотрите эти анкеты:». Берем тех парней, кто написал этой девушке и показываем других девушек, которым они писали за последние пару дней. Предполагается, что людям нравится определенный типаж. Для слишком популярных анкет вводим понижающий коэффициент, чтобы не было засилья людей с модельной внешностью.

2. Интересы и группировка по степени совпадения в процентах, как музыкальные вкусы на last.fm. Собственно здесь, могут быть те же музыкальные или киношные вкусы. Не только на сайтах знакомств, например, в ЖЖ очень не хватает такой группировки по интересам.

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

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

1. Конструкторы персональных сайтов, предназначены для широкого круга разработчиков, в том числе непрограммистов. Лучший и популярнейший представитель — Wordpress;
2. Конструкторы «больших» информационных сайтов, многопользовательские системы, потребители те же. Наиболее популярный представитель — Drupal;
3. Конструкторы корпоративных сайтов. Ими пользуются главным образом разработчики веб-студий и фрилансеры. Помимо собственных наработок, коих большинство, все большую распроcтраненноcть в России получает 1C-Битрикс.

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

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

Рассмотрим типичную ситуацию.

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

«Дизайн сайта разрабатывался и согласовывался в течение года (в частности, оказались отвергнуты 28 начальных вариантов стилевых макетов).» Источник.

Является ли этот факт поводом для гордости, вопрос спорный. Скорее, это говорит об ошибках в управлении требованиями.

Профессор Эрик Шпикерманн (Erik Spiekermann) из Германии, основатель Metadesign, в интервью опубликованном в журнале «Мир Дизайна», говорил, что в дизайне у задачи может быть не больше двух решений.

Речь идет о практике, разумеется. И главное на практике — четкость поставленной задачи, основанная на общем видении заказчика и исполнителя.

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

Итак, два правильных документа и одно правильное мероприятие: