БИБЛИОТЕКА CАЙТОСТРОИТЕЛЬСТВА

новости, статьи, обзоры по веб-дизайну и графике, разработке, оптимизации и продвижению веб-сайтов

Приветствую всех читателей нашей рассылки! Хочу начать с небольшого объявления-напоминания. На следующей неделе? 27-28-го марта в Киеве состоится конференция веб-разработчиков UA WEB 2008; сейчас сформировано три секции конференции - серверная, клиентская и общая (вероятно будет интересна менеджерам и руководителям компаний). Меня больше всего интересует клиентская секция - заявлены доклады о дизайне и юзабилити, вёрстке и микроформатах, четыре из всех клиентских докладов будут читать разработчики из Яндекса, должно быть интересно. Теперь уже точно известно, что я там буду (в качестве слушателя). Если кто-то из читающих рассылку захочет пересечься - можно обменяться контактами в комментариях к записи про конференцию, заодно обсудить, кто на какой секции будет, кто возьмёт с собой фотоаппарат и у кого есть хороший диктофон. А теперь перейдём к делам нашим дизайнерским и поговорим о том, почему так редко получается совместить в разработке и отличную функциональность, и удобство использования, и красоту разрабатываемого интерфейса (и кто в этом виноват, разумеется).

Правильный интерфейс - три типичных перекоса

Разработчики (и, в частности, дизайнеры интерфейсов, любых - веб, или windows приложений), если имеют опыт работы с разными командами, разными компаниями (т.е. разным руководством), сталкиваются с абсолютно разным представлением о том, что такое “правильный” интерфейс. Можно выделить три основные тенденции:

1. Правильный интерфейс - это функциональный интерфейс. В таких командах главный упор делается на продуманный механизм разрабатываемого проекта, на идеальный движок, все силы уходят на то, чтобы ядро было безупречным, чтобы (web или windows) приложение работало без сбоев при любой нагрузке, чтобы максимально полно и качественно реализовать затребованные заказчиком функции и сделать доступными управление этими функциями из интерфейса приложения. И складывается так, что для разработки этого приложения (или ряда приложений) привлекаются лучшие, высокооплачиваемые специалисты-разработчики, аналитики и программисты. Такие факторы, как удобство пользования этим приложением или уж тем более красота интерфейса, считаются вторичными, это приводит к тому, что и специалисты подбираются уже менее тщательно, команда специалистов незначительна по сравнению с командой программистов (обычно вообще один-два человека, иногда даже удалённых). Функциональность реализована, но пользоваться ею неудобно, а о визуальной привлекательности лучше не вспоминать.

2. Правильный интерфейс - это удобный интерфейс. Забота о пользователе ставится во главу угла (я не говорю о том, что это не правильно). Для разработки привлекаются талантливые информационные архитекторы, проектировщики взаимодействия, специалисты по юзабилити-тестированию, удивительно, но факт: в команде на пять программистов - семь ответственных талантливейших человек, отвечающих за создание правильного интерфейса + привлечённые для тестирования (эмуляция целевой аудитории) люди. Работу свою они выполняют качественно, приложение получается на самом деле с интуитивно понятным интерфейсом, удобное в использовании, только вот группа разработчиков подводит - то у них база падает при увеличении нагрузки, то кнопка нажимается через раз, да и сама функциональность не достаточно продумана и реализована поверхностно, хотя другие разработчики из этой же темы давно уже ушли на порядок вперёд. Удобно, но не функционально и не привлекательно.

