С тех пор, как я начал вести этот блог, мой взгляды на процессы веб-разработки и в частности на проектирование сайтов изменились. Кажется, идеализма поубавилось. За полгода у меня сформулировались некоторые принципы проектирования. В скором времени я планирую составить список. А сегодня сформулирую один тезис.
Проектировщик обычного сайта в своей работе должен постоянно смотреть на возможности CMS. Для разработки нового модуля (написания нового кода) нужны очень веские причины. Пусть проектировщик представляет, что в команде вообще нет программиста.
До определенной степени я допускаю ущемление удобства пользователей, отсутствие какой-то автоматизации, логические недочеты, если это позволит сделать сайт из готовых компонентов. А, значит, быстрее и дешевле.
Чтобы следовать этому принципу, нужны две вещи.
Во-первых, проектировщик должен быть эрудированным в области CMS, CMF, BBS и прочих web-based CRM.
Во-вторых, проектировщик постоянно должен приземлять полет своих мыслей, оглядываясь на возможности платформы. А программистам найдется работа в любом случае. Если им не придется писать лишний код, они только спасибо скажут. К тому же есть целый класс необычных сайтов, где возможностей CMS никогда не хватит.
Дмитрий Сергеев, 26 лет, разрабатываю сайты на Drupal, управляю интернет-проектами
Комментарии
ckpomcku, 27.06.2007 15:57
Работа в контексте существующих ограничений – страшнейшая ошибка при разработке веб-проектов, которая приводит к полнейшей потере стоящих задач и шаблонизации всего и вся.
Дмитрий Сергеев, 27.06.2007 20:53
Так уж страшнейшая? :)
С одной стороны вроде бы существует опасность подмены стоящих задач. Но разве проектирование не должно быть в первую очередь ориентировано именно на решение этих задач? Ясное дело, что про задачи ни в коем случае забывать нельзя. Другое дело, что решений может быть много. Они могу быть шаблонными и нешаблонными. И, честно говоря, когда видишь что-нибудь диковинное, иногда даже хочется шаблонности.
У меня пока отрицательного опыта, связанного с этим принципом не было. Может быть, потому что следовать ему трудно и получается далеко не всегда.
У вас есть какая-нибудь жизненная история? Интересно было бы послушать.
ckpomcku, 29.06.2007 03:57
Жизненная история проста – взгляните на бизнес-ориентированные корпоративы. Подавляющее большинство из них не решают никаких задач, кроме адреса на визитке. Это прекрасно отражает глобальное заболевание «высокотехнологичными cms-платформами» и полное нежелание решать задачи клиента, которого, по сути, совершенно не интересует на чем вы там пишите свои супермегакрутые cms'ы, функционал которых, в итоге, не используется даже на 50%. И проблема здесь только в том, что проектировать «под возможности cms» – чистой воды развод клиента, которому, возможно, нужны были всего 3 html-страницы. Естественно, что оглядываться на производственные мощности необходимо, но ограничиваться «однажды заточенным топором» – опасно для здоровья.
Дмитрий Сергеев, 29.06.2007 12:12
В общем я согласен: многие сайты не решают тех задач, которые должны бы решать. Но тут по-моему причина не в функциональности CMS и не в том, что разработчики ставят себе лишние ограничения.
Проблемы могут быть в том, что
* разработчики не достаточно осведомлены о возможностях CMS,
* используется какая-нибудь low-end CMS (может быть самодельная),
* разработчики не хотят использовать функциональность CMS из-за отсутствия реальной заинтересованности (как вы и сказали).
Большие современные CMS в техническом плане развиты неплохо. Скажем, уже на протяжении полугода, если мне нужна какая-то функция Друпала, в 80% я нахожу модуль. Это где-то штук 70 модулей. Всего же их я думаю больше 500. Это, значит, что запас прочности еще есть, хотя я вроде нашел уже все многие ключевые компоненты.
Edzo Hogusava, 29.06.2007 12:34
IMHO то, что многие сайты не решают свои задачи - это скорее не проблема CMS и CM*. Это проблема людей которые занимаются их продакшеном и/или поддержкой. По моему - это проблема не технологическая в принципе. Многофункциональных и стабильных инструментов (в том числе open source) множество. Самолеты есть - пилотов маловато! :-)
ckpomcku, 29.06.2007 14:04
Полностью согласен. Спасибо, что кратко и четко сформулировали мою мысль ;)
Александр Сергеев, 01.07.2007 20:32
Только чтобы управлять этим open source самолетом пилот, к сожалению, вынужден разбираться в технике не хуже конструктора самолета )
ckpomcku, 29.06.2007 14:08
Все верно – вы сами ответили на свой вопрос. Задача решается методом её решения, а не перебором вариантов использования определенной платформы.
Edzo Hogusava, 27.06.2007 23:38
Это вольно сформулированный (и немного вольно интерпретируемый) один из принципов Getting Real. В нем есть большая сила, но в нем же и одна из самых больших слабостей GR...
Дмитрий Сергеев, 28.06.2007 00:31
Вполне возможно, ворую на подсознательном уровне :)
Прочитал несколько месяцев назад GR. В голове что-то осело и неожиданно всплывает в виде собственных мыслей. Хех.
Чаще всего у сильных вещей есть неприятная обратная сторона. Это как растить персонажа в сбалансированной РПГ: всё сразу прокачать невозможно.
Edzo Hogusava, 28.06.2007 01:17
Не, вопрос не о воровстве (ничто не ново под луной :-}
Это скорее про последствия GR, которые со временем начинают становится препятствиями-задачами, для решения которых необходимо придумывать новый GR :-)
Дмитрий Сергеев, 28.06.2007 11:26
Вообще я не думаю, что при создании несложных сайтов программировать вообще не нужно. Просто пытаюсь отодвинуть эту грань необходимого программирования подальше от своих ранних представлений. Но, конечно, это не стало целью моей жизни :) Просто в голове делается еще одна проверка правильности решения с этой точки зрения.
~xXx~, 30.06.2007 03:57
> " К тому же есть целый класс необычных сайтов, где возможностей CMS никогда не хватит."
да ладно ) зная CMS прогер напишет всё что угодно (оговорюсь - я последнее время работал с кастомными промышленными CMS)...
однажды на моей памяти тусил я на заманушной конференции РБК в Балчуге с черной икрой и прочими костюмами от Brioni, где он втюхивали свои кастомы для серьезного корпоратива/гавермента - очень воодушивил веб-интерфейс для сборщика новостей интранета и пресс-службы (правда во втором случае давно есть специализированная софтина у Интерфакс)... фича состояла в том, что внутрь инерфейса подгружался необходимый сайт и в нем маркером метились поля, которые необходимо было сканить на ключевые слова или просто по тупому парсить в систему... если не путаю, проект разрабатывался для Росатома...
Дмитрий Сергеев, 30.06.2007 16:00
Просто иногда CMS может оказаться слишком высокоуровневой. И берется какой-нибудь Zend Framework.
А идея сборщика новостей классная. И выбор новостей не ограничивается только сайтами с RSS.
Junior, 30.06.2007 15:11
Гы-гы, я из заголовка подумал об обратном. Типа "проектировать, не оглядываясь на сложности программирования". Думаю, "о, да, это такой кайф". Но такого не бывает (ну если только бюджет резиновый) :-P
Александр Сергеев, 01.07.2007 20:52
Скоро будем проектировать интерфейсы не думая о сложностях программирования, благодаря Flex, Silver Light, MS Expression Studio, HTMLayout и другим визуальным фреймворкам, которые позволяют, например, сделать комбобокс с чекбоксами или с деревом.
Вся проблема сложности программирования, и уже давно, кроется - в сложности создания действительно удобного GUI при помощи стандартных фреймворков, и только в этой сфере сейчас идет развитие фреймворков, в том числе и в вебе. Транспорт, протоколы взаимодействия - практически не развиваются. RSS 2.0/Atom - разве сложные технологии? WinAPI - давно уже инкапсулирован в .NET Framework. Если появляются новые вещи в интерфейсе новых версий Windows, то это максимум новые опции в старых функциях WinAPI. В вебе - php, python, куча библиотек (smarty, pear, mason). Бизнес-логика пишется на раз-два. В чем сложность? В интерфейсе, в пользовательском интерфейсе. А это юзабилити, аминь )
Дмитрий Сергеев, 02.07.2007 13:39
> Скоро будем проектировать интерфейсы не думая о сложностях программирования, благодаря Flex, Silver Light, MS Expression Studio, HTMLayout
Не очень скоро :)
На счет программирования GUI согласен. Но разработка новых интерфейсных элементов продвигается не так быстро, как хотелось бы. На мой взгляд, сейчас те, кому интересно, экспериментируют. Но это всё какие-то локальные подвижки. Проблема не стоит остро, поэтому и подход относительно несерьезный.
Миша Татхагата, 06.07.2007 19:44
Сложно не согласиться с Александром Сергеевым. Я не понимаю, что такое проектировщик. Вот я называюсь системным архитектором решений (читайте большими буквами - я выстрадал это право) и в этом есть определенный смысл. При проектно-ориентированной организации работы, когда команда собирается на проект я предпочитаю ситуацию, когда программисты думают, что никаких проектировщиков вовсе и нет. А я выстраиваю технологический базис разработки и стиль рабочего поведения этих команд. Иногда ненавязчиво вмешиваюсь в процесс, выполняя интеграционные функции, что-то корректирую в направлении движения команды. Но упаси меня Бог делать вид, что я здесь главный. Без меня они проект худо-бедно закончат. А вот я без них... Вымру от перегруза. И это несмотря на приличное знание предметных областей.
А возможности CMS - это как "Высшая магия для тупых и увечных" Москва 2007, издательство "Кобелев и сыновья", мягкая обложка, карманный формат....
Внимание! Не ищите эту книгу в магазинах России.
Александр Сергеев, 06.07.2007 20:43
Миша, я если честно так и не понял, почему со мной сложно не согласиться :)
Дмитрий Сергеев, 06.07.2007 23:15
Давай попробуем доискаться истины :) Называйте фичи, которые нужны сайту, а я скажу, может ли это друпал или нет.
Александр Сергеев, 06.07.2007 23:38
1) Пользователь/задачи/интерфейс - первичен, код - вторичен. Это принцип UCD-проектирования.
2) Интерфейс состоит из контролов.
3) Сейчас дофига библиотек с готовыми контролами (floating windows, tabs, tooltips, in-place editing, calendars, etc).
4) Хорошая CMS имеет хороший extensibility и _ясный_ код, в идеале это ООП.
Если проектировщик интерфейса хорошо знает контролы, а программист знает хорошие CMS и ООП php - есть контакт.
Дмитрий Сергеев, 06.07.2007 23:49
Это точно сюда комментарий? ;)
Александр Сергеев, 07.07.2007 00:21
Промазал уровнем :)
По друпалу я если можно задам вопросы. Мы вот хотим сделать http://usability.by на Друпале.
Что нам надо (статические страницы опускаю):
1) Новости из мира юзабилити, новости сайта (тизер и полный текст новости с картинками)
2) Юзабилити-специалисты (фото, описание, контакты)
3) Компании (логотип, описание, контакты)
4) Общая блог-лента, которая объединяет блоги воедино (ui.bu, guicci.ru и другие) (типа gui.ru), и плюс внутренние блоги для тех, у кого нет standalone блога
5) Статьи по юзабилити (в формате вики, редактировать могут зарегистрированные и заапрувленные пользователи) с _категориями_
6) Книги по юзабилити (картинка, описание, купить на ozon.ru || oz.by) по категориям
7) Форум
8) FAQ (с популярными вопросами из форума)
9) Блок What's new (новинки в разделах)
10) Поиск по всем разделам
11) Динамическая карта сайта
12) RSS для всего и вся (и подписка на e-mail)
13) Толковый словарь-подстрочник (навел мышь на слово, шлем запрос в наш вики и выводим результат в тултипе)
14) Контактная форма
15) Downloads (софт для юзабилити-специалистов, книги в электронном формате)
16) Ресурсы (ссылки на полезные Интернет-ресурсы)
17) Внутрення баннерная сеть
18) База вакансии и резюме
Это я на ходу придумал - без аналитики и проектирования. Там конечно хотелось бы еще блоки всякие разные иметь по сторонам страниц )
Давно присматриваю Drupal для usability.by.
Что скажешь?
Дмитрий Сергеев, 07.07.2007 13:25
>> 1) Новости (тизер и полный текст новости с картинками)
Есть
>> 2) Юзабилити-специалисты (фото, описание, контакты)
>> 3) Компании (логотип, описание, контакты)
Есть интеграция с CRM-системой CiviCRM. Она работает со связкой «Люди-организации-события». Вот онлайн демка http://demo.civicrm.org/drupal/. Немного сложновато, но присмотреться стоит.
Кроме того, есть набор инструментов CCK (Content Construction Kit), который позволяет создавать новые объекты со свойствами и делать под них формы ввода/редактирования. Вполне удобно.
И есть несколько альтернативных вариантов связывания объектов между собой.
>> 4) Общая блог-лента, которая объединяет блоги воедино (ui.bu, guicci.ru и другие) (типа gui.ru), и плюс внутренние блоги для тех, у кого нет standalone блога
Блоги поддерживаются. Общая лента наверняка поддерживается.
>> 5) Статьи по юзабилити (в формате вики, редактировать могут зарегистрированные и заапрувленные пользователи) с _категориями_
Базовый друпал умеет хранить разные версии материалов. А вот нашелся вики-модуль http://drupal.org/project/drupal_wiki.
>> 6) Книги по юзабилити (картинка, описание, купить на ozon.ru || oz.by) по категориям
Уже говорилось про CCK.
Категории друпал поддерживает. Неограниченное количество наборов категорий (словарей) и любой уровень вложенности. Есть полииерархия. То есть у одного потомка может быть несколько родителей.
>> 7) Форум
Друпаловский форум не очень хорош. Это отдельная тема. Но всё-таки он работает. Права доступа, подфорумы, новые/старые сообщения -- это всё есть.
>> 8) FAQ (с популярными вопросами из форума)
Факи, насколько я знаю, собираются вручную. Особых трудностей не должно быть.
>> 9) Блок What's new (новинки в разделах)
Это просто последние материалы в разных категориях.
>> 10) Поиск по всем разделам
Не думаю, что на поиск друпала стоит рассчитывать. Наверняка морфологию не учитывает.
>> 11) Динамическая карта сайта
Есть Google sitemap (XML) и разные HTML sitemaps.
>> 12) RSS для всего и вся (и подписка на e-mail)
Есть подписки и целый букет фидов.
>> 13) Толковый словарь-подстрочник (навел мышь на слово, шлем запрос в наш вики и выводим результат в тултипе)
С таким не сталкивался. Нужно поискать.
>> 14) Контактная форма
Наверняка есть
>> 15) Downloads (софт для юзабилити-специалистов, книги в электронном формате)
Файловое хранилище должно быть.
>> 16) Ресурсы (ссылки на полезные Интернет-ресурсы)
Ссылки можно ставить :)
>> 17) Внутрення баннерная сеть
Вот баннерный модуль http://drupal.org/project/banner
>> 18) База вакансии и резюме
Не уверен, что есть в готовом виде. Но с CCK реализуется без проблем.
Дмитрий Сергеев, 07.07.2007 13:26
Конечно, если всё собрать в кучу, может получиться уродливый монстр. Так что проектирование всё-таки нужно :)
Александр Сергеев, 07.07.2007 15:13
Спасибо тебе огромное за feasibility!!!
Хотелось бы форум нормальный...Типа vBulletin или на крайняк phpBB...
Дмитрий Сергеев, 07.07.2007 16:18
Да, форум лучше взять отдельный. IPB или vBulletin за деньги, либо PunBB или SMF бесплатно.
Александр Сергеев, 07.07.2007 18:29
Ок, спасибо, учтем.
Миша Татахагата, 10.07.2007 00:17
Для Александра Сергеева.
Во-первых: проектирование приличных GUI, вероятно, представляет едва ли не самую серьезную сложность - достаточно запустить несколько приложений да пройтись по десятку сайтов для того, чтобы убедится в этом.
Во-вторых: стоит вспомнить о .Net Framework и станет ясно, что проектировать просто интерфейсы для веб стало очень просто благодаря использованию модели управляемой при помощи событий.
В-третьих: решение многих рутинных задач, типа отображения набора данных, возможно нынче вобще без написания единой строчки кода - drag, drop и декларирование. Но это уж как-то слишком...
С этим и соглашаюсь
Правда, для того, чтобы добавить чекбокс или картинку в комбобох мне, как правило, не нужно почти ничего, кроме знаний и пары идей относительно реализации.
Александр Сергеев, 10.07.2007 00:31
Миша, теперь понял. Да, мы одного мнения насчет сложности разработки GUI.
Кстати, я поднял тему у себя в блоге по поводу Юзабилити, Web 2.0 и GUI.
В Microsoft как-то поздновато поняли, что GUI Windows API устарела и пора делать поддеркжу более атомарных контролов, которые состоят из более мелких, нежели windows, атомов. Это я про Microsoft Expression Studio, в котором можно рисовать любые контролы в растрово/векторном редакторе и потом экспортировать это дело как XAML (дерево объектов + событийная модель) в IDE для написания кода программистом.
Кстати, интересно что бы вы ответите как Windows-разработчик на мой вопрос
"И еще, интересно, сколько времени понадобится Windows-программисту, чтобы нарисовать вот такое простецкое окошко в VS 2005" в той статье.