Блог NunDesign

Вот какой странный вопрос по поводу интерфейсов для веб-сервисов образовался.
К примеру, есть некий сервис, в котором пользователь (несколько типов пользователей) заполняет какие-то данные (несколько типов данных). Каждая запись, любого типа у любого пользователя имеет “имя” и “дескрипшин”, которые в интерфейсе выводятся как в табличных формах, в разных списках, так и в формах, которые можно было бы назвать профайлом записи.
К примеру, речь идёт о фиксированном размере интерфеса, хотя на самом деле даже это не суть важно.
И, к примеру, пользователь в качестве имени (а сейчас даже более актуально в качестве описания) вводит неразрывное слово; не существующее в словаре, но каким-то образом отмечающее именно эту запись. Вот так вот 120 неразрывных букв “W” в дескрипшине. Естественно, при публикации этой записи на экране в обычных условиях этот экран разъезжается на всю ширину неразрывного слова. Какие приняты в цивилизованном сообществе разработчиков интерфейсов стандартные решения такой задачи?

1. И пусть с ним. Растягивается интерфейс (или сам интерфейс не растягивается, но запись “выезжает” за правый край интерфейса). Как бы ни было свёрстано, первым методом или вторым, экран смотрится в любом случае некрасиво, но можно сказать, к примеру, что юзер сам себе даун, если делает такие записи, и пусть теперь смотрит на то, что сам ввёл, не нравится - отредактирует запись.
2. “Обрезать” запись в соответствии с общем стилем интерфейса. Здесь есть несколько разных методов, которые можно было бы использовать:
   • С помощью html/css, задавая размер блоку, где публикуется дескрипшин и указывая свойство overflow:hidden; Такая беспробельная запись обрежется по правому краю вполне благополучно, в хинте же (title) можно выводить полный текст записи. Плюс этого метода в том, что те записи, которые содержат адекватные дескрипшины с пробелами между словами, будут отображаться нормально. Минус - для каждой такой записи необходимо указывать фиксированный размер, а ширину в некоторых блоках важно было бы оставить динамическую. А если рассматривать программные методы?
   • к примеру, просто обрезая дескрипшин после какого-то символа, как угораздило сделать нашим программером на текущем проекте. Недопустимый минус - он обрезает и валидные дескрипшины по тому же количеству символов и показывает в одной строке, хотя допустим перенос текста дескрипшина на три строки.
   • Можно было бы писать сложнее, вставляя что-то типа <wbr /> после какого-то количества символов. Но тогда в валидных дескрипшинах тоже будут переноситься слова, и причём в самых неожиданных местах, тоже недопустимо.
   • Каким-то образом определять неадекватные дескрипшины? Есть ли для этого стандартные решения? И на каком этапе их нужно определять? Уже после того, как юзер что-то ввёл и показывается экран со списком введённых данных? Или на этапе заполнения формы, хитрыми валидаторами не давая возможности ввести юзеру неадекватный текст?

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

Девчушку, которая пришла к нам работать недавно верстальщиком на простенькие рекламные сайты (для сложных дотнетовских проектов ей ещё изрядное количество времени придётся нарабатывать опыт), посадила рисовать тренировочные эскизы как бы для этой же ветки веб-сайтов. Честно критиковала композицию, сетку, отрисовку каких-то объектов, оформление навигации, блоков, кнопок. У неё получилось два не очень плохих эскиза, которые, думаю, в компаниях с менее [чем наши канадские] придирчивыми заказчиками, очень даже прошли бы как достойные. А задачу я такую поставила с конкретной целью: не достаточно верстальщику знать html+css, не достаточно очень поверхностных знаний о работе с графикой в фотошопе. Фотошоп - такой же инструмент верстальщика, как и редактор кода, чем доскональнее ты знаешь этот инструмент, чем более гибко владеешь им, чем больше у тебя знаний о том, как создаётся макет рисующим дизайнером, тем быстрее будет твоя работа во время интеграции визуального стиля в реальный сайт, тем проще будет договариваться с твоими же партнёрами по разработке. Здесь речь в ПОНИМАНИИ процесса, ещё одна капелька к статусу ХОРОШЕГО ВЕРСТАЛЬЩИКА, к теме, которую мы обсуждали вчера в комментариях к посту в этом блоге и к ярушной трансляции.