3. Правильный интерфейс - это красивый интерфейс. В последнее время приходилось анализировать большое количество как виндовых программ, так и веб сервисов, встречались среди них примеры с на самом деле привлекательным, талантливо исполненным интерфейсом - очень эффектные веб сайты, необычайно и привлекательно отрисованные формы программ, с гармонично подобранными цветовыми гаммами и потрясающей графикой. Честно говоря, ни одно из них не осталось под руками в работе, отношение к ним осталось, как к миленьким игрушкам, которые стоило запустить, чтобы посмотреть, что там у нас рисуют западные прогрессивные разработчики, полюбоваться и забыть навсегда ввиду абсолютной непрактичности приложения. Не говорила бы об этом примере, если бы не сталкивалась. В такой ситуации разработка приложения в целом - это постоянное дорисовывание и перерисовывание интерфейса, его элементов, в процессе разработки делается 50 вариантов эскизов и на ежедневных митингах с руководством 90% времени - это обсуждение того, почему у этой иконочки “вот видите? зубчик на скруглении неаккуратный”, а “вот эта панелечка на один пиксель левее остальных”, и такое прочее. Команда же программеров чувствует себя изгоями - они не получают чёткую постановку задачи, им не дают технических возможностей реализовать всё достаточно правильно, им не дают человеко-ресурсов (когда в команде пару человек более-менее грамотные, остальные 10-15 - новички типа студенты), и даже времени на правильную реализацию.

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

Недооценка важности какого-то этапа, или низкие критерии качества любой части процесса разработки встречаются часто и в большинстве случаев снижают качество работы в целом, иногда - обесценивают (и я была свидетелем того, как закрывались практически готовые, разработанные проекты ввиду их полной коммерческой нецелесообразности при данной реализации, а бюджета на полную переделку уже не было). Часто это приводит к безграмотному использованию человеческих ресурсов. Я встречала, к примеру, в целом неплохую команду разработчиков (что-то около 40 программеров, большей частью веб-сервисы) - и на всю команду ВООБЩЕ ни одного дизайнера, ВООБЩЕ ни одного грамотного верстальщика. Помню, сколько времени талантливый дотнетчик тратил на то, чтобы хоть как-то причесать интерфейс, по ходу разбираясь с тонкостями вёрстки, с html и css и консультируясь по поводу подбора цветов для оформления интерфейса и элементов интерфейса. И это в то время, когда гораздо рациональнее и для конторы в целом выгоднее, если бы он писал только свой движок - но у конторы некому поручить эту работу, а тот удалённо сотрудничающий с ними индус, который рисует им эскизы для интерфейсов (дико уродские, честно-честно) и потом их “режет” в базовую html вёрстку (адаптацией вёрстки в движок он никогда не занимался и поэтому понятия не имеет, отчего матерятся программеры и после его трудов полностью перевёрстывают полученный макет).

Многие этапы разработки производятся в результате спонтанно, случайным образом, как получится. И программисты могут привести множество примеров такой разработки, когда на поставленную задачу один говорит “я слышал, это можно сделать так-то”, второй - “этот механизм я когда-то [в другой ситуации] делал так-то”, но в целом не хватает ни опыта, ни знаний для того, чтобы выбрать на самом деле правильное решение. И по отношению к правильным интерфейсам - в большинстве компаний интерфейсы разрабатываются на основе интуиции, существующего опыта (как опыта разработчика интерфейсов, так и опыта пользования различными интерфейсами) и на основе здравого смысла (а, правильнее сказать, того видения “здравости”, которое наличествует у разработчиков на данный момент времени). И хорошо, если в компании осознают целесообразность привлечения профессионалов для тех или иных этапов разработки, и могут обосновать эту целесообразность, но уж больно часто на предложение, мол пусть эту работу выполняет специалист в соответствующей отрасли, руководство смотрит удивлённо и неодобрительно: А ЗАЧЕМ?

Приведу цитату (скопировано из раздела “советы” на сайте Артёма Горбунова):

Все физические проявления хорошего интерфейса эстетичны — экраны, текстовый набор, иллюстрации и визуализации. Плохой интерфейс уродлив.
[Тафти, Рудер, Херлберт, Мюллер-Брокман, Брингхерст и другие…]

• Обсудить эту заметку можно в комментариях
• Другие заметки по теме в блоге

ИНТЕРЕСНО ПОЧИТАТЬ:

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

:: И кто они после этого? (кто такой дизайнер)
Дизайнер в маленькой компании - на все руки мастер: одному человеку в обязанности вменяется и скетчи для веба нарисовать, и сайт отверстать, и флеш на нём забабахать, и базу данных прикрутить, и визитки в полиграфию отправить, и предпечатную подготовку для всех бланков и презентаций компании провести. ...>>

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

