Блог NunDesign

Как и обещала в прошлом посте, выкладываю чуток фоток с конференции. Жаль, что мало.
Всё под катом.

(more…)

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

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

Мероприятие, как и было обещано, прошло в конференц залах (двух) Президент Отеля (публика периодически перетекала из одного зала в другой за интересными докладами), всё было так солидно и по взрослому. В холле бар и столы для кофебрейков. Вайфай работал стабильно, но с моего htc что-то куда-то писать было лениво. Зато появился повод лишний раз задуматься о том, что разработчики интерфейсов веб-сайтов, особенно всяких редакторских интерфейсов типа админки вёрдпресса, могли бы серьёзнее подойти к вопросу юзабельности и доступности блин этих самых интерфейсов для мобильных устройств.
Спешно перед поездкой, в самый день отъезда, купила мыльницу - выбор в пользу малых размеров, потому что возиться с любимым Canon`ом (который Canon EOS 400D Kit 18-55) тяжко, да и в условиях прогрессирующей лени бессмысленно. Но для мыльницы не взяла зарядное устройство для акка, и к вечеру первого дня она благополучно разрядилась, так что фотки будут, но позже и не очень много.

Долгожданные доклады о правильной вёрстке были отслушаны, всё понравилось, всё правильно, но чуда не произошло, ничего такого, чего бы я не знала или не использовала, никаких, гм., откровений, ессно, не прозвучало. С другой стороны, доклады по XSL оказались сложнее, чем мне понятно, будем догоняться реальной практикой на местечковых проектах.

UPD второй день: на следующий день то ли я адаптировалась, то ли список докладов (и докладчиков) сложился удачный, но второй день показался более плодотворным и ярким. Понравились доклады по интерфейсам новостийных сайтов, по методам тестирования юзабилити веб-интерфейсов, познакомилась и обменялась контактами с Геннадием Осипенко, Юлией Климентовской, Полом Гокиным (Paul Gokin), надеюсь, с пользой. Некоторые докладчики впечатлили - хорошим, уверенным знанием темы, которую читали, умением общаться с аудиторией, способностью увлечь даже такой темой, к которой я, к примеру, прямого отношения не имею (но имею опосредованное отношение). Один пример - доклад Марины Дидковской “Тестирование и оценка времени”. Я с нашими тестировщиками общаюсь напрямую, и, хоть они формально не являются моими подчинёнными, зачастую приходится тратить изрядно времени на введение людей в тему, на объяснение деталей процессов, особенно на тестовых версиях проектов, объяснения, кому какие баги надо постить и почему какой-нибудь “этот визуальный баг” таковым не является и прочие житейские радости.

Хотелось бы, конечно, подробнее пройтись по всем докладам, но так получилось, что я ничего не конспектировала, изданные тезисы восстанавливают в паммяти не все доклады, а записываемые ролики, к сожалению, будут доступны не раньше, чем через 2 недели, а может, и позже. Потому что, как сказали организаторы, ролики ещё надо оцифровать, порезать и разметить, а это время, и вообще… Может, после поездки наберусь сил, о чём-то напишу подробнее.
Ну и, конечно же, благодарности организаторам. Юра, ты умничка! Такое грандиозное мероприятие организовать… Олегу Бунину и Павлу Рогожину. Всем киевским и московским организаторам. И докладчикам - не поленились напрячься, подготовиться, выступить. И участникам - приехали, собрались, значит, не зря суета была. Спасибо Наташе и Лёше Колупаевым за приют
В общем, не жалею

UPD2: а что делать с этой красивой карточкой profyclub`а? Вот этот роскошный номер - его куда-нибудь нужно вбить?
Интересно, что на РИТ я регестрировалась ещё в прошлый раз, увы, не поехала, и не поеду на этот. Надо бы и поработать. С другой стороны, хотелось бы быть в теме, хотелось бы получить материалы конфы, да не спустя год, а как бы сразу. Если будет прямая трансляция - так же узнать где вовремя, а не на следующий день пялиться на “прямой эфир остановлен”, да.