Обсуждение вообще вышло довольно примечательным; я, кажется, с чрезмерными претензиями к личным качествам и профессиональным навыкам специалиста, из которого получается хороший верстальщик, а ребята в комментариях только подчёркивали это; Женя Бондарев писал:

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

В какой-то степени Женя прав, даже с меркантильной точки зрения в нашей компании (где программеров в любом случае раз в 5 больше, чем дизайнеров) хороший (а значит, как минимум ведущий) программист будет получать больше хорошего верстальщика, но здесь вот ещё в чём сложность расчётов: на больших проектах задачи распределяются на подзадачи и направления, и кроме PM`а на проекте есть несколько подкоманд программистов, каждой из которых управляет ведущий программист, лучший. Т.е. он не только лучше всех программирует, он ещё занимается менеджерской работой, распределяет задачи внутри своей команды и отвечает за качество кода своих подзадач. Это всё-таки другая ответственность. К сожалению, всегда бывает так (это я по себе знаю), что большую часть задач, которые ставятся перед командой, ведущий специалист может выполнить сам, и, более того, быстрее, лучше, качественнее (и дальновиднее, потому что умеет видеть проект в целом и перспективу), но задач в какой-то момент становится несколько… больше, чем может выполнять один человек за один рабочий день, а клонировать этого самого ведущего программиста пока технологии не позволяют.

(more…)

Как часто заглядываете вы в статистику вашего сайта или блога? Оценить кривую посещаемости, отметить новых реферреров, ковырнуть да перепроверить страницы, на которых чаще всего “сразу” закрывают ваш сайт? Почитываете список ключевых слов, по которым находят вас в поисковиках? Если манимейкерский у вас проект, то, может, и каждый день, а ежели блог для души да без рекламы, то хотя бы раз в месяц неплохо бы проверять данные. Сегодня глянула и я в Google Analytics да некоторые рейтинги; кое-что порадовало, кое-что напомнило о том, что своими проектами неплохо бы хоть иногда заниматься. Обратила внимание на статистику по “ключевым словам” для этого блога: очень много людей приходит по “верстальщик”, “кто такой верстальщик” и даже “нравится ли вам работа верстальщиком?” Кто такой, кто такой… наша бухгалтерия говорит, что нет такого в реестре должностей, придумали вы что-то, господа хорошие.

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

(more…)

У спамеров от июльской жары совсем крыша потекла. Спамят глубокоуважаемым Тимофеем Бокарёвым, комментами в блог на 3-4 экрана: биография Тимофея Бокарёва, история promo.ru, основы баннерной рекламы… Знает ли герой спамерских текстов о том, как его “пиарят” по блогам? Вообще ужасно, как легко можно спровоцировать негативную реакцию у массовой аудитории на любую известную личность; даже если прозрачно, что это дешёвая провокация, раздражение всё равно появляется.

Ещё начали массово спамить с формы с заброшенного чуток nundesign.com, давно надо было доработать, всё-таки иногда от туда пишут полезности и заказы, а выгребать нужное письмо из сотен писем спама — нет ни времени, ни терпения. Хотя даже и валидные сообщения приходят такие, что сидишь над ним, медитируешь - грохнуть как спам, не раздумывая, или ответить. Чаще всего это письма с “предложениями” по обмену ссылками или просьбами выступить спонсором очередного SEO-конкурса. Да, признаюсь, как-то под настроение и в самом деле несколько раз соглашалась стать спонсором конкурсов, но это, скорее, случайность, и вряд ли в ближайшие месяцы подобное настроение у меня возникнет ещё раз. Поэтому, ребята, извиняйте, но заявками закидывать меня не надо. И если уж пишите… Хоть немного прорабатывайте тему.

В комментах к одной из записей вчера появился вопрос как раз по теме:

Вот и ответ: с исследования о том человеке, к которому собираетесь обращаться.

1. Узнайте его имя (+фамилию), ваше обращение должно быть адресным. Месседжи с шаблонным текстом типа “к вашей компании”, очень похожие на массовую рассылку, с большой вероятностью будут удаляться (я удаляю).
2. Пробейте нишу, в которой работает нужный вам человек. Практически всегда речь идёт об IT отрасли, веб-разработке или раскрутке сайтов, SEO, и если уж вы вышли на этого человека, поищите на авторском сайте или в сети информацию о нём, скорее всего найдёте много чего (для публичных особ это обычное дело), что может вам пригодиться для конструктивного диалога.
3. Смешно говорить, но поищите информацию о его возрасте. Нелепо выглядят заявочки типа “привет, не хочешь ли ты поучаствовать…”; и когда я, уже со своей стороны, провожу разведку про отправителя и выясняю, что пишет юнец молодой человек неполных 20 лет от роду, мне, без малого 40-летней тётке, я не то, чтобы раздражаюсь, но отмечаю для себя, что человечек, вероятнее всего, поверхностный и ненадёжный. Одно дело где-то в блоге флеймить на вольную тему, там допустимо, и другое совсем дело — обращаться ПЕРВЫЙ РАЗ С ДЕЛОВЫМ КОММЕРЧЕСКИМ ПРЕДЛОЖЕНИЕМ.
4. Полезно будет сослаться на реферреров, которые вас направили к этому человеку. Если это общие знакомые, так и пишите: ВасяПупкин порекомендовал… или нашёл в поиске ваш сайт, в одной из ваших заметок вы пишете “…”, по этому поводу у меня есть… или как-то ещё полезно обозначить историю выхода на того, к кому вы обращаетесь.
5. Если вы обращаетесь с просьбой порекламировать, опубликовать пресс-релиз или обменяться ссылками, вы уж указывайте, на каком ресурсе вы хотели бы разместиться, заявления в почту “мы хотели бы разместить у вас на сайте…” я чаще всего оставляю без ответа, изредка под настроение переспрашиваю “на каком именно?” Да, у некоторых людей более одного сайта, это правда.
6. Если вы хотите обратиться с вопросом, прежде всего до начала общения с человеком сформулируйте этот вопрос сами себе. Довольно часто бывает, что человек что-то спрашивает, но через пол часа диалога выясняется, что человек сам не знает, чего хочет.
7. Если обращаетесь с заявкой, будьте готовы к оперативному обсуждению. Если документация и ТЗ ещё не готовы, то так и пишите: для начала хотел бы узнать, возможно ли “какое-то такое” сотрудничество в принципе, и если да, то напишите, когда бы вы могли дать больше информации о заявке. Тягомотина пол-часа в мессенджере, после которой оказывается, что ещё не понятно, нужно рисовать что-то или нет, и что именно рисовать, и после чего “заказчик” неожиданно вообще пропадает из диалога, это убитое время непростительно, и второй раз я на диалог, вероятнее всего, уже не пойду.
8. По поводу просьб о публикации пресс-релизов, о том, как надо делать и что делать нельзя, несколько раз очень хорошо писал в своём блоге Женя Шевченко, ссылку прямо сейчас не дам, ибо блог про рекламу у него не жив, а в его ЖЖ-шном дневничке этих текстов не нашла. Повторяться не буду. UPD: Нашёлся текст на itua — “Рассылка новостей в Интернет как составляющая PR” — там и по сегодняшней теме в том числе есть.

Это некоторые рекомендации по поводу того, “что нужно сделать до…” и “с чего нужно начать”. Может, я дополню этот список, может, что-то дополните и вы, из вашего опыта.

Ещё вчера, пока писала “Офисное дизайнерское: стандарты и договорённости” была уверена, что столько всего нужно записать из “правил и договорённостей”, важных для успешной командной работы дизайнеров, а как до дела дошло, так, кажется, и писать нечего. Большая часть - такие очевидные вещи, что даже странно, что их нужно оговаривать особо. Но, с другой стороны, если были прецеденты больше двух раз, значит, имеет смысл записать себе очередной пунктик.

Вот, к примеру, такая интимная вещь, как организация фолдеров и файлов на дизайнерском компьютере: каждый, кто приходит в офис, пытается создать себе такую структуру, какая уже была у него на домашнем компьютере или на предыдущей работе. Иногда рабочие файлы запрятаны в глубь поддиректорий или даже разбросаны по разным дискам — от десктопа и “My Documents” на C: до совершенно невообразимых путей разной глубины на других дисках. А представьте себе, если по ходу горячей работы дизайнер внезапно не пришёл с утра на работу (мало ли, заболел), или, что ещё чаще бывает, в конце рабочего дня отправил эскиз и благополучно ушёл домой, и тут обнаруживается, что в отправленном допущена ма-а-аленькая ошибка, которую НАДО исправить сегодня, потому что она должна уйти в работу для канадских интеграторов, у которых рабочий день только начался. И что? Им терять целый рабочий день?

Я, обычно, всё равно задерживаюсь на 2-3 часа позже остальных наших творческих личностей, и часто бывает так, что по ходу дорабатываю что-то из их исходников (ошибки или замечания канадских менеджеров), но запоминать все уникальные структуры для файлов надоело. А компы дизайнерские все типовые и размечены одинаково на два диска, С и D. Поэтому был введен локальный корпоративный стандарт:

• Все рабочие проекты живут на диске D в папке projects, в которой создаются папки с именами, соответствующими проекту, для которого ведётся работа. Даже если по этому проекту дизайнеру нужно было нарисовать одну единственную иконочку - исходник для неё, версии и результирующий файл должны лежать в папке с именем этого проекта, никаких temp или other!
• Если проект контролируется через SVN, папка с дизайнерскими исходниками по проекту должна лежать в общей папке проекта, просто не добавляется в SVN.

Следующий трабл обнаружился, когда оказалось, что дизайнеры нифига не хотят уделять внимание именам файлов тех эскизов-иконок-экранных окон, которые они создают/отдают в работу верстальщикам или программерам. И ходит в работе очередной “test123.png”, потом “Первая Проба 123-1.png” (ага, вот так вот, через пробелы), потом “!!!my last test123-5.png” или ещё что похуже, и разобраться в собственных версиях картинок, или даже идентифицировать быстро, для какого проекта какая из картинок рисовалась, в какой-то момент не может уже сам дизайнер, не говоря о том, какие проблемы возникают, если нужно срочно передавать его работу другому. Поэтому мы договорились именовать файлы так:

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

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

Это я привела достаточно абсурдный пример, знаю, хотя он не придуманный. Основные же договорённости всё равно касаются проблем с исходниками скетчей. Опять же, большая часть из них очевидны и тыщу раз озвучены веб-мастерами, но увы, приходится об этом писать опять и опять, и, если со своими договориться получилось сразу, то канадская команда упорно не хочет придерживаться этих правил. Итак, про .psd исходники:

• Все слои должны быть именованы в соответствии с содержащимися в них объектами. Группы слоёв должны быть объединены в Set`ы (Groups) требуемой вложенности, и тоже должны быть именованы. Все эти Layer68 и Group29 - самый удобный способ запутать партнёров по проекту.
• В случае, если в одном файле включены группы слоёв для разных экранов (разных разделов сайта или программы), базовые группы должны полностью визуализировать экран. Чтобы не надо было догадываться, что для экрана такого-то нужно включить второй слой (контент), 28-й (шапка с формой) и 69-й (меню с правильно подсвеченным элементом меню), а для… ну, понятно, в общем.
  

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