:: Простой Google API для веб-мастеров
О Google Api пишут давно, но как-то мало наблюдаю, чтобы его использовали. Вместе с тем если покопаться, можно найти много простых, но интересных готовых решений для веб-мастеров; к примеру, посмотрим на варианты Google AJAX Feed API, с помощью которых можно у себя на сайте без каких либо сложностей формировать ленты читаемых блогов друзей в разных форматах, прям Google Reader на своём собственном сайте....>>

:: Скучно ли быть дизайнером?
Считается, что работа дизайнера — это очень интересно и скучать не придётся. На самом деле почти любую, кроме совсем уж тупо конвейерной, работу можно при желании исполнять творчески, нетривиально, или, как иногда говорят, "с душой". И так же в любом деле, даже, казалось бы, исключительно творческом можно найти элементы рутины, и выполнять со скукой и вселенской скорбью во взоре. ...>>

:: UA Web 2008 - мартовская конференция для веб-разработчиков
Конференция для украинских веб-разработчиков, которую и здесь в том числе анонсировала ещё осенью, всё-таки состоится! Теперь она - UA Web 2008, пройдёт в Киеве, 27-28 марта, в Президент Отеле. Одна из целей организаторов - собрать в одном месте и перезнакомить профессионалов этой отрасли. ...>>

:: Дизайнеров увольняют потому что… Продолжение
Том Демарко и Тимати Листер, «Человеческий фактор»: Каждый руководитель хотя бы раз в жизни вынужден иметь дело с сотрудником, который избегает работы, или же не имеет стандарта качества, или просто не может сделать свою работу....>>

:: У XML`я юбилей - 10 лет!
На сайте консорциума w3c.org предлагают начинать праздновать юбилей XML`я уже сейчас и продолжать праздновать весь год. Поздравления можно оставлять по этому адресу, там же можнол посмотреть, выглядит праздничный баннер, которым можно украсить свой сайт в поддержку юбилея ...>>

:: Миямото Мусаси и вёрстка
Не позволяйте багам возникшим в верстке завладеть вами. Все равно, по опыту, они всегда решаются только когда успокаиваешься и перестаешь орать "Ну какого !@# IE!?"...>>

:: Обзор приемов проектирования. Упрощение взаимодействий
Давно известна польза от меньшего количества кликов в интерфейсе. Резать ненужные взаимодействия и упрощать оставшиеся — одно из самых приятных занятий при проектировании. Не всегда получается сделать это сразу, но после нескольких ревью и обсуждений получившегося интерфейса приходит просветление....>>

:: Проблема технологий, или "Самурай без меча подобен"
Вы помните свои первые программы? Думаю, помните — страничка, которая выводит "Привет, 127.0.0.1? — и радость от того, что то что написано — заработало… Веб-сайт, на котором вовсю используется table и font…...>>

:: Уровни владения HTML, CSS и Javascript: Часть 1. HTML
Вашему внимание предлагается достаточно большой отрывок статьи "Levels of HTML knowledge", написанной Роджером Йоханссеном 30 Мая 2006 года. ...>>

:: 25 способов улучшить свой сайт
Эта небольшая статья поможет новичкам (и не только) оценить удобство собственного сайта и укажет основные недочёты, присущие многим сайтам. Ваши пользователи скажут вам спасибо ...>>

:: 10 ошибок в дизайне иконок
В дизайне иконок сейчас переходный период. Разрешение экранов становится все больше, а следовательно и иконки увеличиваются. Но все еще актуальны иконки размером 16х16 и даже меньше. Итак, вот главные ошибки в дизайне иконок ...>>

:: Web 2.0 может быть опасен… для вашего кошелька
Идеи Web 2.0 не обязательно «вредны» для пользователей, в отличие от предыдущих технологий (в частности, Flash и PDF). Иногда даже встречаются примеры эффективного применения Web 2.0 решений. Но гораздо чаще обнаруживается, что Web 2.0 идеи либо мешают пользователям, либо не отвечают их основным нуждам. ...>>

• Предыдущий выпуск рассылки - #230
• Подпишитесь на RSS

::: рассылку ведет:     Татьяна Вукс 2008 :::