На сегодняшний день существует огромное количество «дизайнов», которые чем только не занимаются, и еще столько же дисциплин, которые дизайном не называются, но являются им по сути. Мне очень хочется все это упорядочить, создав, хотя бы для себя, понятную общую дизайн-типологию. [...]

Я решила отвлечься от всей существующей терминологии и начать именно задач, которые должен решать дизайн. Не задач вроде «сделать логотип», а настоящих, вроде «привлечь аудиторию» или «разработать систему оплаты через интернет». Подумав (долго), я пришла к трем общим и очень абстрактным категориям, на которые задачи можно разделить:

1. Пространственные (вся предметная и понятийная среда)
2. Чувственные (все, что связано с нашими желаниями, восприятием и самочувствием)
3. Коммуникационные (взаимодействия, передвижение, энергообмен всего и вся)

Вся заметка Типология Дизайна 1.0 несомненно стоит внимания, Лиза очень чётко всё расписывает.

Это именно тот дизайн, которым мне хочется заниматься, однако с высоты своего опыта вижу, что такой дизайн очень непросто продавать. По моему опыту российский клиент (во всяком случае того уровня, с которым мне приходится иметь дело) чаще всего не готов на полноценное участие агентства в работе, не понимает, зачем нужен, например, этап проектирования, который у нас в Raum7 является обязательным, а уж тем более не понимает, почему он стоит отдельных денег. По всем этапам приходится проводить образовательную работу, долго и тщательно объяснять, показывать примеры, и при удачном стечении обстоятельств добиваться-таки понимания.

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

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

Небольшая презентация Дэниэля наглядно иллюстрирует принцип COPE:

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

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

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

Схематически это могло бы выглядеть примерно так:

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

Осмысленная структура позволит, как в случае NPR, на лету создавать новые виды представления, легко и просто расширять функционал, строить качественных поиск. На мой взгляд, использование WYSIWYG должно быть минимизировано (в большинстве случае достаточно тегов strong, em, h1-h3, гиперссылок и вставки изображений), а результат работы визуального редактора должен тщательно чиститься. (В плане чистоты и лаконичности мне очень симпатичен WYSIWYG-плагин для jQuery.) Чем дискретней, атомарней данные, тем легче их организовывать, сортировать, повторно использовать, анализировать. Вместо склада текстов можно формировать базы данных, извлекая из них новые смыслы и значения.

Современные фреймворки вроде Symphony, Ruby on Rails или Django, разумеется, предоставляют функционал для построения в кратчайшие сроки CMS с оптимальной структурой хранения данных, однако я пока не встречал удобных инструментов, не требующих навыков программирования для решения типовых задач по созданию специфичных структур данных. Мне кажется, что при нынешнем развитии технологий это вполне посильная задача для очень большого процента случаев.

Кстати, на завтрашнем Хакдее я буду читать доклад о контенте, и непременно затрону и этот вопрос. Мне было бы интересно обсудить его с профессиональными программистами.