• Cценарии поведения объектов - кнопок, табов, элементов меню.
  

  Замечательно получилось, когда на один из проектов дизайнер всё хорошо сделал и продумал - и структура групп, и имена слоёв. Картинка была хорошо порезана, проект (не web, а windows приложение), всё скомпановано. Потом дизайнер уволился, а у нас возникла задача сгенерить интерфейс для языковых версий. А навигация по разделам вся — рисованная, и по задумке дизайнера все элементы навигации - чуть отличаются друг от друга, и каждый элемент при этом имеет пять состояний (normal, active, over, press, disable). И сценарий на смену каждой кнопки дизайнер ДЕРЖАЛ В УМЕ: вот для нормальной “этот” слой - 80% opacity, для over - 100%+включается “вот этот слой”, для disable - 63% + выключается “вот этот слой”. Замечательно, но как мы с другим дизайнером, которого спешно пришлось ставить на этот проект, “угадывали” эти сценарии для генерации состояний элементов… в общем, такого быть не должно.

• Ещё немного очевидных вещей - типы шрифтов. Правила должны быть достаточно строгими: для текстов, которые будут использоваться в проекте, использовать только стандартные шрифты, все тексты с нестандартными шрифтами завёрстываются картинками. Уж сколько раз твердили, повторяли, настаивали…
  

  Очень любят канадские дизайнеры использовать в эскизе “шрифты, похожие на стандартные”! И обидно, что с т.зр. визуала (это важно при презентации своего скетча руководству, чтобы утвердили побыстрее) макеты с этими “почти похожими” и в самом деле смотрятся значительно элегантнее. а на наши угрозы со словами “все тексты, которые отвёрстаны нестандартными шрифтами, будем ставить КАРТИНКАМИ” руководство вяло отбивается “да нет, ставьте текстом… подберите что-то там наиболее близкое…”