Нескучные орнаменты на скучных офисных собраниях. Тем и спасаемся.

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

1. Правильный интерфейс - это функциональный интерфейс. В таких командах главный упор делается на продуманный механизм разрабатываемого проекта, на идеальный движок, все силы уходят на то, чтобы ядро было безупречным, чтобы (web или windows) приложение работало без сбоев при любой нагрузке, чтобы максимально полно и качественно реализовать затребованные заказчиком функции и сделать доступными управление этими функциями из интерфейса приложения. И складывается так, что для разработки этого приложения (или ряда приложений) привлекаются лучшие, высокооплачиваемые специалисты-разработчики, аналитики и программисты. Такие факторы, как удобство пользования этим приложением или уж тем более красота интерфейса, считаются вторичными, это приводит к тому, что и специалисты подбираются уже менее тщательно, команда специалистов незначительна по сравнению с командой программистов (обычно вообще один-два человека, иногда даже удалённых). Функциональность реализована, но пользоваться ею неудобно, а о визуальной привлекательности лучше не вспоминать.
2. Правильный интерфейс - это удобный интерфейс. Забота о пользователе ставится во главу угла (я не говорю о том, что это не правильно). Для разработки привлекаются талантливые информационные архитекторы, проектировщики взаимодействия, специалисты по юзабилити-тестированию, удивительно, но факт: в команде на пять программистов - семь ответственных талантливейших человек, отвечающих за создание правильного интерфейса + привлечённые для тестирования (эмуляция целевой аудитории) люди. Работу свою они выполняют качественно, приложение получается на самом деле с интуитивно понятным интерфейсом, удобное в использовании, только вот группа разработчиков подводит - то у них база падает при увеличении нагрузки, то кнопка нажимается через раз, да и сама функциональность не достаточно продумана и реализована поверхностно, хотя другие разработчики из этой же темы давно уже ушли на порядок вперёд. Удобно, но не функционально и не привлекательно.
3. Правильный интерфейс - это красивый интерфейс. В последнее время приходилось анализировать большое количество как виндовых программ, так и веб сервисов, встречались среди них примеры с на самом деле привлекательным, талантливо исполненным интерфейсом - очень эффектные веб сайты, необычайно и привлекательно отрисованные формы программ, с гармонично подобранными цветовыми гаммами и потрясающей графикой. Честно говоря, ни одно из них не осталось под руками в работе, отношение к ним осталось, как к миленьким игрушкам, которые стоило запустить, чтобы посмотреть, что там у нас рисуют западные прогрессивные разработчики, полюбоваться и забыть навсегда ввиду абсолютной непрактичности приложения. Не говорила бы об этом примере, если бы не сталкивалась. В такой ситуации разработка приложения в целом - это постоянное дорисовывание и перерисовывание интерфейса, его элементов, в процессе разработки делается 50 вариантов эскизов и на ежедневных митингах с руководством 90% времени - это обсуждение того, почему у этой иконочки “вот видите? зубчик на скруглении неаккуратный”, а “вот эта панелечка на один пиксель левее остальных”, и такое прочее. Команда же программеров чувствует себя изгоями - они не получают чёткую постановку задачи, им не дают технических возможностей реализовать всё достаточно правильно, им не дают человеко-ресурсов (когда в команде пару человек более-менее грамотные, остальные 10-15 - новички типа студенты), и даже времени на правильную реализацию.Типичный пример: так, ребятки, нам для послезавтрашней презентации сделайте быстро и красиво первую, пилотную версию (делают, что успевают, но к презентации версию предоставляют). А потом после презентации попытки объяснить руководству, что этот прототип был сделан в спешке на скорую руку, и для правильной реализации дайте же нам две недели! Две недели не дают, говорят, что функциональность устраивает, но через месяц разработки, когда костыли под костылями уже не удерживают конструкцию, удивляются и оскорбляются - что вы, мол, возитесь, и почему у вас всё время ничего не работает! Работает, но кое-как. В подобных ситуациях зачастую: красиво, но неудобно и не функционально.

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

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

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

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

