Считается, что при создании веб-приложений графическим дизайном и программированием должны заниматься разные люди. Ведь известно, что инженерный и художественный таланты редко уживаются в одном человеке. А еще есть юзабилисты, которые до недавнего времени вообще были очень несчастными людьми, когда пытались объяснить миру саму необходимость своей профессии, и что часто чисто инженерных и чисто художественных мозгов не хватает для того, чтобы создать удобный продукт.
Однако работать, оставаясь исключительно в рамках своей специализации, не получается. Будучи программистом, я естественно концентрируюсь, в основном, на функциональности сервиса, а о том, как выглядят в этот момент страницы, практически не задумываюсь. И раньше я часто совершал одну ошибку, которую, уверен, совершают и многие другие программисты: показывал заказчику то, что наработано, прямо в таком виде...
Представьте себе ситуацию со стороны заказчика. Программист месяц-другой что-то там делает, говоря, что все идет хорошо. Но заказчик нервничает, потому что ему остается только верить на слово человеку, которого он до этого и не знал вовсе. Через некоторое время программист таки говорит, что вот, многое уже обрело форму, и есть, что показать.
Дальше можно сколько угодно убеждать заказчика, что дизайн — это отдельная песня, и что расположение элементов на странице никак не связано с функциональностью приложения, и что там действительно готово уже больше половины. Все тщетно. Потому что картинка явно и недвусмысленно подтверждает все опасения заказчика о том, что этот негодяй даже ничего и не начинал, склепал какой-то кошмар в последнюю ночь, и проект близок к провалу.
И у него есть все основания так думать. Ваш заказчик — не программист. Он не читает ваш код, не следит за коммитами в 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 (а то и глубже), которую вы напроектировали там вслепую.
И что мне, как не дизайнеру, особенно приятно, реакция тех нескольких людей, которые видели этот черновой стайлинг, была в духе "симпатично!" :-)
Комментарии: 19
Кхм... надо будет взять на вооружение идею :)
Не перестаю удивляться ясности изложения идей и четкой структурности в Ваших статьях! Спасибо, это просто приятно читать :)
А ведь действительно так лучше! Даже мне, как программисту/админу с аналитическим складом ума, второй вариант нравится в 1000000 раз больше! :-)
А за статью - спасибо! Как раз недавно наткнулся на такую проблему, когда раскрашивать просто не умею, а нераскрашенное заказчик оценивает как ulgy даже не глядя на функциональность.
Спасибо за идею. Хотя мне чаще всего с заказчиками везло и они всё понимали. Чаще всего. Пару раз была такая же проблема, и я на скорую руку что-то страшненькое (нестрашненькое не умею) для них верстал.
А под виндой это
charmap.exe
, только он, кажется, не ставится по умолчанию, хотя не помню.Спасибо.
Вы развеяли ещё немного потаённых страхов и заблуждений. Отсутствие в команде дизайнера, может попортить много крови, ибо рисовать приходится всем...
P.S.
charmap.exe идёт в стандартной комплектации Windows и ставится по умолчанию
Если в самом начале представить проект в виде обычных серых квадратов и прямоугольников, демонстрирующих информационную структуру проекта, и отдать этот файл дизайнеру, то он может спокойно заниматься своим делом, а ты своим. При этом дизайн можно будет показать заказчику задолго до того, как ты закончишь программировать. В это время дизайнер сможет спокойно работать с заказчиком и доводить дизайн до ума, удовлетворяя пожелания клиента. И пусть меняется структура. Направление и стиль дизайна всё равно останутся. При всём этом времени выигрываешь много.
Странно. Я "всю жизнь" сперва получал дизайн и только потом приступал к работе.
Т.е. разработка софта без "черновиковых" дизайнов. Сразу чистовик и заказчику всегда есть что показать.
Очень правильно замечено, что заказчики оценивают продукт по его красоте и внешему виду.
"Если интерфейс красивый, приятный и удобный - значит это делал хороший программит и продукт выполнен качественно." - так думает большая половина людей. Красота внушает надёжность.
Сперва готовый дизайн не всегда возможен. Допустим у вас ещё не совсем требования устаканились. Или тот же инженер по юзабилити заставит переделать layout полностью изза смены требований, а так мне такой компромисный вариант больше всего по душе.
А ты с subversion работаешь? Он (или она? ;) лучше CVS, стоит переходить?
Эхх, к сожалению я с версткой даже в таком минимальном объеме не справляюсь. В итоге для knigoman.com.ua у меня сначала был именно такой вот вариант вообще без верстки (т.к. я заказчик, то мне ОК).
Потом правда, привлек к работе дизайнера, но дизайнера "старой закалки", который сделал все таблицами и без стилей. В итоге я почти в панике: или опять переделывать или интегрировать это чудо и запускаться как есть...
Спасибо. Очень полезная идея. Забираю.
с таким дизайном то и дизайнер для многих проектов становится не нужным
- тут сплошное правильное юзабилити..
Иван,это вам попался совершенно чудесный заказчик, с которым можно работать по такой схеме. К сожалению далеко не каждый первый согласится прорабатывать черновик - и необычайно сложно общаться с тем заказчиком, который еще до утверждения модульной сетки уже ждет цвета, до того момента, как соберется функциональность, уже ожидает "красивой" картинки (но не эскиза, а очень даже сверстанного html). А потом война между дизайнером и программером, изо дня в день, когда функциональность никак не лезет в уже готовое визуальное решение, и наоборот.
Мне кажется, это вообще большая общая проблема, когда заказчик начинает вмешиваться в технологию производства, причем любого. Но что интересно, идея соваться с советами к собственному зубному врачу, например, любому покажется странной. А вот учить проектировщиков, программистов, дизайнеров — это почему-то совершенно не смущает очень многих заказчиков :-).
Мне кажется нам, специалистам, еще предстоить развить эту самую культуру общения с заказчиками. Стоит, наверное, иногда просто отказаться от проекта, когда отношения переходят в стадию "эта кнопка должна быть здесь, потому что я так сказал".
Все здорово, и проблема ясна, и решение хорошее найдено. Но есть ньюанс:
* Процесс поставлен с ног на голову, если юзабилити эксперт будет заниматься "двиганьем" уже имеющихся кнопок. Кнопки должны быть определены этим специалистом. Он делает прототип, тестирует его и отдает в разработку;
* Гораздо лучше будет, если дизайн (для меня это код страницы + CSS, т.к. стилевое решение тут не интересно) будет сделан профессионально. Для этого есть прототип и по нему легко делаются шаблоны страниц;
* Разработка ведется по тому же прототипу и реализуются те функции, которые нужны пользователям, а не потому что "так захотелось эту фичу написать"
Вот тогда не будет возникать проблем:
* "заказчик не знает что мы делаем", потому что есть прототип и делаем именно то что там показано
* "куда приделать кнопку и как ее назвать и какая иконка нужна", потому что опять таки есть прототип и там показано куда, как и что
* "дизайнер не нарисовал", потому что даже если нет шаблона одного, можно делать по аналогии с другими и потом быстро все поправить.
Вообще, мне кажется, что все пободные проблемы при разработке из-за отсутствия методики как таковой. Потому что багтрекинг это еще не методика. Методика подразумевает, что клиент в курсе где сейчас проект. А хорошая методика еще и позволяет менять курс проекта прямо на ходу. Для веба, сферы столь изменчивой, это ИМХО крайне важно.
Эту проблему под именем "Айсберг" описал где-то у себя Джоэл. Он утверждает, что при выходе новой версии нужно в первую очередь работать над интерфейсом (верхняя часть айсберга, 1/12 его объема), а не над нутром - тогда пользователи действительно оценят нововведения. Именно поэтому Микрософт каждому ОФису дает новый интерфейс :-)
Я практически всегда беру для своих разработок какую-нибудь симпатичную минималистическую тему, дорабатываю слегка под свои нужды (вкуса вполне хватает, чтобы нигде внезапно не появлялись красные ссылки на синем фоне и шрифт на полэкрана) и уже с этим работаю.
А если, как советовали нам еще Древние, разметку отделить от кода, то привести это потом к виду, вполне удовлетворяющему заказчика, не есть проблема.