• Anti-aliasing — больная тема. Опять же, если текст должен в проекте быть текстом, он и в эскизе должен быть не размытым, с выключенным anti-aliasing (=none). Очевидно? Казалось бы, да, но упорно не соблюдаемо.
  

  Это вызывает серьёзные спорные моменты, особенно для заголовков, которые (в сл. веб проектов) или жирные, или не жирные, сделать вёрсткой заголовок, который должен быть текстом, стандартным шрифтом и чуточку тяжелее, чем его regular (заметно на тех же, скажем, Tahoma+regular+Sharp anti-aliasing) практически не возможно. И, как всегда, отмазка, мол, сделайте уже как-нибудь.

• Стандартные эффекты. Так же, как и в случае со сценариями, где нам приходилось угадывать свойства слоёв для состояний кнопок, так же часто невозможно угадать, какие свойства и эффекты применялись к слою перед тем, как дизайнеру вздумалось отрендерить слой в “простой”.
• Стандартные объекты. Значительная часть дизайнерских скетчей легко раскладывается на стандартные объекты - прямоугольные (четырёхугольные или со скруглёнными углами заданного радиуса), окружности-овалы, должны оставаться векторными формами. То же касается сложных форм, нарисованных пером или интегрированных из векторного редактора, то же касается векторных масок.

