По-моему, хороший интегратор — зверь еще более редкий.
Мой, к сожалению, оказался слишком хорошим — его перевели в архитекторы, а мне в помощь отрядили бакэндера, которому еще только предстоит разобраться в XAML.
Я думаю, что каждый веб-дизайнер, владеющий HTML и CSS, может так же нормально работать с XAML. Просто в WPF выше порог вхождения, это нужно знать изначально.
Думаю, это — потенциальная тема для дискуссии. Хорошо, хоть есть с кем обсудить :)
Это очень интресно! У нас проекты большие, но все равно это — оболочки. Давно хотел почитать, как идет работа над операционными системами и подобными вещами.
Технология WPF делает это элементарно. Программист вообще не трогает то, что сделал дизайнер в XAML, он только связывает свой код с ID-именами, присвоенными контролам.
Я дизайню визуалы WPF-приложений и у меня вообще не бывает конфликтов с программистами. Они понятия не имеют об отступах и координатах, всё закладывается мной в XAML-библиотеки и отражается на экране с точностью до пикселя.
Этим работа дизайнера в WPF принципиально отличается от работы веб-дизайнера. По статье может сложиться впечатление, что XAML непостижим для дизайнерского ума и требует усилия специального человека. Это не так.
По-моему, в данном случае просто показана специфика работы в Майкрософт: компания старается унифицировать процесс для разных софтверных платформ.
Если дизайнить без оглядки на веб-технологии (например, большие приложения), то многое меняется.
Я — дизайнер визуалов для больших WPF-приложений, (т.е., вся графика — моя, 100% custom, ничего из дефолтных тем).
— В своей работе не пользуюсь ничем, кроме Expression Blend / VS. Уровень функциональности графических инструментов Expression Blend абсолютно такой же, как и у Expression Design, причем в Blend я сразу применяю нужные панели, и девелоперам в большинстве случаев не нужно ничего придумывать.
— Иконки тоже все рисую в Blend и конвертирую в ресурсы. Программы Adobe не нужны вообще, за ислючением редких случаев, вроде рисования шестеренки (использую векторы, импортированные из Fireworks).
— Все стандартные контролы делаю сам.
— Структуру библиотек с XAML-ресурсами создаю сам, конвенции нейминга ресурсов тоже мои. Иначе просто невозможно держать в голове «что, где и как» и следить, чтобы от спринта к спринту не разваливалась айдентика.
— Да, интегратор есть. Он занимается кастомными контролами со сложными дата-темплейтами, пишет расширения, сделал reference application, частично заменяющую Style- и UX Guides.
— О том, чтобы кодеры, кроме логики, вставляли C# элементы визуализации, и речи не идет. Им вообще запрещено это делать, если я не прошу.
Мне казалось, что мы работаем по той схеме, которая была задумана MS. Возможно, для мобильных приложений, которые мы еще не делали, лучше другие методики. Буду, как говорится, следить за рекламой…
Считают всё, но на больших проектах главный фактор — сделать в срок на должном уровне. В сметы могут закладываться дополнительные расходы на привлечение удаленных специалистов. Они летают постоянно или периодически, при этом в офисе для них держат рабочие места и оплачивают очень существенные расходы по разъездам.
Так возник целый дивизион огромных консалтинговых компаний, вроде Accenture (в штате 250 тыс. работников), Capgemini (120 тыс.) и прочих. Они продают свою рабсилу целыми летучими бригадами, и клиентам она обходится очень недешево.
Нет, там не вопросы экономии — удаленным платят столько же (а аутсорсинг — это совсем другое). Удаленные работники обычно — высококвалифицированные специалисты, каких не хватает в местности, где расположен офис. Находят нужного специалиста вдалеке, а переезжать он не хочет…
Спасибо за высокую оценку :)
Честно говоря, прокрутив в голове ответы на статью о прототипах, я начал писать ответ почти сразу, но быстро надоело, бросил. Потом, дня через три, напрягся и, сильно сократив, домучил :) Жаль выбрасывать дополнителные аргументы и красочные примеры, но если есть ощущение, что иначе до конца не дотянуть, то приходится…
Я спрашивал, почему ссылки имеют движение слева направо, как breadcrumbs, почему аватарки разных размеров и гуляют по инфоблоку, путая ментальную карту, и т.д… Если бы я получил подобный ответ от UX-дизайнера, это означало бы, что все это сделано просто ради композиционных пятен и может быть переделано по моему усмотрению…
Если у визуального дизайнера есть претензии к навигации, пусть аргументирует их и предложит альтернативу, — в чем проблема? Просто дизайнеры UX и визуалов должны работать в контакте.
Да, нормальная схема работы, вовремя вступает дизайнер — после того, как блок-схемы шаблонов напилены.
По второму варианту они выложили только графическую часть, видимо, убрав информацию о UX и проектном планировании, дабы не было слишком нудно. А схема работы может меняться в зависимости от нужд конкретного проекта.
Не сомневаюсть, что они читают книги по UX так же, как читают Эдварда Тафти (о чем «маячат» тем, кто «в теме» :)
Да, слово «симулякр» в данном контексте не является общепринятым. Но оно за свою долгую историю, начиная с платоновских времен, выдержало уже столько разных применений, что может вынести и это :)
Если вас интересует UX, то черпайте информацию из сети и книжек. Хорошо, если есть возможность участвовать в конференциях. Ажиотажный спрос на специалистов по UX возник после того, как Apple натянула всем нос своими тачскрин-гаджетами, т.е. совсем недавно. Не хватает ни преподавателей, ни разработанных методик. В этом даже есть плюсы — эти вещи инновационные и создаются прямо на глазах. Но высшеее образование либо в ИТ, либо в дизайне иметь очень желательно.
Хотя… Вот недавняя история, как человека без профильного образования и опыта работы взяли в UX-группу приличной фирмы. После двух телефонных интервью его вызвали на собеседование, которое оказалось 4-х часовым тестированием, вместе с его потенциальным конкурентом (тот был из программистов, с 6-летним опытом).
После всяких вопросов им дали задание вместе разработать веб-сайт, причем, работодатели сидели и, что называется, пасли все их действия, включая поведение. Тут возник довольно тонкий этический момент, так как каждому из претендентов нужно было показать себя лучшим кандидатом, не топя конкурента.
Взяли обоих, причем, поставили работать в паре, — оказывается, работодатели изначально рассматривали такой вариант и устроили им такой проверочный трюк.
en.wikipedia.org/wiki/Mockup
В русском языке аналога слова mokup я не знаю. Наиболее близким было слово «макет», но макеты могут быть в любом масштабе и иметь сходство с реальным объектом только в общих очертаниях, например, макет застройки микрорайона.
Из этих примеров мне непонятно, как чужие вайрфреймы или прототипы могут мне помешать в работе. Я все равно применю те цвета и графические приемы, какие посчитаю нужными.
Когда UX-дизайнеры приносят мне прототипы, в процессе обсуждения они должны обьяснить и обосновать свои решения. Например, навскидку — по второй картинке:
1. Я вижу, что основной фокус внимания находится в верхнем правом углу. Два второстепенных фокуса — текстовая строка слева, (которая по мощи тянет не заголовок, но находится под информационным блоком — почему?) и оранжевый блок справа. Правильно ли я понимаю иерархию, и почему именно эти части важнее остальных?
2. Я вижу круглые аватарки. Какими соображениями вызвано их размещение то в левом верхнем углу, то вверху посередине, то сбоку справа и применение 3-х разных размеров?
3. В нижней части верхнего левого блока размещены ссылки в виде навигационной цепочки. Почему не в верхней, как это обычно принято? Почему массив ссылок справа тоже напоминает навигационные цепочки с движением слева направо?
Мой, к сожалению, оказался слишком хорошим — его перевели в архитекторы, а мне в помощь отрядили бакэндера, которому еще только предстоит разобраться в XAML.
Я думаю, что каждый веб-дизайнер, владеющий HTML и CSS, может так же нормально работать с XAML. Просто в WPF выше порог вхождения, это нужно знать изначально.
Думаю, это — потенциальная тема для дискуссии. Хорошо, хоть есть с кем обсудить :)
Я дизайню визуалы WPF-приложений и у меня вообще не бывает конфликтов с программистами. Они понятия не имеют об отступах и координатах, всё закладывается мной в XAML-библиотеки и отражается на экране с точностью до пикселя.
Этим работа дизайнера в WPF принципиально отличается от работы веб-дизайнера. По статье может сложиться впечатление, что XAML непостижим для дизайнерского ума и требует усилия специального человека. Это не так.
По-моему, в данном случае просто показана специфика работы в Майкрософт: компания старается унифицировать процесс для разных софтверных платформ.
Если дизайнить без оглядки на веб-технологии (например, большие приложения), то многое меняется.
Я — дизайнер визуалов для больших WPF-приложений, (т.е., вся графика — моя, 100% custom, ничего из дефолтных тем).
— В своей работе не пользуюсь ничем, кроме Expression Blend / VS. Уровень функциональности графических инструментов Expression Blend абсолютно такой же, как и у Expression Design, причем в Blend я сразу применяю нужные панели, и девелоперам в большинстве случаев не нужно ничего придумывать.
— Иконки тоже все рисую в Blend и конвертирую в ресурсы. Программы Adobe не нужны вообще, за ислючением редких случаев, вроде рисования шестеренки (использую векторы, импортированные из Fireworks).
— Все стандартные контролы делаю сам.
— Структуру библиотек с XAML-ресурсами создаю сам, конвенции нейминга ресурсов тоже мои. Иначе просто невозможно держать в голове «что, где и как» и следить, чтобы от спринта к спринту не разваливалась айдентика.
— Да, интегратор есть. Он занимается кастомными контролами со сложными дата-темплейтами, пишет расширения, сделал reference application, частично заменяющую Style- и UX Guides.
— О том, чтобы кодеры, кроме логики, вставляли C# элементы визуализации, и речи не идет. Им вообще запрещено это делать, если я не прошу.
Мне казалось, что мы работаем по той схеме, которая была задумана MS. Возможно, для мобильных приложений, которые мы еще не делали, лучше другие методики. Буду, как говорится, следить за рекламой…
Так возник целый дивизион огромных консалтинговых компаний, вроде Accenture (в штате 250 тыс. работников), Capgemini (120 тыс.) и прочих. Они продают свою рабсилу целыми летучими бригадами, и клиентам она обходится очень недешево.
Честно говоря, прокрутив в голове ответы на статью о прототипах, я начал писать ответ почти сразу, но быстро надоело, бросил. Потом, дня через три, напрягся и, сильно сократив, домучил :) Жаль выбрасывать дополнителные аргументы и красочные примеры, но если есть ощущение, что иначе до конца не дотянуть, то приходится…
По второму варианту они выложили только графическую часть, видимо, убрав информацию о UX и проектном планировании, дабы не было слишком нудно. А схема работы может меняться в зависимости от нужд конкретного проекта.
Не сомневаюсть, что они читают книги по UX так же, как читают Эдварда Тафти (о чем «маячат» тем, кто «в теме» :)
Хотя… Вот недавняя история, как человека без профильного образования и опыта работы взяли в UX-группу приличной фирмы. После двух телефонных интервью его вызвали на собеседование, которое оказалось 4-х часовым тестированием, вместе с его потенциальным конкурентом (тот был из программистов, с 6-летним опытом).
После всяких вопросов им дали задание вместе разработать веб-сайт, причем, работодатели сидели и, что называется, пасли все их действия, включая поведение. Тут возник довольно тонкий этический момент, так как каждому из претендентов нужно было показать себя лучшим кандидатом, не топя конкурента.
Взяли обоих, причем, поставили работать в паре, — оказывается, работодатели изначально рассматривали такой вариант и устроили им такой проверочный трюк.
В русском языке аналога слова mokup я не знаю. Наиболее близким было слово «макет», но макеты могут быть в любом масштабе и иметь сходство с реальным объектом только в общих очертаниях, например, макет застройки микрорайона.
Когда UX-дизайнеры приносят мне прототипы, в процессе обсуждения они должны обьяснить и обосновать свои решения. Например, навскидку — по второй картинке:
1. Я вижу, что основной фокус внимания находится в верхнем правом углу. Два второстепенных фокуса — текстовая строка слева, (которая по мощи тянет не заголовок, но находится под информационным блоком — почему?) и оранжевый блок справа. Правильно ли я понимаю иерархию, и почему именно эти части важнее остальных?
2. Я вижу круглые аватарки. Какими соображениями вызвано их размещение то в левом верхнем углу, то вверху посередине, то сбоку справа и применение 3-х разных размеров?
3. В нижней части верхнего левого блока размещены ссылки в виде навигационной цепочки. Почему не в верхней, как это обычно принято? Почему массив ссылок справа тоже напоминает навигационные цепочки с движением слева направо?
И т.д.