Шаблоны страниц глазами дизайнера
В новом проекте я много работаю в роли дизайнера-юзабилиста-фронтендщика. Пишу html, css, javascript. Думаю страницами, действиями, приоритетами. Хочу поделиться тем, что я успел увидеть глазами дизайнера в оформлении шаблонов страниц сайта.
Не уходить далеко от html, css
В случае статического сайта каждая страница - это один html файл. Это очень удобно. Хочешь поправить главную страницу - открывай start.html, профиль - profile.html и т.д. Поэтому всё (или почти всё), что относится к текущей странице, должно быть в одном файле шаблона. Даже javascript код лучше не выносить в отдельный файл, если он относится к дизайну-юзабилити страницы (а не к супер-сложной технологии, которую понимают только программисты). Исключения - методы или свойства моделей, возвращающие часто встречающиеся элементы (например, у меня в профайле есть свойство profile_link, которое собирает полное имя из first_name, last_name и оборачивает его в ), удобные фильтры и повторяющиеся виджеты (в виде отдельных файлов, добавляемых через {% include %} или inclusion tags - последние удобны тем, что их можно параметризовать).
Хорошо, если синтакс шаблонов - это обычный html-код с небольшими удобностями (django templates очень хороши в этом аспекте). Плохо - когда это что-то универсальное навороченное, из чего к тому же можно и html генерить. Синтакс шаблонов должен выбираться (и проектироваться) дизайнерами, или программистами-дизайнерами (которые большая редкость, и большая ценность).
Не заморачиваться чрезмерно с повторным использованием
Когда программист делает дизайн сайта, то у него все одинаковое. Профайл пользователя одинаково отображается на всех станицах, в формах все поля - одинакового размера. Когда над этими страницами начинает работать дизайнер, то вся это стройность перестаёт иметь смысл. Где-то важнее одна информация, где-то другая. Программист в этом случае добавит ветвление в свой универсальный шаблон (чтобы поддерживать, например, полную и краткую версию профайла), а дизайнер не станет париться и просто сделает два разных куска кода. Пусть они будут похожи, но через неделю-две они станут совсем разными. А два разных куска кода можно редактировать независимо, и это большой подарок для дизайнера - ведь ему удобнее редактировать целую страницу, а не двадцать отдельных виджетов, которые разбросаны по всему сайту. Целая страница - это как плакат. Правь ее и смотри - что получилось. Правь до тех пор, пока она не засияет и не начнет работать. Невозможно править двадцать разных виджетов и прыгать по всему сайту, пытаясь понять - стало лучше или хуже.
Если javascript пишет программист - давать дизайнеру возможность менять html, не меняя javascript
Хорошо, если javascript скрывает элемент p.description и вместо него показывает кнопку a.show_description. Плохо, если javascript вставляет после текущего элемента кнопку (html-код кнопки находится в javascript-коде) и затем скрывает этот элемент.
Второй код может быть более мощным и реюзабельным, но когда дизайнер начнет передвигать элементы на странице, то он перестанет работать. А вникать в чужой javascript-код, это совсем не то, чем хорошо заниматься, полируя дизайн.