Хорошую заметку прислали, на английском, специально прямо для наших канадских творцов: “10 Tips For Creating Website Mockups In Photoshop“. Но я бы не стала так уж прямо привязываться к первым двум пунктам, или же сформулировала бы по-другому. Всё-таки простые формы в дизайне экранов - это частный случай, а не обычное решение. А как часто и мои дизайнеры, и я сама в скетче что-то не векторное дорисовываем ручками, доводим до идеального состояния. Да, эскиз получается не масштабируемый легко, ничего не поделаешь. Простые векторные формы, плоский стиль подходит не для 100% задач.
Ещё важно, из того, что должен отслеживать дизайнер на этапе создания макета (а не отдавать на волю верстальщика или программиста) — как должен выглядеть интерфейс при разных разрешениях экрана:

• если дефолтный скетч рисуется для разрешения экрана 800х600, проверить, как он будет смотреться при разрешениях 1200х1024, 1600х1200;
• если предполагается резиновый дизайн, показать, как он будет тянуться и куда что ползёт, какие элементы продолжают выравниваться от центра экрана, какие выравниваются по правому/левому краю, как изменяются размеры панелей;
• если предполагается фиксированный дизайн - показать выравнивание по отношению к центру экрана;
• то же касается экранов для windows-программ - как выглядит интерфейс при изменении размеров программы, её минимальный размер + full screen.
• если предполагается фиксированный дизайн, но с неоднородным основным фоном, показать поведение фона при изменении размеров окна и (к примеру) центрировании рабочей области.

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

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