Продолжая вчерашнюю тему о том, кого и где называют дизайнером (как и обещано в прошлом посте), рассказываю. Программеры в нашей компании разрабатывают не только (а в последнее время не столько) веб-приложения, сколько всякие мелкие и не мелкие виндовз-программы. Дизайнеры на разные программы привлекаются для разных целей. Самая обычная и простая дизайнерская работа для этих программеров - нарисовать главную иконку программы (формат .ico, полный), соответствующие иконки (порождаются от основной) install/uninstall, и две стандартные заставки на стандартный инсталлятор. В некоторых случаях дизайнеры принимают участие в “декоративном оформлении” интерфейсов программ - отрисовке функциональных иконок на тулбарах, симпатичных фончиков и тематических картиночек на формы и дают ни к чему не обязывающие рекомендации по подбору цвета для каких-то лейблов и для боевой раскраски гридов, реже - рекомендации по построению самой формы (расположение элементов формы, где и как текстбоксы, где и куда кнопки) или сценариям вызова той или иной формы.

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

Но чем больше в компании разрабатывается проектов, чем больше программерский состав, да и дизайнерский - тем уже специализация у каждого участника команды, это нормально и предсказуемо. Постепенно проходит время мастеров на все руки, проектировщиков-юзабилистов-художников-дизайнеров-верстальщиков в одном флаконе. Мне нравится эта тенденция, мне видится в этом что-то достаточно здоровое и подтверждающее, что правильным путём идём, товарищи. С другой стороны возникают свои сложности, в том числе и в поиске нужных специалистов. А руководство наше (о чём вчера и рассказывала) ищет кого бы вы думали? Дизайнера. Разумеется, мне позволяется в тексте вакансии более подробно описать, какие к нему требования и какой работой ему придётся заниматься. (more…)

Кого в вашей компании называют “дизайнером”? Понимаю, что вопрос не совсем корректный - тут зависит от того, чем компания, собственно, занимается, но всё равно интересно. К примеру, на прошлый пост о дедлайне и голимой вёрстке (трансляция в ЖЖ), где я использовала термин “дизайнер-верстальщик”, uznick ответил, что “А вот не надо совмещать дизайнеров и верстальщиков :)”. Отчасти ведь прав, не поспоришь. Но есть тема для обсуждения.

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

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

Знаете, честно признаюсь, двоякое у меня лично отношение к дедлайнам. В первом моём отношении к ним я вижу следующее стечение обстоятельств: действительно, бывает такое, когда какому-то мудрому менеджеру приходит в голову уникальная идея, которую он не поленился высказать руководству. Которое, в свою очередь, перенаправило эту идею аналитикам и те, в свою очередь, оценили как перспективную и своевременную. А тут ещё руководство встретилось с потенциальными партнёрами, и те заинтересовались, и сказали, что, мол, вот то собрание, которое планируется в конце месяца - единственно удачное время для презентации базового макета будущего продукта, если они увидят, что воплотить идею - реально, если идея на деле окажется настолько же жизнеспособной, как и на словах, то будут вам инвестиции и всяческая наша поддержка. И вот идея спускается к разработчикам в виде ТЗ и с комментариями, мол, ребятки, вы уж постарайтесь. Сроки горят, за три недели нужно сделать базовую функциональность, базовый интерфейс (пусть не конечный вариант, но чтобы всё было причёсано и опрятно как минимум), если пройдёт - будет у нас бюджет на глобальный проект, минимум на год разработки для целой команды (сколько это человекочасов получается?).

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

