Не вижу связи. Дизайнер следит за эргономикой, юзабельностью, соблюдением брендинга. За соблюдением удобства использования должен следить дизайнер взаимодействия. А за качеством реализации кода — девелопер менеджер.
И нет ничего плохого в том, что дизайнер делает «бумажные» прототипы. Этому их учат и это они умеют делать хорошо. Опять же, для каких целей. Для целей выяснения юзабилити бумажные прототипы ничуть не хуже, чем сделанные в виде ПО.
Я не спорю про то, каким должен быть «идеальный» дизайнер. Я говорю про то, что чем более точно будет проработана документация (и особенно — сценарии использования продукта), тем проще будет работать и самому дизайнеру, и всем остальным членам команды.
А говорю я про это в контексте того, что первично: прототип или документация. Я стою на стороне того, что документация первична. На начальном этапе прототип уместен только в случае, когда надо что-то протестировать или когда просто нет другого способа уточнить общее ТЗ. Замещать подготовку документации прототипированием, как это предлагает топикстартер, на мой взгляд не верно в корне.
Опять повторюсь: всё зависит от выработанного в компании процесса работы. Если команда не большая, то да, дизайнер может и с прототипами поиграться, и в ТЗ поковыряться… В серьёзных конторах, когда «на конвейере» одновременно несколько проектов, а дизайнер — только один (а он, как правило один, ибо это очень дорогой и узкопрофильный специалист), то его рабочее время расшарено между проектами, и у него даже при всём желании нет возможности «поиграться» и «поразбираться». Максимум, как можно задействовать дизайнера в таком случае на ранних стадиях — привлечь его к согласованию ТЗ, дабы в него не прокрались «воздушные замки». Прототипированием такой дизайнер если и будет заниматься, то только в случае, если такие работы заранее прописаны в проекте и руководство дало «добро» на это.
Мне кажется, идёт выдача желаемого за действительное.
Дизайнер интерфейсов — как резчик. Бывают резчики по дереву, по кости, по металлу… Специальность — одна, а вот специализаций — множество. Поэтому вполне логично, что дизайнер, имеющий очень хорошую квалификацию в разработке UI под MAC, будет очень долго приспосабливаться под Android. Даже в эпоху расцвета Windows Mobile дизайнерам с десктопной винды приходилось приспосабливаться под мобильную, и хороших дизайнеров под мобильные приложения было не найти. А выцепить на hh.com сразу специалиста по дизайну UI под Android просто так вряд ли удастся и сейчас.
Я это все говорю к тому, что тезис о понимании дизайнером аспектов реализации тех или иных интерфейсных элементов в коде и о предугадывании дизайнером аспектов программирования — это некая идеализация, которая хотя и может быть достижима в отдельных идеальных случаях (ваш дизайнер в комманде уже 5 лет и на мобильных интерфейсах собаку съел), в большинстве случаев остается утопией.
Поэтому всё то, что в вашем примере вам кажется логичным и само собой разумеющимся, должно быть детально отображено в документации, которую получает на руки дизайнер UI прежде чем приступить к работе. И именно в документации, а не на словах, иначе вы рискуете провалить сроки. И документация при этом должна оперировать понятиями общей функциональности и логического взаимодействия, а не описывать «кнопочки» и «скроллбары».
Прочитал я статью Скотта Беркуна, спасибо за ссылочку. Интересно, но есть о чем поспорить. Думаю, надо разделять общую идеологию и конкретные случаи, когда наиболее оптимальное для данного конкретного случая решение может отличаться от идеального очень сильно.
Мне кажется, мы говорим о разных «дизайнерах». Вы больше говорите о «программисте, реализующем интерфейс». Я же говорю о дизайнере, который даже не имеет понятия, как интерфейс реализовывается программным кодом. В задачу такого дизайнера входит не только реализация интерфейса конкретного приложения, но и соблюдения общей идеологии интерфейса, принятого для компании, соблюдение требований BrandBook-а и тому подобное. Т.е. он может быть, был бы и рад поразбираться во всех тонкостях реализации алгоритма, да времени нет…
— 2. Изучение дизайна
3. Изучение технологии
— Это все не имеет прямого отношения к конкретному проекту. Это все НИОКР. Хочется заказчику оплачивать ваше обучение и разработки — ради бога. Большинство за подобные вольности порвет на британский флаг: «Я вам деньги не за это плачу!!!» Не зря перед проектом HR получает четкие требования к персоналу — по каким требованиям какие скилзы должны наличествовать.
А привлекать пользователей на ранней стадии — себе дороже. Гораздо важнее с ними тщательно проработать сценарии. А показывать — только альфу…
Дизайнер обычно не участвует в подготовке маркетинговых документов, т.е. — в начальной проработке ТЗ. Обычно он получает его уже готовым. И лучше всего, если это ТЗ оперирует понятиями, отвязанными от интерфейса конкретной операционки. Только если разрабатывается что-то принципиально новое, то дизайнер привлекается для согласования на предмет трудозатратности реализации той или иной функциональности.
Давайте уточним, о каких типах проектов мы говорим? Я говорю не про стартапы, а про производственный процесс, когда продукты эволюционируют и развиваются. В таком случае роли в процессе разработки ПО уже четко распределены, и на позиции дизайнера UI находится действительно дизайнер, а не разработчик, освоивший Expression Blend. Если же говорить о стартапах, то тут все может быть очень кучеряво.
Есть хорошее правило: «Прототипировать надо только то, что нужно проверить. Т.е. реализовывать в прототипе нужно столько функциональности, сколько необходимо для проверки гипотез, ответов на вопросы и уточнения понимания Требований.» Если отойти от этого правила, то работа над прототипом очень легко выходит из под контроля, и есть очень большой шанс, что на подготовку нормального рабочего решения уже не хватит времени и ресурсов.
Второе. Прототипирование не должно подменять собой другие необходимые маркетинговые действия, и прежде всего — проработку сценариев использования. При проработке сценариев очень важно оперировать платформо-независимыми и интерфейсо-независимыми критериями. Попытка сперва нарисовать интерфейс, а потом описать сценарий использования этого интерфейса порочна. Дизайнер не владеет полностью идеей продукта, поэтому рисовать его будет в меру своего понимания, а потом вдруг оказывается, что именно такое кривое видение оказывается закрепленным в ТЗ.
В третьих, при таком раннем прототипировании есть очень большой шанс, что заказчики и пользователи начнут воспринимать прототип как «почти готовое приложение».
Но самое главное и самое большое возражение вот в чем. При раннем прототипировании, когда сценарии использования еще не проработаны, дизайнер, даже если у него есть общее описание логики работы программы, не владеет информацией о приоритезации различных частей программы. В результате он будет долго и тщательно прорисовывать экраны дополнительных настроек, а главные экраны могут быть не проработаны. При демонстрации подобного прототипа мнение о продукте у пользователей/Заказчика сложится совершенно неадекватное. Поэтому «горизонтальное» прототипирование можно делать только на этапе, когда сценарии уже завершены, общая конфигурация продукта согласована и утверждена.
Ну, для начала надо предложить четкий математический метод определения, почему приоритет у сообщения о том, что моя жена хорошо поужинала, выше, чем у сообщения, что где-то в другом городе сгорела квартира. Дальше уже все просто.
Резонный вопрос: а зачем вообще нужны какие-либо сообщения к пользователю, требующие от него неких действий? Все упирается в детальную проработку сценария взаимодействия пользователя и программы. Т.е. сценарий должен быть выстроен таким образом, чтобы (1) с максимальной лёгкостью выполнять текущую задачу; (2) обеспечивать легкий переход по ветвлениям сценария, если таковые предусмотрены; (3) на каждом конкретном шаге должно быть предельно ясно, что именно делает пользователь, что он должен и хочет увидеть, и что ему в данном случае совсем не нужно видеть.
Правильно ли я понимаю, что первоначально пользователь должен сам указать, что именно он собирается разпознавать на изображении, и только потом запускать камеру? Распознает только по одной строке/адресу? А автоматически «вылавливать» из фотографии что попадется не получается?
Статейка, может, и не плохая, но «хороша ложка к обеду». Дата публикации в 9 декабря, когда телефон уже больше полугода как продается, доставляет.
И, кстати говоря, на 6 фотографии надо было писать не Flash, а LED Flash. Ибо в аппарате не импульсный источник подсветки (как в том же Mozart), а светодиодный.
Грация — не клон ну просто ни разу. Другой формат дисплея, другой форм-фактор, другая батарея, другие кнопки.
Что лично мне не нравится в WP7. Сразу говорю, будет эмоционально… Нервным, боящимся, что их хрустальная мечта детства будет растоптана грязными сапожищами, лучше дальше не читать.
1. «Дизайн-1» Как человеку практичному, все эти «летающе-вылетающие окошки» как-то по-барабану. Мне нужно, чтобы было быстро и удобно. Летающий Metro — это красиво… первую неделю… потом начинает немного подбешивать…
2. «Дизайн-2» Кинетический скроллинг смотрится красиво… пока тебе не нужно реально им пользоваться. Когда тебе реально нужно быстро найти и запустить нужную программу — приходится тратить КУЧУ лишнего времени на то, чтобы гоняя список туда-сюда таки найти нужный ярлык. В этом плане концепция рабочих столов iPhone мне нравится гораздо больше: ты чётко знаешь, что нужный тебе ярлык размешен на 3-м столе, слева в третьей строчке. Ты запускаешь его моментально, не тратя лишнее время на летающие-вылетающие-катающиеся скроллинги. С радостью бы выключил.
3. За список «Settings» хочется отдельно бить морду дизайнеру этого «чуда». Долго, тщательно и со вкусом. Список отсортирован… никак он не отсортирован. Вообще. Ни по алфавиту, ни по функциональности… Единственное возможное объяснение, что его отсортировали «по важности и нужности». Но кто и как эту важность определял? Все свалено в одну кучу. Просто приходится помнить, что меню About находится где-то там внизу списка и кинетическим скроллингом гонять список туда-сюда, пока не поймаешь-таки этот пункт. Бред. Кому мешал алфавитный порядок? Почему нельзя настроить под себя? Почему все свалено в кучу? Почему нельзя было задействовать такой же режим группировки, как в других программах? Риторические вопросы. Ребята торопились, им было не до того…
4. Клавиатура доставляет. Когда нужно вводить в поле e-mail, то на раскладке появляется отдельная кнопочка '.com', но символ подчёркивания при этом почему-то засунут в самый дальний угол. Еле нашёл его вообще. Никто и никогда в e-mail не использует этот символ? Даже клавиатура в старом Pocket PC 2002 была функциональнее и удобнее. Почему нельзя было реализовать ввод дополнительных символов через удержание кнопки с буквой, как это сделано на том же Android — загадка для меня. Снова патентные тролли? Или всё то же «ребята торопились, ребятам было не до того»?
5. Отдельное спасибо дизайнером за работу кнопок при заблокированном устройстве. Что громкость регулируется, что питание выключается, что камера включается… Т.е. я должен носить телефон перед собой на вытянутых руках, кабы дабы что… ибо в кармане или сумке случайное нажатие просто тупо выключает телефон, или выводит громкость «в ноль», или включает камеру. Что за улучшение ухудшайзинга? Бред какой-то… Плюс еще невозможность зарядить выключенный телефон. Почему так решили?
6. Без доступа к интернету телефон представляет собой тупую железку для просмотра локального контента. Ну, логично, в общем-то. Фигня в том, что все (ВСЕ!!!) приложения, за исключением разве что встроеннного будильника и календаря, для генерации уведомлений обязаны использовать пуш-нотификации. Нет интернета — нет нотификаций. Тоже можно было бы не париться с этим, если бы телефон честно тебя предупреждал: «Ой, чувак, тут чет у меня инет кончился… Может оно и гут, но ты тут кучу софта поставил, который использует для своей работы систему нотификейшенов. Так вот, вся эта байда сейчас лежит мёртвым грузом и не работает! Имей ввиду...» Я имею ввиду, что телефон, жестко ориентированный на работу с интернетом, никак и ничем не предупреждает пользователя об отсутствии интернета как такового и невозможности функционирования должным образом.
Короче говоря, моё мнение, что система пока слишком смахивает на бету. Так много таких вот всяких мелких мелочей, которые не видны с первого взгляда за летающими окнами, но которые через некоторое время начинают конкретно доставать, что становится грустно…
А вот этого я уже не понимаю. Как писал в предыдущем топике, глядя на эти тарифы, создаётся впечатление, что трафик операторы между собой возят попакетно на верблюдах и через северный полюс! Он просто не может столько стоить! Да, есть определенные накладные расходы на установление проключения между двумя электронными АТС. Это означает, что надо обеспечить канал между двумя коммутационными узлами, которые агрегируют международный трафик. Т.е. либо самим проложить кабель напрямую, либо воспользоваться услугами транспортных контор, арендовав уже готовые каналы связи. Это вполне определенные расходы, которые очень легко посчитать и которые уж никак это не стоят таких астрономических сумм, которые хотят получать операторы. Накладные расходы на эксплуатацию этих каналов связи тоже есть, но они тоже вполне конечны, логичны и стандартизованы. Причем, не трудно догадаться, что расходы эти никак не зависят от трафика! Что есть трафик, что нет его в канале — накладные расходы на обслуживание этого никак не меняются!
И еще один момент — одно опто-волокно может прокачивать внутри себя огромный объём трафика — до 1 Гигабит (ну, если до конца быть честным, нужно два волокна: на прием и на передачу). На абонентскую ступень из 128 абонентов по стандарту идет 2Мбит поток. Т.е. одна пара волокн вполне способна прокачать весь трафик между РФ и Грецией, Турцией и Кипром вместе взятыми.
Вот теперь объясните мне, откуда появляются такие цифры за трафик? Когда один оператор начинает кивать на другого оператора, это напоминает детский сад, когда расхулиганившиеся карапузы кивают друг на друга. Обоих выпороть и поставить в угол, дабы не повадно было.
Разумеется, в реальности всё не так просто, как я написал. Конечно ROM состоит из нескольких стандартизованных блоков. Конечно можно не билдить каждый раз ROM целиком, а только обновленной блок + общий билд. Более того, предусмотрен механизм, когда на девайс присылается не блок, а только изменения для текущего блока, т.е. еще меньше информации.
Все это подробно описано либо на dea-developers, либо на нашем 4pda в соотв. разделах, посвященных ромоделанью
И нет ничего плохого в том, что дизайнер делает «бумажные» прототипы. Этому их учат и это они умеют делать хорошо. Опять же, для каких целей. Для целей выяснения юзабилити бумажные прототипы ничуть не хуже, чем сделанные в виде ПО.
А говорю я про это в контексте того, что первично: прототип или документация. Я стою на стороне того, что документация первична. На начальном этапе прототип уместен только в случае, когда надо что-то протестировать или когда просто нет другого способа уточнить общее ТЗ. Замещать подготовку документации прототипированием, как это предлагает топикстартер, на мой взгляд не верно в корне.
Дизайнер интерфейсов — как резчик. Бывают резчики по дереву, по кости, по металлу… Специальность — одна, а вот специализаций — множество. Поэтому вполне логично, что дизайнер, имеющий очень хорошую квалификацию в разработке UI под MAC, будет очень долго приспосабливаться под Android. Даже в эпоху расцвета Windows Mobile дизайнерам с десктопной винды приходилось приспосабливаться под мобильную, и хороших дизайнеров под мобильные приложения было не найти. А выцепить на hh.com сразу специалиста по дизайну UI под Android просто так вряд ли удастся и сейчас.
Я это все говорю к тому, что тезис о понимании дизайнером аспектов реализации тех или иных интерфейсных элементов в коде и о предугадывании дизайнером аспектов программирования — это некая идеализация, которая хотя и может быть достижима в отдельных идеальных случаях (ваш дизайнер в комманде уже 5 лет и на мобильных интерфейсах собаку съел), в большинстве случаев остается утопией.
Поэтому всё то, что в вашем примере вам кажется логичным и само собой разумеющимся, должно быть детально отображено в документации, которую получает на руки дизайнер UI прежде чем приступить к работе. И именно в документации, а не на словах, иначе вы рискуете провалить сроки. И документация при этом должна оперировать понятиями общей функциональности и логического взаимодействия, а не описывать «кнопочки» и «скроллбары».
О графическом дизайне речи не идет и, по-хорошему, UI-дизайнер не должен им заниматься.
3. Изучение технологии
— Это все не имеет прямого отношения к конкретному проекту. Это все НИОКР. Хочется заказчику оплачивать ваше обучение и разработки — ради бога. Большинство за подобные вольности порвет на британский флаг: «Я вам деньги не за это плачу!!!» Не зря перед проектом HR получает четкие требования к персоналу — по каким требованиям какие скилзы должны наличествовать.
А привлекать пользователей на ранней стадии — себе дороже. Гораздо важнее с ними тщательно проработать сценарии. А показывать — только альфу…
Давайте уточним, о каких типах проектов мы говорим? Я говорю не про стартапы, а про производственный процесс, когда продукты эволюционируют и развиваются. В таком случае роли в процессе разработки ПО уже четко распределены, и на позиции дизайнера UI находится действительно дизайнер, а не разработчик, освоивший Expression Blend. Если же говорить о стартапах, то тут все может быть очень кучеряво.
Второе. Прототипирование не должно подменять собой другие необходимые маркетинговые действия, и прежде всего — проработку сценариев использования. При проработке сценариев очень важно оперировать платформо-независимыми и интерфейсо-независимыми критериями. Попытка сперва нарисовать интерфейс, а потом описать сценарий использования этого интерфейса порочна. Дизайнер не владеет полностью идеей продукта, поэтому рисовать его будет в меру своего понимания, а потом вдруг оказывается, что именно такое кривое видение оказывается закрепленным в ТЗ.
В третьих, при таком раннем прототипировании есть очень большой шанс, что заказчики и пользователи начнут воспринимать прототип как «почти готовое приложение».
Но самое главное и самое большое возражение вот в чем. При раннем прототипировании, когда сценарии использования еще не проработаны, дизайнер, даже если у него есть общее описание логики работы программы, не владеет информацией о приоритезации различных частей программы. В результате он будет долго и тщательно прорисовывать экраны дополнительных настроек, а главные экраны могут быть не проработаны. При демонстрации подобного прототипа мнение о продукте у пользователей/Заказчика сложится совершенно неадекватное. Поэтому «горизонтальное» прототипирование можно делать только на этапе, когда сценарии уже завершены, общая конфигурация продукта согласована и утверждена.
И, кстати говоря, на 6 фотографии надо было писать не Flash, а LED Flash. Ибо в аппарате не импульсный источник подсветки (как в том же Mozart), а светодиодный.
Грация — не клон ну просто ни разу. Другой формат дисплея, другой форм-фактор, другая батарея, другие кнопки.
1. «Дизайн-1» Как человеку практичному, все эти «летающе-вылетающие окошки» как-то по-барабану. Мне нужно, чтобы было быстро и удобно. Летающий Metro — это красиво… первую неделю… потом начинает немного подбешивать…
2. «Дизайн-2» Кинетический скроллинг смотрится красиво… пока тебе не нужно реально им пользоваться. Когда тебе реально нужно быстро найти и запустить нужную программу — приходится тратить КУЧУ лишнего времени на то, чтобы гоняя список туда-сюда таки найти нужный ярлык. В этом плане концепция рабочих столов iPhone мне нравится гораздо больше: ты чётко знаешь, что нужный тебе ярлык размешен на 3-м столе, слева в третьей строчке. Ты запускаешь его моментально, не тратя лишнее время на летающие-вылетающие-катающиеся скроллинги. С радостью бы выключил.
3. За список «Settings» хочется отдельно бить морду дизайнеру этого «чуда». Долго, тщательно и со вкусом. Список отсортирован… никак он не отсортирован. Вообще. Ни по алфавиту, ни по функциональности… Единственное возможное объяснение, что его отсортировали «по важности и нужности». Но кто и как эту важность определял? Все свалено в одну кучу. Просто приходится помнить, что меню About находится где-то там внизу списка и кинетическим скроллингом гонять список туда-сюда, пока не поймаешь-таки этот пункт. Бред. Кому мешал алфавитный порядок? Почему нельзя настроить под себя? Почему все свалено в кучу? Почему нельзя было задействовать такой же режим группировки, как в других программах? Риторические вопросы. Ребята торопились, им было не до того…
4. Клавиатура доставляет. Когда нужно вводить в поле e-mail, то на раскладке появляется отдельная кнопочка '.com', но символ подчёркивания при этом почему-то засунут в самый дальний угол. Еле нашёл его вообще. Никто и никогда в e-mail не использует этот символ? Даже клавиатура в старом Pocket PC 2002 была функциональнее и удобнее. Почему нельзя было реализовать ввод дополнительных символов через удержание кнопки с буквой, как это сделано на том же Android — загадка для меня. Снова патентные тролли? Или всё то же «ребята торопились, ребятам было не до того»?
5. Отдельное спасибо дизайнером за работу кнопок при заблокированном устройстве. Что громкость регулируется, что питание выключается, что камера включается… Т.е. я должен носить телефон перед собой на вытянутых руках, кабы дабы что… ибо в кармане или сумке случайное нажатие просто тупо выключает телефон, или выводит громкость «в ноль», или включает камеру. Что за улучшение ухудшайзинга? Бред какой-то… Плюс еще невозможность зарядить выключенный телефон. Почему так решили?
6. Без доступа к интернету телефон представляет собой тупую железку для просмотра локального контента. Ну, логично, в общем-то. Фигня в том, что все (ВСЕ!!!) приложения, за исключением разве что встроеннного будильника и календаря, для генерации уведомлений обязаны использовать пуш-нотификации. Нет интернета — нет нотификаций. Тоже можно было бы не париться с этим, если бы телефон честно тебя предупреждал: «Ой, чувак, тут чет у меня инет кончился… Может оно и гут, но ты тут кучу софта поставил, который использует для своей работы систему нотификейшенов. Так вот, вся эта байда сейчас лежит мёртвым грузом и не работает! Имей ввиду...» Я имею ввиду, что телефон, жестко ориентированный на работу с интернетом, никак и ничем не предупреждает пользователя об отсутствии интернета как такового и невозможности функционирования должным образом.
Короче говоря, моё мнение, что система пока слишком смахивает на бету. Так много таких вот всяких мелких мелочей, которые не видны с первого взгляда за летающими окнами, но которые через некоторое время начинают конкретно доставать, что становится грустно…
И еще один момент — одно опто-волокно может прокачивать внутри себя огромный объём трафика — до 1 Гигабит (ну, если до конца быть честным, нужно два волокна: на прием и на передачу). На абонентскую ступень из 128 абонентов по стандарту идет 2Мбит поток. Т.е. одна пара волокн вполне способна прокачать весь трафик между РФ и Грецией, Турцией и Кипром вместе взятыми.
Вот теперь объясните мне, откуда появляются такие цифры за трафик? Когда один оператор начинает кивать на другого оператора, это напоминает детский сад, когда расхулиганившиеся карапузы кивают друг на друга. Обоих выпороть и поставить в угол, дабы не повадно было.
Все это подробно описано либо на dea-developers, либо на нашем 4pda в соотв. разделах, посвященных ромоделанью