• дизайнер уходит в отпуск (замечательная причина, я считаю!)
• дизайнер заболел, и не меньше чем на две недели (будьте здоровы, дорогие!)
• дизайнер отпросился по семейным обстоятельствам (это, обычно, несколько дней, но проект-то ждать не будет!)
• дизайнера просто приходится переводить с одного проекта на другой (сложная причина. Иногда необходимо это делать несмотря на то, что этим дизайнером уже выполнено 70% работы.)

В последнем случае такое может происходить, к примеру, если дизайнер справляется с трудом, ему, к примеру, не интересно, или не получается, и эффективность от участия его именно в этом проекте низкая, и предполагается, что если его перевести с этого проекта1 на проект2, а его работу перепоручить другому дизайнеру, то эффективность по обоим проектам возрастёт. Бывает так, что дизайнер из команды уходит надолго или совсем, и никуда не денешься от того, что его проект перепоручается другому:

• дизайнер уходит в декретный отпуск (и это тоже замечательная причина!)
• дизайнер увольняется потому, что ему предложили что-то получше (для любого человека естественно выбирать лучшее предложение из имеющихся, глупо ведь взывать к смешным “верности компании” или прочим абстрактным сущностям)
• дизайнер увольняется потому, что ему не интересны задачи, которые ставятся в этой компании (мало ли, человека в 3D тянет, а здесь у него сплошь плоские интерфейсы, юзабилити какое-то и прочая чушь)
• дизайнера увольняют (тут причин может быть много, они описывались уже раньше в заметках “Почему увольняют дизайнеров?” и “Дизайнеров увольняют потому что… Продолжение“.)

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

Весной была довольно объёмная работа над одним приложением. Помимо прочих “элементов дизайна” необходимо было разработать в едином стиле 12 полноформатных иконок для базового приложения и для его подприложений, каждая с фреймами 256×256, 128×128, 64×64, 48×48, 32×32, 16×16, каждый размер в решениях 32 бита и 8 бит. Ничего сложного, но у нас с иконочной графикой дизайнеры возиться вообще не любят, совсем пиксельные стандарты (на 16 цветов и на 2 цвета) не были нужны, но всё равно для мелких размеров в 256 цветах обычно нужна ручная догонка фреймов. Программист сделал 11 иконок из 12 и… вынужден был по важным семейным обстоятельствам отпроситься в отпуск на неделю. По проектным срокам иконки должны были понадобиться дней через 10, поэтому отпустили без проблем. Но у нас как всегда: внезапно изменилась погода, всё перекроили, где-то на горизонте замаячили инвесторы и сообщение о том, что презентация - в пятницу, до которой три дня. Я перевожу “доработку” последней иконки на другую девочку, тоже талантливую и умелую. Пол дня она пыталась… нарисовать эту последнюю иконку в стиле предыдущего дизайнера. Потом забила и за полтора дня ПЕРЕРИСОВАЛА все 12 иконок в почти (почти!!!) том же стиле, но всё же немного по-другому, в соответствии со своим видением правильного набора иконок. Её иконки оказались удачными вполне, работу утвердили, а 11 иконок предыдущего дизайнера, неделя работы, оказались просто не востребованными (хотя по виду тоже ничего, не плохо).

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

Тогда в дизайнерском офисе вынуждены вводить какие-то внутренние стандарты и договорённости, да.

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