Но бывают и совсем другие дедлайны. Которые от безграмотного менеджмента и неуважения к разработчикам. Когда проект у людей висит уже не первый месяц, они что-то там возились, оптимизировали и даже разрабатывали функциональность, потом забрасывали на какое-то время, потом вдруг, скажем, под вечер в среду присылают письмо с архивом (!) проекта, частично даже без исходников (precompiledWeb), мол, ребята, вы там причешите в стиле (***) - в общем, нашего предыдущего большого проекта. Всё это без описания функциональности и без документации на сам проект, типа вы же такие умненькие, разберётесь. Типа, там же только таблицу стилей подредактировать. Запускаю проект (ага, без исходного кода, без связей, ещё повозиться надо, чтобы он вообще запустился, чтобы вообще хоть как-то увидеть интерфейс глазками, покликать по функциональным элементам), и тихо млею от того, насколько безграмотно организовано филе… больше сотни .aspx страниц, без шаблонов, с кошмарнейшим html кодом - доктайп не прописан ни в одной из, сплошные незакрытые или закрытые ошибочно теги (открыт параграф, закрыт спан), зато всё оформление прописано атрибутами в самих тегах. Да и значения атрибутов в одном теге то в двойных кавычках, то в одинарных, то совсем без оных. Встроенный в редактор валидатор кода зашкаливает, и это естественно - он подчёркивает всё, где видит неправильность, т.е. его использовать для правки смысла не имеет. А ещё часть функциональных элементов (сложных гридов, к примеру, с сортировками/фильтрами/настройками внутри, или календарик для фильтра по датам) вообще собираются js скриптом полностью - т.е. те же теги и атрибуты тегов - шрифты, цвета, фончики, извиняюсь. Какой css?? Ну и, повторюсь, весь этот хлам без сопроводительной документации. И даже тот факт, что запускающая для проекта страница называется Test.aspx, разработчики должны были понять сами ага. (more…)

О Google Api пишут давно, но как-то мало наблюдаю, чтобы его использовали. Вместе с тем если покопаться, можно найти много простых, но интересных готовых решений для веб-мастеров; к примеру, посмотрим на варианты Google AJAX Feed API, с помощью которых можно у себя на сайте без каких либо сложностей формировать ленты читаемых блогов друзей в разных форматах, прям Google Reader на своём собственном сайте. Для начала следует получить свой API key, уникальный ключ (бесплатно). Для каждого сайта веб-мастера должен быть свой ключ, т.е. у одного веб-мастера может быть несколько ключей. Так же полезно начать с изучения доступной документации, разобрать предложенные готовые примеры. Я для эксперимента выбрала один пример - FeedControl, который позволяет сформировать ленточку фидов блогов, которые я читаю и подписана (подписка в Оперной RSS читалке, которая называется “Каналы новостей”). Пример моей тестовой ленты можно посмотреть здесь.

Сформировать такую ленту проще простого: нужно в хидер, прежде всего, добавить ссылку на скрипт с указанием полученного вами API ключа:

<script type="text/javascript" src="http://www.google.com/jsapi?key="YOUR-KEY"></script>

Здесь вместо YOUR-KEY вы ставите тот самый полученный код. Дальше, если на странице с документацией (ссылка выше) в что-то недопоняли со скриптом, можете воспользоваться визардом для построения ленты. Будут предложены простой вертикальный, динамический вертикальный и горизонтальный варианты. Я выбрала динамический вертикальный, у которого в первом блоке листается поочерёдно пост с аннотацией из всех указанных далее в скрипте лент, а графический маркер указывает, какой пост из какой ленты сейчас динамически высветился в верхнем блоке. Для того, что бы юзер мог сам указывать нужные ленты, ему отдаётся кусочек JavaScript`a, можно сказать, юзерский такой кусочек, с простеньким кодом, в котором он может плодить ленты, задавать титлы для лент, в простом случае из каждой ленты будут выгребаться четыре ссылки на последние четыре добавленных в блог поста. Для моей тестовой ленты юзерский кусок скрипта выглядит так:
(more…)

Помните такой Издательский Дом Питер? У них ещё книжный магазин онлайновый типа. Ага, сегодня, видимо, перепутали 8 марта с первым апреля. Прислали письмо с умильными датами: