Главная страница статей --> Хитрости при программировании php, заметки по базам данных

Черновой стайлинг

Источник: realcoding.net

Считается, что при создании веб-приложений графическим дизайном и программированием должны заниматься разные люди. Ведь известно, что инженерный и художественный таланты редко уживаются в одном человеке. А еще есть юзабилисты, которые до недавнего времени вообще были очень несчастными людьми, когда пытались объяснить миру саму необходимость своей профессии, и что часто чисто инженерных и чисто художественных мозгов не хватает для того, чтобы создать удобный продукт.

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

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



И показывает ворох нестилизованного HTML с огромными дефолтными шрифтами и без раскладки, когда все блоки идут просто один за другим.

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

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

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

По этой же причине, кстати, очень плохо при показе программы выглядят типичные для программиста тестовые данные типа “foo”, “bar”, “тестовая запись” и “asdfgh”. Для заказчика отсутствие функциональности вообще и наличие тестовой функциональности одинаково бесполезно. Ему интересен готовый результат. И поскольку он, опять-таки, не программист, он не может знать, что с вашей точки зрения само появление на экране хоть чего-то после долгого проектирования модели — это большой шаг вперед.

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

Я сейчас нахожусь как раз в середине двухмесячной разработки того, что мы с заказчиком условились публично называть “Неким Музыкальным Сервисом”. И не далее, как пять дней назад, решение такой проблемы у меня наконец выкристализовалось в четкую концепцию “чернового стайлинга”. Это такой компромиссный вариант, который позволяет инженеру без художественных талантов тем не менее достойно представить результаты своего труда.





Строится он по таким принципам:

*

Раскладка должна быть полностью задана. Несмотря на то, что расположение блоков и вид кнопочек задаются одним и тем же CSS’ом, для тех, кто будет смотреть на ваши страницы, это разные вещи. И юзабилисту потом будет проще давать советы, что куда подвинуть и как поменять, если будет, от чего отталкиваться.
*

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

Картинки-пиктограммки должны быть нарисованы, и выглядеть некошмарно. Обычно графика, которую рисуют программисты, выглядит убого просто потому, что делается на непрозрачном белом фоне инструментом “карандаш” в одно движение мышкой. Не надо так делать. Возьмите редактор, который умеет делать прозрачность (под Windows я пользовался Microangelo, под Линуксом сейчас — GIMP) и потратьте на черно-белую иконку какое-то время. Честно говоря, в квадратике 16х16 не так много места, чтобы не нарисовать все по точкам, тем более что никакого “леденцового” качества не требуется.
*

Вместо многих иконок вообще можно пользоваться Unicode’ными символами. Галочки, стрелочки, карандашики, кружочки и квадратики — все это там есть. И это не то же самое, что раньше было в шрифте Wingdings, теперь это все внесено в стандарт Unicode и есть во многих стандартных шрифтах.

Чтобы эти символы набирать, я пользуюсь “Character Map”, которая идет с Ubuntu. Точно помню, что есть такая и в Windows, хотя сейчас я ее на соседней XP не нашел. Но в любом случае можно вводить их кодами: ✓
*

Даже не надо думать про скругления углов, градиенты и прочее. Вполне можно обойтись CSS’ными border’ами для создания псевдотрехмерных эффектов. (Хотя я и не удержался от двух градиентных картинок :-) )
*

Шрифт должен быть меньше стандартного, потому что тот слишком большой обычно. И без засечек. Я обычно ставлю “font:small Tahoma” в качестве основного.
*

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

Ну и ко всему прочему, во время стилизации тут же вылезают все огрехи в структуре HTML (а то и глубже), которую вы напроектировали там вслепую.

И что мне, как не дизайнеру, особенно приятно, реакция тех нескольких людей, которые видели этот черновой стайлинг, была в духе “симпатично!” :-)



Похожие статьи:
- CSS от А до Я
- Семантическая сеть, основанная на микроформатах
- XHTML+CSS. Преимущества очевидны
- Разрешение экрана и разметка страниц
- Иконка в строке с URLом.
- HTML » XHTML » XML
- Бесплатная «вечная» реклама любого товара + раскрутка сайта.
- Web 2.0 для дизайнеров
- Типичные ошибки сайтов
- Схема MVC в Ruby on Rails
- Быстрый старт - Rails + SQLite
- Разрушим величайший миф веб-дизайна
- Ruby on Rails vs. PHP stats


Оглавление | Обсудить на форуме | Главная страница сайта | Карта сайта |

Контакты
Редакция:
[0.002]