Нас пинают, чтобы мы не забрасывали изучение Silverlight`а, ещё с нового года, если не раньше. Никаких серьёзных проектов на нём мы не затеваем, но и совсем забрасывать этот, с позволения сказать, перспективный инструмент для разработчиков не разрешается, поэтому ваяем потихоньку никому не нужные бесполезные тестовые проектики, программеры исследуют свою часть, дизайнеры - свою. Для коммерческих проектов использовать Silverlight пока никто не рискует, не столько с нашей стороны (разработчиков), сколько со стороны руководства и маркетингового отдела, у которого есть глубокие сомнения в целесообразности использовать SL в неопределённо долгое “ближайшее” время. Прежде всего, естественно, потому, что именно с них, с маркетингового отдела спросят, где посетители на очередном сайте, и как успешно они конвертируются в заказчиков? И не закрывает ли каждый первый страницу, на которую он попал, только потому, что у него не грузится контент страницы СРАЗУ?

Кроме того, что технология новая и малообкатанная, успешных разработчиков, хорошо понимающих SL, на сегодняшний день мало или даже можно сказать нет (но можно сказать, что есть начинающие изучать и даже добивающиеся некоторых, гм., успехов), мало того, что браузеры юзеров ещё девственно чисты и для доступа к контенту соотв. сайтов нуждаются в доустановке соответствующих типа плагинов, смущает наших маркетологов и то, насколько успешно можно будет продвигать такие сайты в поисковых системах, насколько хорошо будет индексироваться контент и все прочие связанные с SEO вопросы. Вопросы эти висели в пассивном состоянии, серьёзных исследований никто не затевал, но после недавней новости о переговорах Adobe с Google&Yahoo по поводу флеш-контента публика вновь засуетилась, и, как я поняла, не только у нас. По теме нашла опубликованный вчера пост одной довольно широко известной в узких кругах дамы по имени Мери Джо:

Когда Adobe, Google и Yahoo анонсировали в начале этой недели, что контент, который содержится в файлах формата Flash будет ещё более легко индексируемым поисковыми системами Google и Yahoo, Microsoft там не участвовал.
Кажется, я помню, как Redmondians и его сторонники, когда сравнивали Silverlight с Flash`ем, убеждали аудиторию в том, что Silverlight контент легче видим для поисковых систем (и не только для Live Search). Мне это что, приснилось? Я запросила у Microsoft подтверждение и получение следующих утверждений от представительницы компании на 2 июля:

Microsoft изначально проектировала Silverlight легко доступным для поисковых систем. Потому что это простой ZIP архив, а Silverlight приложения упаковываются в XAP (это расширение файлов исполняемых пакетов Silverlight`а) файл, легко доступный для поисковых систем без специального SDK (software development kit). И потому, что XAML - это W3C-совместимый XML, любой статический текстовый XAML легко разбирается поисковыми системами. Кроме того, любые мета-данные, которые включаются в ZIP файл, так же легко индексируются поисковыми системами. Silverlight приложения так же поддерживают “deep linking“, поскольку легко разбирают загружаемый URL,  и используют информацию из строки запроса в URL для быстрой загрузки и отображения соответствующих данных. И в заключении, Silverlight DOM сам по себе может легко проверить на обнаружение все тексты, ссылки и картинки, которые визуализируются в контроле.
“Т.е., средства, которые предлагает Silverlight пользователям, прекрасно оптимизированы для поисковых систем? Да. Silverlight не только сконструирован так, что предполагает отличную искабельность, но и великолепен для включения публикаций динамического контента из систем управления контентом, который легко индексируется поисковыми системами. При публикации динамического контента Silverlight типа XAML и XHTML отображения, пользователи компетентны в эффектном уменьшении времени для оптимизации контента для поисковых систем.”

И другие вопросы, на которые я не получила ответ: может ли Live Search индексировать Flash контент сегодня и насколько хорошо? (остался без ответа. Хотелось бы видеть, что Microsoft может сказать об этом)
UPDATE: Ina Fried из News.com говорит: Microsoft не комментирует этот вопрос… По крайней мере сейчас.
Проводил ли кто-нибудь из SEO экспертов или разработчиков/владельцев сайтов хоть какой-нибудь сравнительный анализ, чей контент - Flash или Silverlight, находится лучше? Думаете ли вы, что новые соглашения с Google и Yahoo (но без Microsoft для Live Search) дадут Adobe преимущества над Microsoft на этом фронте? Если да, почему?
Тем временем было объявлено о том, что Microsoft запустила пилотную версию Silverlight Streaming для рекламных блоков (только для USA, для тех, кто может заполнить форму W9), для которой ещё в начале весны была начата регистрация тестеров. “Эта пилотная программа разрешает вам аплоадить видео контент в Silverlight Streaming и воспроизводить его с контекстной рекламой релевантно воспроизведению событий, основанных на ключевых словах, которые вы присоединяете к вашему видео, когда вы его загружаете, или позже в настройке свойств этого видео,” следует из текста поста в блоге Windows Live Dev.
(Silverlight Streaming — сервис Microsoft’а для Silverlight rich media content`а.)

Сегодня нежданно напомнил о себе сервис LiveLib — книжная социальная сеть, которая завелась как-то в рунете чуть больше года назад, та так и живёт себе потихоньку, малозаметная и скромная. И вот, с целью, так сказать, популяризации в массы, решили LiveLib затеять конкурс в стиле “приведи друга, получи iphone!”:

Первый победитель получит Apple iPhone, следующий призёр получит Apple iPod Nano, и ещё три призёра получат Apple iPod Shuffle каждый. Призы будут переданы победителям лично или отправлены им удобным для них способом.
Условия:

1. Чтобы стать участником, достаточно зарегистрироваться.
2. Победителями будут те участники, которые пригласят наибольшее количество новых пользователей сервиса за время проведения конкурса. Приглашённые идут в зачёт после того, как добавят в свою коллекцию 10 прочитанных книг.
3. Приглашённые должны подтвердить свой email, а также указать свои имя, город и страну — это тоже непременные условия.
4. Конкурс продолжается до конца июля. С наступлением 1-го августа по московскому времени учёт приглашённых пользователей прекращается. Итоги конкурса будут подведены в пятницу, 1-го августа.
5. Каждый приглашённый должен быть настоящим человеком. Не разрешается регистрировать множественные аккаунты самостоятельно, предлагать за регистрацию деньги, материальные или нематериальные бонусы, пользоваться автоматическими средствами регистрации и рассылать или размещать в каталогах спам с приглашениями. Это грозит дисквалификацией.

Мы рассчитываем на честную игру и надеемся, что она принесёт удовольствие тебе и твоим друзьям!

Как-то и я там зарегестрировалась, и даже писала о сервисе в ЖЖ-шном блоге (этого тогда ещё не было), и, кажется, даже планировала пользоваться, но не пошло, какого-то комфорта и соответствия моей жизни не было. Но если кому-то интересно, вы регистрируйтесь тогда с моей ссылки http://www.livelib.ru/register/nundesign, с моим фартом призов мне всё равно не светит, но вдруг кому-то понравится такая онлайновая библиотека.

А вообще-то сегодня я планировала написать про совсем недавно обнаруженное IT Community, но, к сожалению, это замечательное детище от M$ глючит и недоступно. Регистрация на сервисе там = активации аккаунта Windows Live ID, а тот, в свою очередь, радует некоторыми техническими проблемами (но не обещает, кстати говоря, то они будут решены и когда они будут решены):

Что-то меня это не удивило, этот если честно.

Да, и вот ещё новость недельной уже давности. Как-то после более чем годового забытья напомнили мне про I2R-вский форум, заброшенный вместе с библиотекой ввиду малосмысленности однобокого развития проекта без его библиотечной i2r`вской базы. Да просто так напомнили - в аську написали разные, не знакомые между собой люди о том, что форум заспамили, и как же так, и всё такое. Я старательно делала вид, что мне глубоко пофигу весь i2r, но тут пришло строгое письмо от Google AdSense, где попрекали меня недопустимым конетнтом на одной из площадок (ну да, на форуме же), где размещены объявы АдСенса. Давно надо было снять, да забылось, в статистике адрес не мелькался, денег с форума не капало, плюс отношение “вычеркнуть, забыть и не расстраиваться”. В общем, пришлось разыскивать логины-пароли на доступ к форуму, грохать (для начала) гугловский код нафиг, потом - упомрачительное количество порнухи во всех темах. Мда.

Интересное наблюдение: больше всего порнушными картинками и текстовыми постами была завалена тема под названием “Пофлеймить и поговорить за жисть”, что-то около нескольких тысяч постов. Меньше всего - раздел “вёрстка” - меньше 50 постов. С чего бы вдруг такое корректное поведение у злостных спамеров? В общем, поудаляла грязь и закрыла все разделы, вообще. На модерацию времени нет, собирать серьёзное тематическое сообщество - нет смысла, зазывать волонтёров или нанимать недорого студентов для поддержания относительного порядка - не возникло желания. В общем, очередной досвидос i2r.ru